contracts for system design
TRANSCRIPT
HAL Id hal-00757488httpshalinriafrhal-00757488
Submitted on 28 Nov 2012
HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents whether they are pub-lished or not The documents may come fromteaching and research institutions in France orabroad or from public or private research centers
Lrsquoarchive ouverte pluridisciplinaire HAL estdestineacutee au deacutepocirct et agrave la diffusion de documentsscientifiques de niveau recherche publieacutes ou noneacutemanant des eacutetablissements drsquoenseignement et derecherche franccedilais ou eacutetrangers des laboratoirespublics ou priveacutes
Contracts for System DesignAlbert Benveniste Benoit Caillaud Dejan Nickovic Roberto Passerone
Jean-Baptiste Raclet Philipp Reinkemeier Alberto Sangiovanni-VincentelliWerner Damm Thomas Henzinger Kim Guldstrand Larsen
To cite this versionAlbert Benveniste Benoit Caillaud Dejan Nickovic Roberto Passerone Jean-Baptiste Raclet et alContracts for System Design [Research Report] RR-8147 INRIA 2012 pp65 hal-00757488
ISS
N02
49-6
399
ISR
NIN
RIA
RR
--81
47--
FR+E
NG
RESEARCHREPORTNdeg 8147November 2012
Project-Teams S4
Contracts for SystemsDesignAlbert Benveniste Benoicirct Caillaud Dejan NickovicRoberto Passerone Jean-Baptiste Raclet Philipp ReinkemeierAlberto Sangiovanni-Vincentelli Werner DammTom Henzinger Kim Larsen
RESEARCH CENTRERENNES ndash BRETAGNE ATLANTIQUE
Campus universitaire de Beaulieu35042 Rennes Cedex
Contracts for Systems Design
Albert Benvenistelowast Benoicirct Caillauddagger Dejan NickovicDagger
Roberto Passeronesect Jean-Baptiste Racletpara Philipp Reinkemeier
Alberto Sangiovanni-Vincentellilowastlowast Werner Dammdaggerdagger
Tom HenzingerDaggerDagger Kim Larsen
Project-Teams S4
Research Report ndeg 8147 mdash November 2012 mdash 64 pages
This work was funded in part by the European STREP-COMBEST project number 215543 the European projects CESAR of the ARTEMIS JointUndertaking and the European IP DANSE the Artist Design Network of Excellence number 214373 the MARCO FCRP TerraSwarm grant the iCyPhyprogram sponsored by IBM and United Technology Corporation the VKR Center of Excellence MT-LAB and the German Innovation Alliance on EmbeddedSystems SPES2020
lowast INRIA Rennes France corresp author AlbertBenvenisteinriafrdagger INRIA Rennes FranceDagger Austrian Institute of Technology (AIT)sect University of Trento Italypara IRIT-CNRS Toulouse France Offis and University of Oldenburglowastlowast University of California at Berkeleydaggerdagger Offis and University of OldenburgDaggerDagger IST Austria Klosterneuburg
Aalborg University Danmark
Abstract Systems design has become a key challenge and differentiating factor over the last decadesfor system companies Aircrafts trains cars plants distributed telecommunication military or health caresystems and more involve systems design as a critical step Complexity has caused system design timesand costs to go severely over budget so as to threaten the health of entire industrial sectors Heuristicmethods and standard practices do not seem to scale with complexity so that novel design methods andtools based on a strong theoretical foundation are sorely neededModel-based design as well as other methodologies such as layered and compositional design have beenused recently but a unified intellectual framework with a complete design flow supported by formaltools is still lacking albeit some attempts at this framework such as Platform-based Design have beensuccessfully deployedRecently an rdquoorthogonalrdquo approach has been proposed that can be applied to all methodologies proposedthus far to provide a rigorous scaffolding for verification analysis and abstractionrefinement contract-based design Several results have been obtained in this domain but a unified treatment of the topic thatcan help in putting contract-based design in perspective is still missing This paper intends to providesuch treatment where contracts are precisely defined and characterized so that they can be used in designmethodologies such as the ones mentioned above with no ambiguity In addition the paper provides animportant link between interfaces and contracts to show similarities and correspondences Examples ofthe use of contracts in design are provided as well as in depth analysis of existing literature
Key-words system design component based design contract interface
Contrats pour la conception de systegravemesReacutesumeacute Cet article fait le point sur le concept de contrat pour la conception de systegravemes Les contrats que nous proposonsportent non seulement sur des proprieacuteteacutes de typage de leurs interfaces mais incluent une description abstraite de comportementsNous proposons une meacuteta-theacuteorie ou si lrsquoon veut une theacuteorie geacuteneacuterique des contrats qui permet le deacuteveloppement seacutepareacute desous-systegravemes Nous montrons que cette meacuteta-theacuteorie se speacutecialise en lrsquoune ou lrsquoautre des theacuteories connues
Mots-cleacutes conception des systegravemes composant contrat interface
Contracts for System Design 4
CONTENTS
I Introduction 6I-A The Present System Design 6I-B The Future CPS and SoS 6I-C The Need for a Methodological Effort 6I-D Contract based design 7I-E Readerrsquos guide 7
II System Design Challenges 8II-A Complexity of Systems 8II-B Complexity of OEM-Supplier Chains 9II-C Managing Requirements 9II-D Managing Risks 10II-E System-wide Optimization 10
III How Challenges have been addressed so far 10III-A Complexity of Systems and System-
wide Optimization 10III-A1 Layered design 11III-A2 Component-based design 11III-A3 The V-model process 11III-A4 Model-Based Design 12III-A5 Virtual Integration 12III-A6 Platform Based Design 13
III-B Complexity of OEM-Supplier ChainsStandardization and Harmonization 13III-B1 Standardization of design
entities 13III-B2 Harmonization of processes
and certification 14III-C Managing Requirements Traceability
and Multiple Viewpoints 14III-D Cross-company Shared Risk Management 14III-E The Need for Contracts 15
IV Contracts what why where and how 16IV-A Contracts 16
IV-A1 Components and their Envi-ronment Contracts 16
IV-B Contract Operators 17IV-B1 Contract Composition and
System Integration 17IV-B2 Contract Refinement and In-
dependent Development 18IV-B3 Contract Conjunction and
Viewpoint Fusion 18IV-C Contracts in requirement engineering 19IV-D Contract Support for Design Method-
ologies 20IV-D1 Supporting open systems 20IV-D2 Managing Requirements and
Fusing Viewpoints 20IV-D3 Design Chain Management
Re-using and IndependentDevelopment 21
IV-D4 Deployment and Mapping 21IV-E Bibliographical note 23
V A Mathematical Meta-theory of Contracts 24V-A Components and their composition 24V-B Contracts 25V-C Refinement and conjunction 25V-D Contract composition 26V-E Quotient 27V-F Discussion 27V-G Observers 27V-H Bibliographical note 28
VI Panorama of concrete theories 29
VII Panorama AssumeGuarantee contracts 29VII-A Dataflow AG contracts 30VII-B Capturing exceptions 30VII-C Dealing with variable alphabets 31VII-D Synchronous AG contracts 32VII-E Observers 32VII-F Discussion 32VII-G Bibliographical note 32
VIII Panorama Interface theories 33VIII-A Components as io-automata 33VIII-B Interface Automata with fixed alphabet 34VIII-C Modal Interfaces with fixed alphabet 35VIII-D Modal Interfaces with variable alphabet 37VIII-E Projecting and Restricting 38VIII-F Observers 40VIII-G Bibliographical note 40
IX Panorama Timed Interface Theories 42IX-A Components as Event-Clock Automata 42IX-B Modal Event-Clock Specifications 43IX-C Bibliographical note 43
X Panorama Probabilistic Interface Theories 44X-A Components as Probabilistic Automata 44X-B Simple Modal Probabilistic Interfaces 45X-C Bibliographical note 45
XI The Parking Garage an example in Require-ments Engineering 45
XI-A The contract framework 45XI-B Top level requirements 46XI-C Formalizing requirements as contracts 46XI-D Sub-contracting to suppliers 48XI-E The four ldquoCrdquo 49
XI-E1 Consistency amp Compatibility 49XI-E2 Correctness 50XI-E3 Completeness 50
XI-F Discussion 50
RR ndeg 8147
Contracts for System Design 5
XII Contracts in the context of AUTOSAR 50XII-A The AUTOSAR context 50XII-B The contract framework 51XII-C Exterior Light Management System 51
XII-C1 Function and timing 51XII-C2 Safety 56
XII-D Integrating Contracts in AUTOSAR 58XII-E Summary and discussion 59
XIII Conclusion 59XIII-A What contracts can do for the designer 59XIII-B Status of research 59XIII-C Status of practice 59XIII-D The way forward 59
References 60
RR ndeg 8147
Contracts for System Design 6
I INTRODUCTION
A The Present System Design
System companies such as automotive avionics and con-sumer electronics companies are facing significant difficultiesdue to the exponentially raising complexity of their productscoupled with increasingly tight demands on functionalitycorrectness and time-to-market The cost of being late tomarket or of imperfections in the products is staggering aswitnessed by the recent recalls and delivery delays that systemindustries had to bear
In 2010 Toyota had to recall 10 Million cars worldwidefor reasons that ranged from the infamous sticky acceleratorpedals to steering and engine problems The last recall atthe end of August 2010 was for the engine control moduleToyota is not alone in this situation Most of the automotivemakers had one or more major recalls in the recent past(see eg httpwwwautorecallsus) involving electronics aswell as mechanical parts Boeing and Airbus Industries hadsignificant delays in the delivery of their latest planes (787and A380) For the A380 underlying causes were cited asissues in the cabling system configuration management anddesign process In particular the complexity of the cabinwiring (100000 wires and 40300 connectors) was considereda major issue (see httpenwikipediaorgwikiAirbus_A380)The delays caused the departure of both the EADS and AirbusCEOs and of the program manager for the A380 and caused anoverall earning shortfall of 48 Billion Euros Boeing originallyplanned the first flight of the 787 for August 2007 (seehttpenwikipediaorgwikiBoeing_787) but after a streamof delay announcements the actual first flight occurred onDecember 15 2009 The delays were caused by a number ofunfortunate events and design errors and caused at least a 23Billion USD write-off not counting the claim of Air India of1 Billion USD damages for delayed delivery and the revenueshortfalls
These are examples of the devastating effects that designproblems may cause The specific root causes of these prob-lems are complex and relate to a number of issues rangingfrom design processes and relationships with different depart-ments of the same company and with suppliers to incompleterequirement specification and testing
B The Future CPS and SoS
Many products and services require to take into considera-tion the interactions of computational and physical processesSystems where this interaction is tight and needs special careare called Cyber-Physical Systems (CPS) [133] The broadmajority of these new applications can be classified as ldquodis-tributed sense and control systemsrdquo that go substantially be-yond the ldquocomputerdquo or ldquocommunicaterdquo functions traditionallyassociated with information technology These applicationshave the potential to radically influence how we deal with abroad range of crucial problems facing our society today forexample national security and safety including surveillanceenergy management and distribution environment control
efficient and reliable transportation and mobility and effectiveand affordable health care A recurring property of theseapplications is that they engage all the platform componentssimultaneouslymdashfrom data and computing services on thecloud of large-scale servers data gathering from the sensoryswarm and data access on mobile devicesmdashwith significantheterogeneity These large scale systems composed of subsys-tems that are themselves systems are now called Systems ofSystems (SoS) and are heavily investigated
As the complexity of these systems increases our inabilityto rigorously model the interactions between the physical andthe cyber sides creates serious vulnerabilities Systems becomeunsafe with disastrous inexplicable failures that could not havebeen predicted The challenges in the realization and operationof these CPS and SoS are manifold and cover a broad range oflargely unsolved design and run-time problems These includemodeling and abstraction verification validation and testreliability and resiliency multi-scale technology integrationand mapping power and energy security diagnostics andrun-time management Failure to address these challengesin a cohesive and comprehensive way will most certainlydelay if not prohibit the widespread adoption of these newtechnologies
C The Need for a Methodological Effort
We believe the most promising means to address the chal-lenges in systems engineering is to employ structured andformal design methodologies that seamlessly and coherentlycombine the various dimensions of the design space (be itbehavior space or time) that provide the appropriate abstrac-tions to manage the inherent complexity and that can pro-vide correct-by-construction implementations The followingtechnology issues must be addressed when developing newapproaches to the design of complex systems CPS and SoSbull The overall design flows for heterogeneous systemsmdash
meant here both in a technical and also an organiza-tional sensemdashand the associated use of models acrosstraditional boundaries are not well developed and un-derstood Relationships between different teams inside asame company or between different stake-holders in thesupplier chain are not well supported by solid technicaldescriptions for the mutual obligations
bull System requirement capture and analysis is in largepart a heuristic process where the informal text andnatural language-based techniques in use today are facingsignificant challenges Formal requirement engineeringis in its infancy mathematical models formal analysistechniques and links to system implementation must bedeveloped
bull Dealing with variability uncertainty and life-cycle issuessuch as extensibility of a product family are not well-addressed using available systems engineering methodol-ogy and tools
bull Design-space exploration is rarely performed adequatelyyielding suboptimal designs where the architecture se-lection phase does not consider extensibility re-usability
RR ndeg 8147
Contracts for System Design 7
and fault tolerance to the extent that is needed to reducecost failure rates and time-to-market
bull The verification and validation of ldquocomplex systemsrdquoparticularly at the system integration phase where anyinteractions are complicated and extremely costly toaddress is a common need in defense automotive andother industries
The challenge is to address the entire process and not toconsider only point solutions of methodology tools andmodels that ease part of the design
D Contract based design
It is our goal to offer a new approach to the system designproblem that is rigorous and effective in dealing with theproblems and challenges described before and that at thesame time does not require a radical change in the wayindustrial designers carry out their task as it cuts across designflows of different type contract-based design
Contracts in the layman use of the term are establishedwhen an OEM must agree with its suppliers on the subsystemor component to be delivered Contracts involve a legal partbinding the different parties and a technical annex that servesas a reference regarding the entity to be delivered by thesuppliermdashin this work we focus on the technical facet ofcontracts Contracts can also be used through their technicalannex in concurrent engineering when different teams developdifferent subsystems or different aspects of a system within asame company
In this paper we argue that contracts can be actually usedalmost everywhere and at nearly all stages of system designfrom early requirements capture to embedded computinginfrastructure and detailed design involving circuits and otherhardware Contracts explicitly handle pairs of properties re-spectively representing the assumptions on the environmentand the guarantees of the system under these assumptionsIntuitively a contract is a pair
C = (AG) of Assumptions Guarantees
characterizing in a formal way 1) under which context thedesign is assumed to operate and 2) what its obligations areAssumeGuarantee reasoning has been known for quite sometime but it has been used mostly as verification mean for thedesign of software Our purpose is more ambitious contractbased design with explicit assumptions is a philosophy thatshould be followed all along the design with all kinds ofmodels whenever necessary Here the models we mean arerichmdashnot only profiles types or taxonomy of data but alsomodels describing the functions performances of variouskinds (time and energy) and safety The consideration of richcontracts as above in the industry is still in its infancy Tomake contract-based design a technique of choice for systemengineers we must developbull Mathematical foundations for contract representation and
requirement engineering that enable the design of frame-works and tools
bull A system engineering framework and associated method-ologies and tool sets that focus on system requirementmodeling contract specification and verification at mul-tiple abstraction layers The framework should addresscross-boundary and cross-organizational design activities
This paper intends to provide a unified treatment of contractswhere they are precisely defined and characterized so that theycan be used in design with no ambiguity In addition the paperprovides an important link between interfaces and contractsto show similarities and correspondences Examples of the useof contracts in design will be provided as well as in depthanalysis of existing literature
E Readerrsquos guide
The organization of the paper is explained in Table IIn Section II a review of the challenges that are faced by the
system industry is proposed followed in Section III by ananalysis of the design methodologies that have been deployedto cope with them
Section IV develops a primer on contracts by using a verysimple example requiring only elementary mathematical back-ground to be followed Its purpose is to smoothly introducethe different concepts and operations we need for a contractframeworkmdashthe restricted case considered is by no meansrepresentative of the kind of system we can address usingcontracts We then introduce a motivating example repre-sentative of requirement engineering In a third sub-sectionldquorequirementsrdquo on a theory of contracts are identified fromanalyzing what is expected from contract-based design andin particular the support for 1) the development of differentaspects or viewpoints of a system such as its function safetytiming and resource use by different teams and how to fusethese different aspects and 2) the possibility for differentsuppliers to develop independently the different subsystemssubcontracted to them This section concludes with the relatedbibliography
Section V is the cornerstone of this paper and it is a newvista on contracts The so-called ldquometa-theoryrdquo of contractsis introduced and developed in detail By meta-theory wemean the collection of concepts operations and propertiesthat any formal contract framework should offer Conceptsoperations and properties are thus stated in a fairly genericway Every concrete framework compliant with this meta-theory will inherit these generic properties The meta-theoryfocuses on assumptions and guarantees its formalizes howdifferent aspects or viewpoints of a specification can beintegrated and on which basis independent development bydifferent suppliers can be safely performed
So far the meta-theory is non effective in that it is notsaid how component and contracts are effectively representedand manipulated The subsequent series of sections propose apanorama of major concrete contract frameworks Section VIIdevelops the AssumeGuarantee contracts This framework isthe most straightforward instance of the meta-theory It dealswith pairs (AG) of assumptions and guarantees explicitlyA and G being both expressed as properties This framework
RR ndeg 8147
Contracts for System Design 8
Section methodological tutorial fundamental technical applicationSection IIchallengesSection IIIaddressing the challengesSection IVwhy contracts where and how
Section Vcontract meta-theory
Section VIIAssumeGuarantee contractsSection VIIIInterface theoriesSection IXtimedSection Xprobabilistic
Section XIrequirements engineeringSection XIIAUTOSAR
Section IIdarr
Section III Section IV
Section V Section VII mdash Section VIIIdarr darr
Section XII Section XI
Section IX mdash Section Xdarr darr
Section Section
Section IIdarr
Section III Section IV
Section V Section XI Section XII
Table IREADERrsquoS GUIDE CATEGORIZATION OF THE DIFFERENT SECTIONS (TOP) AND
DEPENDENCIES (BOTTOM LEFT IN-DEPTH READING BOTTOM-RIGHT QUICK READING)
is flexible in that it allows for different styles of descriptionof such propertiesmdashcomputational efficiency depends on thestyle adopted Section VIII develops the Interface theoriesin which assumptions and guarantees are specified by meansof a single object the interface Interface theories turn outto include the most effective frameworks They can easily beadapted to encompass timing (Section IX) and probabilistic(Section X) characteristics of systems
In Section XI a toy example in requirements engineeringis developed This example is simple but rich enough to illus-trate the very difficulties in formalizing requirements It alsoillustrates well the added value of contract based requirementsengineering First the different responsibilities (assumptionsversus obligation or guarantees) that requirement implicit referto are made explicit and captured in our contract frameworkSecond contracts offer a formal meaning for documents ofrequirements structured into chapters or viewpoints Contractsoffer formal support for checking important properties suchas consistency compatibility completeness and more Finallycontracts offer significant assistance in the process of deduc-ing from the top specification an architecture of specificationsfor the different sub-systems for independent developmentWhile our application example is a toy one is it neverthelesstoo complex for dealing with it by hand We handle it by usinga proof-of-concept tool for contract management
Finally Section XII develops a case study in the contextof AUTOSAR AUTOSAR is a recently established standardin the automobile sector This standard was developed withthe objective of allowing for better flexibility in componentreuse and OEMsupplier relations This section illustrates howcontracts can be used to break into simple pieces of reasoningthe difficult task of correct system integration
II SYSTEM DESIGN CHALLENGES
Many challenges face the system community to deliverproducts that are reliable and effective We summarize someof them below
A Complexity of Systems
The ever-expanding use of electronic embedded systems tocontrol increasingly many aspects of the real world and thetrend to interconnect more and more such systems (often fromdifferent manufacturers) into a global network are creating achallenging scenario for system designers In this scenario thethree challenges that are taking center stage are as follows
The Hardware Platform Complexity Most system com-panies rely on Components off-the-shelf (COTS) and pro-grammability to implement their applications For companieswho build ldquophysically largerdquo systems such as avionics and au-tomotive companies the complexity of the hardware platform
RR ndeg 8147
Contracts for System Design 9
Design task Tasks Tasks Tasks Tasks Tasks Tasksdelayed delayed delayed causing delay causing delay causing delayautomotive automation medical automotive automation medical
System integration 630 565 667 423 190 375test and verificationSystem architecture 296 261 333 385 429 313design and specificationSoftware application 444 304 750 269 310 250andor middlewaredevelopment and testProject management 370 283 167 538 381 375and planning
Table IIDIFFICULTIES RELATED TO SYSTEM INTEGRATION
is reflected in the number of Electronic Control Units and intheir interconnections For a top-of-the-line automobile thenumber of processors to manage and interconnect is above50 The layout of the cables that connect these processingelements with sensors and actuators is a serious concern Initialproduction of the Airbus A380 was troubled by delays in partattributed to the 530 km (330 mi) of wiring in each aircraft
The Embedded Software Complexity Given the cost andrisks associated to developing hardware solutions system com-panies are selecting hardware platforms that can be customizedby reconfiguration andor by software programmability Inparticular software is taking the lionrsquos share of the implemen-tation budgets and cost In cell phones more than 1 millionlines of code is standard today while in automobiles theestimated number of lines by 2010 is in the order of hundredsof millions and in the Boeing 787 is in the order of 20 millionlines However as this happens the complexity explosion ofthe software component causes serious concerns for the finalquality of the products and the productivity of the engineeringteams
The Integration Complexity A standard technique to dealwith complexity consists in decomposing top-down the systeminto subsystems This approach which has been customar-ily adopted by the semiconductor industry for years has alimitation as a designer or a group of designers has to fullycomprehend the entire system and to partition appropriately itsvarious parts a difficult task given the enormous complexityof todayrsquos systems
Hence the future is one of developing systems by compos-ing pieces that all or in part have already been predesignedor designed independently by other design groups or evencompanies This has been done routinely in vertical designchains for example in the avionics and automotive sectorsalbeit in a heuristic and ad hoc way The resulting lack of anoverall understanding of the interplay of the subsystems and ofthe difficulties encountered in integrating very complex partscause system integration to become a nightmare in the systemindustry as demonstrated by Table II1
In addition heterogeneity comes into play Integration of
1VDC research Track 3 Embedded Systems Market Statistics Exhibit II-13from volumes on automotiveindustrial automationmedical 2008
electronic and mechanical design tools and frameworks will beessential in the near future Integration of chemical electronicand biology tools will be essential in the further future fornano-systems Data integration and information flow amongthe companies forming the chain have to be supported Inother words it is essential that the fundamental steps of systemdesign (functional partitioning allocation on computationalresources integration and verification) be supported acrossthe entire design development cycle and across different dis-ciplines
B Complexity of OEM-Supplier Chains
The source of the above problems is clearly the increase incomplexity It is however also the difficulty of the OEMs inmanaging the integration and maintenance process with sub-systems that come from different suppliers who use differentdesign methods different software architectures and differenthardware platforms
There are also multiple challenges in defining technicalannexes to commercial contracts between OEM and suppli-ers Specifications used for procurement should be preciseunambiguous and complete However a recurrent reason forfailures causing deep iterations across supply chain boundariesrests in incomplete characterizations of the environment ofthe system to be developed by the supplier such as missinginformation about failure modes and failure rates missing in-formation on possible sources for interferences through sharedresources and missing boundary conditions This highlightsthe need to explicate assumptions on the design context inOEM-supplier commercial contracts In light of an increasedsharing of hardware resources by applications developed bymultiple suppliers a contract-based approach seems indispens-able for resolving liability issues and allowing applicationswith different criticality levels to co-exist (such as ASILlevels[175] [13] in automotive)
C Managing Requirements
We argued that the design chains should connect seamlesslyto minimize design errors and time-to-market delays Yet theboundaries among companies and between different divisionsof the same company are often not as clean as needed anddesign specs move from one company (or one division) to the
RR ndeg 8147
Contracts for System Design 10
next in non-executable and often unstable and imprecise formsthus yielding misinterpretations and consequent design errorsIn addition errors are often caught only at the final integrationstep as the specifications were incomplete and imprecisefurther nonfunctional specifications (eg timing power con-sumption size) are difficult to trace Further it is commonpractice to structure system level requirements into severalldquochaptersrdquo ldquoaspectsrdquo or ldquoviewpointsrdquo Examples include thefunctions safety timing and energy viewpoints Quite oftenthese different viewpoints are developed by different teamsusing different skills frameworks and tools Yet they are notunrelated as we already mentioned Without a clean approachto handle multiple viewpoints the only sensible way is tocollect these viewpoints into a single requirements documentwhich is then seen as a flat collection of requirements forsubsequent design Since this is clearly impracticable thecommon practice instead is to discard some of the viewpointsin a first stage eg by considering only functions and safetyDesigns are then developed based on these only viewpointsOther viewpoints are subsequently taken into account (timingenergy) thus resulting in late and costly modifications andre-designs
Requirement engineering is a discipline that aims at improv-ing this situation by paying close attention to the managementof the requirement descriptions and traceability support (egusing commercial tools such as DOORS2 in combinationwith Reqtify3) and by inserting whenever possible preciseformulation and analysis methods and tools Research in thisarea is active but we believe more needs to be done to makethis essential step a first class citizen in system design Indeedif the specification quality is low then the entire design processis marred since the very beginning The overall system productspecification is somewhat of an art today since to verify itscompleteness and its correctness there is little that it can beused to compare with
D Managing Risks
System design processes are highly concurrent distributedand typically multi-domain often involving more than onehundred sub-processes The complexity of the entire designprocess and of the relationships between players in the supplychain creates the need to elaborate risk sharing and riskmanagement plans because of the potential enormity of theimpact that design errors and supplier solidity may have onthe economics of a company Risk management has thusbecome a requirement of most of public companies as fi-nancial social and political risks are analyzed and appropriatecountermeasures have to be prepared as a requirement fromthe regulatory bodies Risk mitigation measures typically coverall phases of design processes ranging from assuring highquality initial requirements to early assessments of risks inmeeting product requirements during the concept phase toenforcing complete traceability of such requirements with
2 httpwww-01ibmcomsoftwareawdtoolsdoorsproductline3httpetc
requirements management tools to managing consistency andsynchronization across concurrent sub-processes using PLMtools4 If we will be able to change the design processalong the lines of more formal approaches better complexityhandling better requirement engineering then risks will besubstantially lower than they are today
E System-wide Optimization
We believe that since the design process is fragmentedproduct optimization is rarely carried out across more thanone company boundary and even then it is limited due tobull The lack of appropriate models encompassing both func-
tional and non-functional (Quality of Service) aspectscovering both internal use and export outside the com-pany
bull The time pressure to meet the product deadlinesbull The functional description that is over-constrained by
architectural considerations which de facto eliminate po-tentially interesting implementation alternatives
If the design process were carried out as in a unique well-integrated virtual company including all the players shownabove the overall ecosystem would greatly benefit The issuehere is to allow a reasonably efficient design space explorationby providing a framework where different architectures couldbe quickly assembled and evaluated at each layer of abstractioncorresponding to the design task being considered in the chain
III HOW CHALLENGES HAVE BEEN ADDRESSED SO FAR
In this section we present a review and a critical analysisof the design methodologies that have been deployed to copewith the challenges exposed in the previous section
A Complexity of Systems and System-wide Optimization
Multiple lines of attack have been developed by researchinstitutions and industry to cope with the exponential growth insystems complexity starting from the iterative and incrementaldevelopment several decades ago [123] Among them ofparticular interest to the development of embedded controllersare Layered design Component-based design the V-modelprocess model-based development virtual integration andPlatform-Based Design (PBD) There are two basic princi-ples followed by these methods abstractionrefinement andcompositiondecomposition Abstraction and refinement areprocesses that relate to the flow of design between differentlayers of abstraction (vertical process) while compositionand decomposition operate at the same level of abstraction(horizontal process) Layered design the V-model processand model-based development focus on the vertical processwhile component-based design deals principally with the hor-izontal process PBD combines the two aspects in a unifiedframework and hence subsumes and can be used to integrated
4 PLM Product Lifecycle Management PLM centric design is used incombination with virtual modeling and digital mockups PLM acts as a database of virtual system components PLM centric design is for exampledeployed at Dassault-Aviation httpwwwdassault-aviationcomenaviationinnovationthe-digital-companydigital-designplm-toolshtmlL=1
RR ndeg 8147
Contracts for System Design 11
the other methodologies Contracts are ideal tools to solidifyboth vertical and horizontal processes providing the theoreticalbackground to support formal methods
1) Layered design Layered design copes with complexityby focusing on those aspects of the system pertinent to supportthe design activities at the corresponding level of abstractionThis approach is particularly powerful if the details of alower layer of abstraction are encapsulated when the designis carried out at the higher layer Layered approaches are wellunderstood and standard in many application domains Asan example consider the AUTOSAR standard5 This standarddefines several abstraction layers Moving from ldquobottomrdquoto ldquotoprdquo the micro-controller abstraction layer encapsulatescompletely the specifics of underlying micro-controllers thesecond layer abstracts from the concrete configuration of theElectronic Control Unit (ECU) the employed communicationservices and the underlying operating system whereas the(highest) application layer is not aware of any aspect ofpossible target architectures and relies on purely virtual com-munication concepts in specifying communication betweenapplication components Similar abstraction levels are definedby the ARINC standard in the avionic domains
The benefits of using layered design are manifold Using theAUTOSAR layer structure as example the complete separationof the logical architecture of an application (as represented bya set of components interconnected using the so-called virtualfunction bus) and target hardware is a key aspect of AUTOSARin that it supports decoupling of the number of automotivefunctions from the number of hardware components In par-ticular it is flexible enough to mix components from differentapplications on one and the same ECU This illustrates thedouble role of abstraction layers in allowing designers to focuscompletely on the logic of the application and abstracting fromthe underlying hardware while at the same time imposing aminimal (or even no) constraint on the design space of possiblehardware architectures In particular these abstractions allowthe application design to be re-used across multiple platformsvarying in number of bus-systems andor number and class ofECUs These design layers can in addition be used to matchthe boundaries of either organizational units within a companyor to define interfaces between different organizations in thesupply chain The challenge then rests in providing the properabstractions of lower-level design entities
2) Component-based design Whereas layered designs de-compose complexity of systems ldquoverticallyrdquo component-basedapproaches reduce complexity ldquohorizontallyrdquo whereby designsare obtained by assembling strongly encapsulated design enti-ties called ldquocomponentsrdquo equipped with concise and rigorousinterface specifications Re-use can be maximized by findingthe weakest assumptions on the environment sufficient to es-tablish the guarantees on a given component implementationWhile these interface specifications are key and relevant forany system the ldquoquality attributerdquo of perceiving a subsystemas a component is typically related to two orthogonal criteria
5See httpwwwautosarorg
that of ldquosmall interfacesrdquo and that of minimally constrainingthe deployment context so as to maximize the potential for re-use ldquoSmall interfacesrdquo ie interfaces which are both smallin terms of number of interface variables or ports as wellas ldquologically smallrdquo in that protocols governing the invoca-tion of component services have compact specifications notrequiring deep levels of synchronization constitute evidenceof the success of encapsulationmdashstill small interfaces mustencompass dynamic properties of the system The secondquality attribute is naturally expressible in terms of interfacespecifications where re-use can be maximized by finding theweakest assumptions on the environment sufficient to establishthe guarantees on a given component implementation
One challenge then for component-based design of em-bedded systems is to provide interface specifications that arerich enough to cover all phases of the design cycle Thiscalls for including non-functional characteristics as part ofthe component interface specifications which is best achievedby using multiple viewpoints Current component interfacemodels in contrast are typically restricted to purely functionalcharacterization of components and thus cannot capitalize onthe benefits of virtual integration testing as outlined above
The second challenge is related to product line designwhich allows for the joint design of a family of variants of aproduct The aim is to balance the contradicting goals of striv-ing for generality versus achieving efficient component im-plementations Methods for systematically deriving ldquoquotientrdquospecifications to compensate for ldquominorrdquo differences betweenrequired and offered component guarantees by composing acomponent with a wrapper component (compensating for suchdifferences as characterized by quotient specifications) existsfor restricted classes of component models [155]
3) The V-model process A widely accepted approach todeal with complexity of systems in the defense and trans-portation domain is to structure product development processesalong variations of the V diagram originally developed fordefense applications by the German DoD6
Its characteristic V-shape splits the product developmentprocess into a design and an integration phase Specificallyfollowing product level requirement analysis subsequent stepswould first evolve a functional architecture supporting productlevel requirements Sub-functions are then re-grouped takinginto account re-use and product line requirements into alogical architecture whose modules are typically developed bydifferent subsystem suppliers The realization of such modulesoften involves mechanical hydraulic electrical and electronicsystem design Subsequent phases would then unfold thedetailed design for each of these domains such as the designof the electronic subsystem involving among others the designof electronic control units These design phases are paralleledby integration phases along the right-hand part of the Vsuch as integrating basic- and application software on theECU hardware to actually construct the electronic control unitintegrating the complete electronic subsystems integrating the
6See eg httpwwwv-model-xtde
RR ndeg 8147
Contracts for System Design 12
mechatronic subsystem to build the module and integratingmultiple modules to build the complete product Not shownbut forming an integral part of V-based development processesare testing activities where at each integration level test-suites developed during the design phases are used to verifycompliance of the integrated entity to their specification
This presentation is overly simplistic in many ways Thedesign of electronic components in complex systems suchas aircrafts inherently involves multi-site multi-domain andcross-organizational design teams reflecting eg a partition-ing of the aircraft into different subsystems (such as primaryand secondary flight systems cabin fuel and wing) differentdomains such as the interface of the electronic subsystem tohydraulic andor mechanical subsystems control-law designtelecommunications software design hardware design diag-nostics and development-depth separated design activities car-ried out at the OEM and supplier companies This partitioningof the design space (along perspectives and abstraction layers)naturally lends itself to a parallelization of design activitiesa must in order to achieve timely delivery of the overallproduct leading often into the order of hundreds of concurrentdesign processes To summarize while being popular andwidely referenced the V-model process has become a ldquosloganrdquohiding the complexity of actual design processes In realitylarge system companies develop their own processes and thenstruggle for their application both in-house and across thesupplier chain
4) Model-Based Design Model-based design (MBD) is to-day generally accepted as a key enabler to cope with complexsystem design due to its capabilities to support early require-ment validation and virtual system integration MBD-inspireddesign languages and tools such as SysML7 [149] andorAADL [152] for system level modeling Catia and Model-ica [93] for physical system modeling Matlab-Simulink [118]for control-law design and UML8 [44] [147] Scade [32]and TargetLink for detailed software design depend on de-sign layer and application class The state-of-the-art in MBDincludes automatic code-generation simulation coupled withrequirement monitoring co-simulation of heterogeneous mod-els such as UML and Matlab-Simulink model-based analy-sis including verification of compliance of requirements andspecification models model-based test-generation rapid pro-totyping and virtual integration testing as further elaboratedbelow
In MBD today non-functional aspects such as performancetiming power or safety analysis are typically addressed indedicated specialized tools using tool-specific models withthe entailed risk of incoherency between the correspond-ing models which generally interact To counteract theserisks meta-models encompassing multiple views of designentities enabling co-modeling and co-analysis of typicallyheterogeneous viewpoint specific models have been developedExamples include the MARTE UML [148] profile for real-time
7httpwwwomgorgspecSysML8httpwwwomgorgspecUML
system analysis the SPEEDS HRC metamodel [156] and theMetropolis semantic meta-model [19] [67] [16] [170] InMetropolis multiple views are accommodated via the conceptof ldquoquantitiesrdquo that annotate the functional view of a designand can be composed along with subsystems using a suitablealgebra The SPEEDS meta-model building on and extendingSysML has been demonstrated to support co-simulation andco-analysis of system models for transportation applicationsallowing co-assessment of functional real-time and safety re-quirements It forms an integral part of the meta-model-basedinter-operability concepts of the CESAR reference technologyplatform9
Meta-modeling is also at the center of the model driven(software) development (MDD) methodology MDD is basedon the concept of the model-driven architecture (MDA) whichconsists of a Platform-Independent Model (PIM) of the ap-plication plus one or more Platform-Specific Models (PSMs)and sets of interface definitions MDA tools then supportthe mapping of the PIM to the PSMs as new technologiesbecome available or implementation decisions change [146]The Vanderbilt University group [119] has evolved an em-bedded software design methodology and a set of tools basedon MDD In their approach models explicitly represent theembedded software and the environment it operates in andcapture the requirements and the design of the applicationsimultaneously using domain-specific languages (DSL) Thegeneric modeling environment (GME) [119] provides a frame-work for model transformations enabling easy exchange ofmodels between tools and offers sophisticated ways to sup-port syntactic (but not semantic) heterogeneity The KerMetametamodeling workbench [91] is similar in scope
5) Virtual Integration Rather than ldquophysicallyrdquo integratinga system from subsystems at integration stages model-baseddesign allows systems to be virtually integrated based on themodels of their subsystem and the architecture specificationof the system Such virtual integration thus allows detectingpotential integration problems up front in the early designphases Virtual system integration is often a source of het-erogeneous system models such as when realizing an aircraftfunction through the combination of mechanical hydraulicand electronic systems Heterogeneous composition of modelswith different semantics was originally addressed in Ptolemy[88] Metropolis [20] [67] [16] [48] and in the SPEEDSmeta-model of heterogeneous rich components [65] [29] [31]albeit with different approaches Virtual integration involvesmodels of the functions the computer architecture with itsextra-functional characteristics (timing and other resources)and the physical system for control Some existing frameworksoffer significant support for virtual integration Ptolemy IIMetropolis and RT-Builder Developments around Catia andModelica as well as the new offer SimScape by Simulinkprovide support for virtual integration of the physical part atan advanced level
9wwwcesarprojecteu
RR ndeg 8147
Contracts for System Design 13
6) Platform Based Design Platform-based design was in-troduced in the late 1980s to capture a design process thatcould encompass horizontal (component-based design virtualintegration) and vertical (layered and model-based design)decompositions and multiple viewpoints and in doing sosupport the supply chain as well as multi-layer optimization
The idea was to introduce a general approach that couldbe shared across industrial domain boundaries that wouldsubsume the various definition and design concepts and thatwould extend it to provide a framework to reason aboutdesign Indeed the concepts have been applied to a variety ofvery different domains from automotive to System-on-Chipfrom analog circuit design to building automation to syntheticbiology
The basic tenets of platform-based design are as followsThe design progresses in precisely defined abstraction layersat each abstraction layer functionality (what the system issupposed to do) is strictly separated from architecture (howthe functionality could be implemented) This aspect is clearlyrelated to layered design and hence it subsumes it
Each abstraction layer is defined by a design platform Adesign platform consists ofbull A set of library components This library not only con-
tains computational blocks that carry out the appropriatecomputation but also communication components that areused to interconnect the computational components
bull Models of the components that represent a characteri-zation in terms of performance and other non-functionalparameters together with the functionality it can supportNot all elements in the library are pre-existing com-ponents Some may be ldquoplace holdersrdquo to indicate theflexibility of ldquocustomizingrdquo a part of the design that isoffered to the designer In this case the models representestimates of what can be done since the components arenot available and will have to be designed At times thecharacterization is indeed a constraint for the implementa-tion of the component and it is obtained top-down duringthe refinement process typical of layered designs Thislayering of abstractions based on mathematical models istypical of model-based methods and the introduction ofnon-functional aspects of the design relates to viewpoints
bull The rules that determine how the components can beassembled and how the the functional and non-functionalcharacteristics can be computed given the ones of thecomponents to form an architectureThen a platformrepresents a family of designs that satisfies a set ofplatform-specific constraints [15] This aspect is relatedto component-based design enriched with multiple view-points
This concept of platform encapsulates the notion of re-use asa family of solutions that share a set of common features (theelements of the platform) Since we associate the notion ofplatform to a set of potential solutions to a design problem weneed to capture the process of mapping a functionality (whatthe system is supposed to do) with the platform elements thatwill be used to build a platform instance or an ldquoarchitecturerdquo
(how the system does what it is supposed to do) The strictseparation between function and architecture as well as themapping process have been highly leveraged in AUTOSARThis process is the essential step for refinement and provides amechanism to proceed towards implementation in a structuredway Designs on each platform are represented by platform-specific design models A design is obtained by a designerrsquoscreating platform instances (architectures) via composing plat-form components (process that is typical of component-baseddesign) by mapping the functionality onto the components ofthe architecture and by propagating the mapped design in thedesign flow onto subsequent abstraction layers that are dealtwith in the same way thus presenting the design process asan iterative refinement This last point dictates how to moveacross abstraction layers it is an important part of design spaceexploration and offers a way of performing optimization acrosslayers In this respect PBD supports multiple viewpoints in ageneral way
B Complexity of OEM-Supplier Chains Standardization andHarmonization
So far the main answer to the complexity of OEM-supplierchains has been standardization Standardization concerns boththe design entities and the design processes particularlythrough the mechanism of certification
1) Standardization of design entities By agreeing on (do-main specific) standard representations of design entitiesdifferent industrial domains have created their own linguafranca thus enabling a domain wide shared use of designentities based on their standardized representation Exam-ples of these standards in the automotive sector include therecently approved requirement interchange format standardRIF10 the AUTOSAR11 de-facto standard the OSEK12 operat-ing system standard standardized bus-systems such as CAN13
and Flexray14 standards for ldquocar2Xrdquo communication andstandardized representations of test supported by ASAM15Examples in the aerospace domain include ARINC stan-dards16 such as the avionics applications standard interfaceIMA RTCA17 communication standards In the automationdomain standards for interconnection of automation devicessuch as Profibus18 are complemented by standardized designlanguages for application development such as Structured Text
As standardization moves from hardware to operating sys-tem to applications and thus crosses multiple design layersthe challenge increases to incorporate all facets of designentities required to optimize the overall product while atthe same time enabling distributed development in complex
10httpwwww3org2005ruleswikiRIF_Working_Group11httpwwwautosarorg12httpwwwosek-vdxorg13httpwwwisoorgisosearchhtmqt=Controller+Area+
NetworkampsearchSubmit=Searchampsort=relamptype=simpleamppublished=true14httpwwwflexraycom15httpwwwasamnet16httpwwwaeec-amc-fsemccomstandardsindexhtml17httpwwwrtcaorg18httpwwwprofibuscom
RR ndeg 8147
Contracts for System Design 14
supply chains As an example to address the different view-points required to optimize the overall product AUTOSARextended in transitioning from release 31 to 4 its capabilityto capture timing characteristics of design entities a keyprerequisite for assessing alternate deployments with respectto their impact on timing More generally the need for overallsystem optimization calls for the standardization of all non-functional viewpoints of design entities an objective yet tobe achieved in its full generality in order to allow crosslayer optimization Within the EDA domain such richnessof design interface specifications is industrial practice Withinthe systems domain the rich component model introduced inthe Integrated Projects SPEEDS tackles this key objective incovering multiple design layers (from product requirements todeployment on target architectures) and in providing means ofassociating multiple viewpoints with each design entity it isexpressive enough to allow for cross-supply chain optimizationof product developments This approach is further elaboratedand driven towards standardization in the Artemis flagshipproject CESAR
2) Harmonization of processes and certification Harmo-nizing or even standardizing key processes (such as devel-opment processes and safety processes) provides for a fur-ther level of optimization in interactions across the supplychain As an example Airbus Directives and Procedures(ADBs) provide requirements for design processes of equip-ment manufactures Often harmonized processes across thesupply chain build on agreed maturity gates with incrementalacceptance testing to monitor progress of supplier developmenttowards final acceptance often building on incremental proto-types Shared use of Product Lifcycle Management (PLM)19
databases across the supply chain offers further potentialsfor cross-supply chain optimization of development processesAlso in domains developing safety related systems domainspecific standards clearly define the responsibilities and dutiesof companies across the supply chain to demonstrate func-tional safety such as in the ISO 2626220 for the automotivedomain IEC 6150821 for automation its derivatives CenelecEN 50128 and 5012622 for rail and Do 178 B23 for civilavionics
Yet the challenge in defining standards rests in balancingthe need for stability with the need of not blocking processinnovations As an example means for compositional con-struction of safety cases are seen as mandatory to reducecertification costs in the aerospace and rail domains Similarlythe potential of using formal verification techniques to copewith increasing system complexity is considered in the movefrom DO 178 B to DO 178 C standards
19See [162] and also footnote 420httpwwwisoorgisocatalogue_detailhtmcsnumber=4346421httpwwwiecchfunctionalsafety22httpwwwceneleceuCenelecCENELEC+in+actionWeb+Store
Standardsdefaulthtm23httpwwwdo178sitecom
C Managing Requirements Traceability and Multiple View-points
Depending on application domains up to 50 of all er-rors result from imprecise incomplete or inconsistent andthus unfeasible requirements Requirements are inherently illstructured They must address all aspects of the system andthus cannot be constrained by the lingua franca of a partic-ular domain They are fragmented in the form of large andsometimes huge DOORS files24 structured into viewpointsTwo issues have thus been identified by systems industries asessential for requirement management powerful and flexibletraceability tools to relate requirements between them and tolink them to tests for validation purposes and the developmentof domain specific ontologies as part of the PLM suiteFurther based on an assessment by the system companiesprocesses in the CESAR project25 and the German EmbeddedSystems Innovation alliance26 and building on the finding ofthe Integrated Project SPEEDS27 multiple viewpoints havebeen categorized into perspectives and aspects to provide asolid requirement and property modeling scaffold Perspectivesare viewpoints relevant to architecture modeling as carriedout by different stake-holders during the development processAspects are viewpoints that are orthogonal to the systemstructure Aspects are used to demonstrate compliance of thearchitecture to end-user concerns Example of aspects aresafety cost maintainability performance and weight Themeta-model underlying the CESAR RTP is able to maintainlinks such as the satisfy derive verify refine and allocaterelationships between design artifacts of different perspectivesand across abstraction layers
In addition to cope with the inherently unstructured prob-lem of (in)completeness of requirements industry has setup domain- and application-class specific methodologies Asparticular examples we mention learning process such asemployed by Airbus to incorporate the knowledge base ofexternal hazards from flight incidents the Code of Practiceproposed by the Prevent Project28 using guiding questions toassess the completeness of requirements in the concept phaseof the development of advanced driver assistance systemsUse-case analysis methods as advocated for UML baseddevelopment process follow the same objective All togetherrequirement engineering misses the support of formal ap-proaches for its structuring and analysis
D Cross-company Shared Risk Management
The realization of complex systems calls for design pro-cesses that mitigate risks in highly concurrent distributedand typically multi-domain engineering processes often in-volving more than one hundred sub-processes Risk mitigation
24Typical sub-systems in aeronautics would have a few thousands top-levelrequirements An aircraft can have up to several hundred thousands of them
25wwwcesarprojecteu26httpspes2020informatiktu-muenchende27httpwwwspeedseucom28Albert http
RR ndeg 8147
Contracts for System Design 15
measures typically cover all phases of design processes rang-ing from ensuring high quality initial requirements to earlyassessments of risks in realizability of product requirementsduring the concept phase to enforcing complete traceabilityof such requirements with requirements management tools tomanaging consistency and synchronization across concurrentsub-processes using PLM tools A key challenge rests inbalancing risk reduction versus development time and effortcompletely eliminating the risks stemming from concurrentengineering essentially requires a complete synchronizationalong a fine-grained milestone structure which would kill anydevelopment project due to the induced delays Another keychallenge is the ldquonot my faultrdquo syndrome in the OEM-supplierchain when errors call for costly re-design and the issue ofpenalties arises Properly assigning responsibilities to risks isstill out of reach today
E The Need for Contracts
The way system design challenges have been addressed sofar leaves huge opportunities for improvements by relying oncontract-based design In this section we briefly summarizefor each existing approach to address the design challengeshow contracts could improve the current situation
Contribution 1 Addressing Complexity of Systems andSystem-wide OptimizationWhile layered design (Section III-A1) and component baseddesign (Section III-A2) have been critical steps in breakingsystems complexity they do not by themselves provide theultimate answer When design is being performed at a consid-ered layer implicit assumptions regarding other layers (egcomputing resources) are typically invoked by the designerwithout having these explicated Hence actual properties ofthese other layers cannot be confronted against these hiddenassumptions Similarly when components or sub-systems areabstracted via their interfaces in component based design itis generally not true that such interfaces provide sufficientinformation for other components to be safely implementedbased on this sole interface Contract-based design providesthe due discipline concepts and techniques to cope with thesedifficulties
Model-based development (Section III-A4) has reached sig-nificant maturity by covering nearly all aspects of the system(physics functions computing resources) albeit not yet in afully integrated way To offer a real added value any newlyproposed technology should be rich enough for encompassingall these aspects as well Contract-based design offers in largepart this desirable feature
Virtual integration and virtual modeling (Section III-A5) isa step beyond basic model-based development by offering anintegrated view of all the above different aspects eg physics+ functions + performances Contract-based design supportsthe fusion of different systems aspects
Contract-based design is compliant with the V-model pro-cess (Section III-A3) just because it does not impose anyparticular design process Using contracts only imposes a
small set of rules that any process should accommodate seeSection IV-D for a discussion of this
Finally Platform-Based Design (PBD Section III-A6)which is being deployed in some large systems industries suchas United Technologies Corporation (UTC) is a systematicand comprehensive methodology that unifies the various de-sign methodologies that have been described in this sectionContracts offer theory and methodological support for boththe successive refinement aspect the composition aspect andthe mapping process of PBD allowing formal analysis andsynthesis processes
Contribution 2 Addressing the Complexity of OEM-Supplier ChainsThe problems raised by the complexity of OEM-SupplierChains (Section II-B) are indeed the core target of contract-based design By making the explication of implicit assump-tions mandatory contracts help assigning responsibilities toa precise stake holder for each design entity By supportingindependent development of the different sub-systems whileguaranteing smooth system integration they orthogonalize thedevelopment of complex systems Contracts are thus adequatecandidates for a technical counterpart of the legal bindingsbetween partners involved in the distributed and concurrentdevelopment of a system
Contribution 3 Managing RequirementsSo far the task of getting requirements right and managingthem well (Section III-C) has only got support for sortingthe complexity out (traceability services and ontologies whichis undoubtely necessary) However requirements can only betested on implementations and it is not clear whether properdistinctions are made when performing tests regarding thefollowing fusing the results of tests associated to differentchapters or viewpoints of a requirement document versusfusing the results of tests associated to different sub-systemstesting a requirement under the responsibility of the designerof the considered sub-system versus testing a requirementcorresponding to an assumption regarding the context of useof this sub-systemmdashsuch distinctions should be made as weshall see Also requirements are barely executable and cannotin general be simulated Requirements engineering is the otherprimary target of contract-based design the above issues areproperly handled by contracts and contracts offer improvedsupport for evidencing the satisfaction of certification con-straints
Contribution 4 Managing RisksRisk metrics and risk mitigation measures are the essentialtools in managing risks (Section III-D) By offering improvedsupport for sub-contracting and distributing design to differentteams contracts are likely to significantly reduce the ldquonot myfaultrdquo syndrome
Contribution 5 Addressing CertificationAs explained in Section III-B2 the design of critical sys-tems is subject to a number of certification standards Whilecertification steps are mostly concerned with the processesnot the designs themselves the recent move from DO 178Bto DO 178C for level A critical systems in aeronautics has
RR ndeg 8147
Contracts for System Design 16
shown for the first time the consideration of formal proofsor validations as valid evidences We believe that the samewill eventually hold for contracts In particular by providingadequate formal support for completeness consistency com-patibility and more for sets of requirements contracts wouldprovide a valuable contribution to certification
IV CONTRACTS WHAT WHY WHERE AND HOWAs we argued in the previous section there are two basic
principles followed by design methods so far developed ab-stractionrefinement and compositiondecomposition Abstrac-tion and refinement are processes that relate to the flow of de-sign between different layers of abstraction (vertical process)while composition and decomposition operate at the same levelof abstraction (horizontal process) In this section we presentbriefly contracts and the basic operations they support andthen me make the point that contracts are ideal tools to solidifyboth vertical and horizontal processes providing the theoreticalbackground to support formal methods We conclude thesection by providing a (non exhaustive) bibliography on thegeneral concept of contract
A Contracts
Here we propose a ldquoprimerrdquo on contracts using a simpleexample as the reference for their use
1) Components and their Environment Contracts We startfrom a model that consists of a universal set M of com-ponents each denoted by the symbol M A component Mis typically an open system ie it contains some inputsthat are provided by other components in the system or theexternal world and it generates some outputs This collectionof other components and the exterior world is referred to as theenvironment of the component The environment is often notcompletely known when the component is being developedAlthough components cannot constrain their environment theyare designed to be used in a particular context
In the following example we define a component M1 thatcomputes the division between two real inputs x and y andreturns the result through the real output z The underlyingassumption is that M1 will be used within a design contextthat prevents the environment from giving the input y = 0Since M1 cannot constrain its input variables we handle theexceptional input y = 0 by generating an arbitrary output
M1
variables
inputs x y
outputs z
types x y z isin Rbehaviors (y 6= 0rarr z = xy) and (y = 0rarr z = 0)
A contract contract denoted by the symbol C is a de-scription of a component with the following characteristicproperties
1) Contracts are intentionally abstract2) Contracts distinguish responsibilities of a component
from that of its environmentProperty 1) of a contract highlights the goal of handlingcomplexity of the systems Thus contracts expose enough
information about the component but not more than necessaryfor the intended purpose We can see a contract as an under-specified description of a component that can be either veryclose to the actual component or specify only a singleproperty of a componentrsquos behavior Regarding Property 2)and in contrast to components a contract explicitly makes adistinction between assumptions made about the environmentand guarantees provided mirroring different roles and respon-sibilities in the design of systems
A contract can be implemented by a number of differentcomponents and can operate in a number of different envi-ronments Hence we define a contract C at its most abstractlevel as a pair C = (EC MC ) of subsets of components thatimplement the contract and of subsets of environments inwhich the contract can operate We say that a contract C isconsistent if MC 6= empty and compatible if EC 6= empty
This definition of contracts and the implementation relationis very general and as such it is not effective In concretecontract- based design theories a contract needs to have afinite description that does not directly refer to the actualcomponents and the implementation relation needs to beeffectively computable and establish the desired link betweena contract and the underlying components that implement it
For our present simple example of static systems wepropose the following way to specify contracts
C1
variables
inputs x y
outputs z
types x y z isin Rassumptions y 6= 0
guarantees z = xy
C1 defines the set of components having as variablesinputs x y output z of type real and whose behaviorssatisfy the implication
ldquoassumptionsrArr guaranteesrdquo
ie for the above example y 6= 0rArr z = xy Intuitivelycontract C1 specifies the intended behavior of components thatimplement division It explicitly makes the assumption that theenvironment will never provide the input y = 0 and leaves thebehavior for that input undefined
This contract describes an infinite number of environmentsin which it can operate namely the set EC1
of environmentsproviding values for x and y with the condition that y 6=0 Itdescribes an infinite number of components that implementthe above specification where the infinity comes from theunderspecified case on how an implementation of C1 shouldcope with the illegal input y = 0 In particular we have thatM1 implements C1 Thus contract C1 is consistent We nowshow a variant of contract C1 that is not consistent
Cprime1
variables
inputs x y
outputs z
types x y z isin Rassumptions T
guarantees z = xyRR ndeg 8147
Contracts for System Design 17
where symbol T denotes the boolean constant ldquotruerdquo Incontrast to C1 the contract Cprime1 makes no assumption on valuesof the input y Hence every component that implements Cprime1has to compute the quotient xy for all values of y includingy = 0 which makes no sense
B Contract Operators
There are three basic contract operators that are used insupport of the design methodologies we presented previouslycomposition refinement and conjunction
1) Contract Composition and System Integration Intu-itively the composition operator supports component-baseddesign and in general horizontal processes The compositionoperator that we denote by the symbol times is a partial functionon components The composition is defined with respect to acomposability criterion where two components M and M prime
are composable if their variable types match Composabilityis a syntactic property on pairs of components that definesconditions under which the two components can interactComposition times must be both associative and commutative inorder to guarantee that different composable components maybe assembled together in any order
Consider the component M2 defined as follows
M2
variables
inputs x
outputs y
types x y isin Rbehaviors y = ex
The component M2 computes the value of the output variabley as the exponential function of the input variable x M1 andM2 are they are composable since both common variables xand y have the same type x is an input variable to both M1
and M2 and the output variable y of M2 is fed as an input toM1 It follows that their composition M1 timesM2 has a singleinput variable x and computes the output z as a function ofx that is z = xex
Now consider component M prime2 that consists of an inputvariable x and an output variable z both of type real wherez = abs(x)
M prime2
variables
inputs x
outputs z
types x z isin Rbehaviors z = abs(x)
The component M prime2 is not composable with M1 becausethe two components share the same output variable z Theircomposition is illegal as it would result in conflicting rulesfor updating z
We now lift the above concepts to contracts The compo-sition operator between two contracts denoted by otimes shallbe a partial function on contracts involving a more subtlecompatibility criterion Two contracts C and Cprime are compatibleif their variable types match and if there exists an environmentin which the two contracts properly interact The resultingcomposition C otimes Cprime should specify through its assumptions
this set of environments By doing so the resulting contractwill expose how it should be used Unlike component com-posability contract compatibility is a combined syntactic andsemantic property
Let us formalize this For C a contract let AC and GC beits assumptions and guarantees and define
GC1otimesC2 = GC1andGC2
AC1otimesC2 = max
A∣∣∣∣∣∣AandGC2rArrAC1andAandGC1rArrAC2
(1)
where ldquomaxrdquo refers to the order of predicates by implica-tion thus AC1otimesC2 is the weakest assumption such that thetwo referred implications hold Thus this overall assumptionwill ensure that when put in the context of a componentimplementing the second contract then the assumption ofthe first contract will be met and vice-versa Since the twoassumptions were ensuring consistency for each contract theoverall assumption will ensure that the resulting compositionis consistent This definition of the contract compositiontherefore meets our previously stated requirements The twocontracts C1 and C2 are called compatible if the assumptioncomputed as in (1) differs from F the ldquo falserdquo predicate
Consider contracts C2 and Cprime2 that we define as follows
C2
variables
inputs u
outputs x
types u x isin Rassumptions T
guarantees x gt u
Cprime2
variables
inputs v
outputs y
types v y isin Rassumptions T
guarantees y = minusv
C2 specifies components that for any input value u generatesome output x such that x gt u and Cprime2 specifies componentsthat generate the value of the output variable y as functiony = minusv of the input v Observe that both C2 and Cprime2 areconsistent A simple inspection shows that C1 and C2 can becomposed and their composition yields
C1 otimes C2
variables
inputs u y
outputs x z
types x y u z isin Rassumptions y 6= 0
guarantees x gt u and z = xy
C1 and Cprime2 can also be composed and their composition yields
C1 otimes Cprime2
variables
inputs v x
outputs y z
types v x y z isin Rassumptions v 6= 0
guarantees y = minusv and z = xyRR ndeg 8147
Contracts for System Design 18
Both compositions possess a non-empty assumption (observealso that they are both free of exception) reflecting that thetwo pairs (C1 C2) and (C1 Cprime2) are compatible
In our example we require that compositions C1otimes(C2otimesC3)and (C1 otimes C2) otimes C3 result in equivalent contracts as well ascompositions C1otimesC2 and C2otimesC1 thus providing support forincremental system integration
A quotient operation can be defined that is dual to thecomposition operation Given a system-wide contract C anda contract C1 that specifies pre-existing components and theirinteractions the quotient operation CC1 defines the part ofthe system-wide contract that still needs to be implementedIt formalizes the practice of ldquopatchingrdquo a design to make itbehave according to another contract
2) Contract Refinement and Independent DevelopmentIn all vertical design processes the notions of abstractionand refinement play a central role The concept of contractrefinement must ensure the following if contract Cprime refinescontract C then any implementation of Cprime should 1) implementC and 2) be able to operate in any environment for C Hencethe following definition for refinement pre-order betweencontracts we say that the contract Cprime refines the contract C ifECprime supe EC andMCprime subeMC Since is a pre-order refinementis a transitive relation For our current series of examples andusing previous notations Cprime C amounts to requiring that 1AC implies ACprime and 2 ACprimerArrGCprime implies ACrArrGC
In Figure 4 we start with the contract C1 that representsthe general system-wide requirements We decompose theserequirements into requirements of three subsystems resultingin three contracts C11 C12 and C13 with the property thatC11otimesC12otimesC13 C1 Now these three contracts can be handedto different design teams and refined further independentlyIn particular C12 is further decomposed into contracts C121
and C122 such that C121 otimes C122 C12 and similarly C13 isfurther decomposed into contracts C131 and C132 such thatC131 otimes C132 C13
For all contracts C1 C2 Cprime1 and Cprime2 if C1 is compatible withC2 and Cprime1 C1 and Cprime2 C2 then Cprime1 is compatible with Cprime2and Cprime1 otimes Cprime2 C1 otimes C2
We now give a concrete example where we start withvery abstract requirements for a component that implementsa function z = xex Consider contracts Cprimeprime1 and Cprimeprime2 that wedefine as follows
Cprimeprime1
variables
inputs y
outputs z
types y z isin Rassumptions y 6= 0
guarantees z isin R
Cprimeprime2
variables
inputs x
outputs y
types x y isin Rassumptions T
guarantees y gt 0
The contract Cprimeprime1 formalizes the most crude and abstractrequirements for a divider It requires that the denominatorvalue (input variable y) is not equal to 0 and only ensuresthat the output value of z is any real Note that the contractCprimeprime1 does not declare the nominator input variable x Thecontract Cprimeprime2 specifies components that have an input variablex and an output variable of type y The only requirement onthe behavior of Cprimeprime2 is that y is strictly greater than 0 Thecomposition Cprimeprime1 otimes Cprimeprime2 is well defined The contract C1 refinesCprimeprime1 since it allows more inputs (the nominator input variable x)and restricts the behavior of the output variable z by definingits behavior as the division xy It follows that C1 is alsocompatible with Cprimeprime2 and that C1 otimes Cprimeprime2 Cprimeprime1 otimes Cprimeprime2 Finally wehave that M1 and M2 are implementations of their respectivecontracts It follows that M1 timesM2 implements C1 otimes Cprimeprime2
3) Contract Conjunction and Viewpoint Fusion We nowintroduce the conjunction operator between contracts denotedby the symbol and Conjunction is complementary to composi-tion
1) In the early stages of design the system-level speci-fication consists of a requirements document that is aconjunction of requirements
2) Full specification of a component can be a conjunctionof multiple viewpoints each covering a specific (func-tional timing safety etc) aspect of the intended designand specified by an individual contract see Figure 4 foran illustration
3) Conjunction supports reuse of a component in differentparts of a design see Figure 5 for an illustration
We state the desired properties of the conjunction operatoras follows Let C1 and C2 be two contracts If C1 and C2 areshared refinable then C1 andC2 C1 and C1 andC2 C2 and forall contracts C if C C1 and C C2 then C C1 and C2
To illustrate the conjunction operator we consider a contractCT1 that specifies the timing behavior associated with C1 Forthis contract we introduce additional ports that allow us tospecify the arrival time of each signal
CT1
variables
inputs tx ty
outputs tz
types tx ty tz isin R+
assumptions Tguarantees tzlemax(tx ty) + 1
The contract CT1 is shared refinable with C1 Their conjunctionC1 and CT1 yields a contract that guarantees in addition to C1itself a latency with bound 1 (say in ms) for it Becausethere are no assumptions this timing contract specifies thesame latency bound also for handling the illegal input y = 0In fact the contract says more because it does not mentionthe input y it assumes any value of y is acceptable Asa result the conjunction inherits the weakest T assumptionof the timing contract and cancels the assumption of C1This however is clearly not the intent since the timingcontract is not concerned with the values of the signals andis a manifestation of the weakness of this simple contract
RR ndeg 8147
Contracts for System Design 19
framework in dealing with contracts with different alphabetsof ports and variables We will further explain this aspect andshow how to address this problem in Section VII For themoment we can temporarily fix the problem by introducing yin the interface of the contract and use it in the assumptionsas in the following contract CT2
CT2
variables
inputs y tx ty
outputs tz
types y isin R tx ty tz isin R+
assumptions y 6=0guarantees tzlemax(tx ty) + 1
Note that this timing contract does not specify any bound forhandling the illegal input y = 0 since the promise is notenforced outside the assumptions
So far this example was extremely simple In particularit was stateless Extension of this kind of AssumeGuaranteecontracts to stateful contracts will be indeed fully developedin the coming sections and particularly in Section VII
C Contracts in requirement engineering
In this section we introduce a motivating example that isrepresentative of early requirements capturemdashthe specificationof a parking garage Its full development requires technicalmaterial that we introduce later and we thus defer it toSection XI This example illustrates the following features ofcontract based requirements capture namelybull Top-level system specification is by writing a require-
ments document Different formalisms may be used fordifferent kinds of requirements Here we illustrate thisby blending textual requirements written in constrainedEnglish (possibly obtained using boilerplates) with smallsized automata
bull The document itself is structured into chapters describingvarious aspects of the system such as how gates shouldbehave how payment should proceed plus some overallrules
bull Some requirements are under the responsibility of thesystem under development they contribute to specifyingthe guarantees that the system offers Other requirementsare not under the responsibility of the system underdevelopment they contribute to defining the assumptionsregarding the context in which the system should operateas specified
bull Requirements are written in constrained English languageor by using automata
We now begin with the top-level requirements The systemunder specification is a parking garage subject to paymentby the user At its most abstract level the requirementsdocument comprises the different chapters gate payment andsupervisor see Table III The gate chapter will collect thegeneric requirements regarding entry and exit gates Thesegeneric requirements will then be specialized for entry andexit gates respectively
Focus on the ldquogaterdquo chapter It consists of the three require-ments shown on Table III Requirement Rg1 is best described
gateRg1ldquovehicles shall not pass when gate is closedrdquo see Fig 7Rg2 after vehicle_pass vehicle_pass is forbiddenRg3 after gate_open gate_open is forbidden and
after gate_close gate_close is forbiddenpaymentsupervisor
Table IIITHE TOP-LEVEL SPECIFICATION WITH CHAPTER gate EXPANDED
REQUIREMENTS WRITTEN IN italics ARE ASSUMPTIONS UNDER WHICHgate SHOULD OPERATE
0
gate_close
1gate_opengate_close
vehicle_passgate_open
Figure 1 Requirement Rg1 specified as an io-automaton Prefix ldquordquoindicates an input and prefix ldquordquo indicates an output
by means of an io-automaton shown in Figure 1mdashwe providean informal textual explanation for it between quotes Supposethat some requirement says ldquogate_open never occursrdquo Thisis translated by having no mention of gate_open in thecorresponding io-automaton To express this ldquonegativerdquo factwe must keep track of the fact that gate_open belongs tothe alphabet of actions of the io-automaton Thus when per-forming the translation the explicit list of inputs and outputsshould be explicitly given To avoid such additional notationalburden we have cheated by omitting this unless necessaryThe other two requirements are written using constrainednatural language which can be seen as a boilerplate styleof specification Prefix ldquordquo indicates an input and prefix ldquordquoindicates an output
The first two requirements are not under the responsibilityof the system since they rather concern the car driver Thus itdoes not make sense to include them as part of the guaranteesoffered by the system Should we remove them This wouldbe problematic If drivers behave the wrong way unexpectedthings can occur for sure The conclusion is that 1) we shouldkeep requirements Rg1 and Rg2 and 2) we should handlethem differently than Rg3 which is a guarantee offered by thesystem Indeed Rg1 and Rg2 are assumptions under whichthe gate operates as guaranteed We take the convention thatassumptions are written in italics
So far we have specified gate as a list of requirementsRequirement Rg1 specified as an io-automaton can be con-sidered formal Requirements Rg2 and Rg3 are formulatedin constrained natural language and are ready for subsequentformalization eg as io-automata Are we done Not yetWe need to give a formal meaning to what it means to havea collection of requirements and what it means to distinguishassumptions from guarantees Similarly we must give a formalmeaning to what it means to combine different chapters of arequirements document Intuitively all requirements must be
RR ndeg 8147
Contracts for System Design 20
met for a chapter to be satisfied and similarly all chaptersmust be satisfied for the whole specification to be correctlyimplemented Thus we propose to write the top-level specifi-cation C as the following conjunction
C = Cgate and Cpayment and Csupervisor
As we said formally defining what conjunction and is requirestechnical material that is developed later in this paper Thefollowing issues arise regarding this top-level specificationFirst of all since a conjunction operator is involved in theconstruction of C there is a risk of formulating contradictingrequirementsmdashthis is referred to as the issue of consistencySecond are we sure that the top-level specification C iscomplete ie precise enough to rule out undesirable imple-mentations One good way of checking for completeness is tobe able to execute or simulate this top-level specification CWe provide answers to all these issues in Section XI wherethis example is fully developed
request enter
ticket issue
entry gate open
entry gate closeEntryGate
vehicle enter
vehicle exit
exit ticket insert ExitGateexit gate open
exit gate close
ticket insert payment
coin insert paymentPaymentMachine exit ticket issue
Figure 2 System architecture as specified by the designer
Having the top-level specification C at hand the designerthen specifies an architecture ldquoagrave la SysMLrdquo as shown onFigure 2 Some comments are in order regarding this archi-tecture The considered instance of a parking garage consistsof one entry gate one exit gate and one payment machineCompare with the top-level specification of Table III Thelatter comprises a generic gate a payment machine and asupervisor each one with its set of requirements In contrastthe architecture of Figure 2 involves no supervisor Thesupervisor is meant to be distributed among the two gatesThe architecture of Figure 2 seems to be very loosely coupledFirst the PaymentMachine seems to be totally independent Infact the ticket that is inserted in the exit gate must coincidewith the one issued by the PaymentMachine It turns out thatthis reflects a missing assumption regarding the environmentof the system (namely the user of the parking) Then thetwo gates seem to have the shared input ldquovehicle exitrdquo astheir only interaction But this shared input is involved in
requirement Rs3 which forbids the entry if the parking isfull
The next step in the design consists in subcontractingthe development of each of the three sub-systems of thearchitecture of Figure 2 This amounts to specifying threesubcontracts CEntryGate CExitGate and CPaymentMachinesuch that
CEntryGate otimes CExitGate otimes CPaymentMachine C (2)
The symbol in (2) means that any implementation of theleft hand side is also a valid implementation of the top-level C Then the contract composition operator otimes ensuresthat each supplier can develop its sub-system based on itsown sub-contract only and still integrating the so designedsub-systems yields a correct implementation of the top-levelspecification Once the three sub-contracts are found checkingthat they satisfy (2) requires formalizing the contract compo-sition operator otimes Furthermore guessing such sub-contractsis a difficult task In our development of this example inSection XI we propose adequate answers to these issues
D Contract Support for Design Methodologies
The three operators introduced above fit naturally in anydesign methodology developed so far In particular contractcomposition and conjunction supports horizontal processesand contract refinement supports vertical processes We showhow this is so by first analyzing the use of contract conjunc-tion for requirement management then of composition andrefinement for design chain management re-use and indepen-dent development to close with conjunction composition andrefinement for deployment and mapping
1) Supporting open systems When designing componentsfor reuse their context of use is not fully known in advanceWe thus need a specification of components exposing boththe guarantees offered by the component and the assumptionson its possible context of usemdashits ldquoenvironmentrdquo This stateswhat contracts should be
2) Managing Requirements and Fusing Viewpoints Re-ferring to Section III-C complex systems involve a numberof viewpoints (or aspects) that are generally developed bydifferent teams using different skills As a result there is aneed for fusing these viewpoints in a mathematically soundway Structuring requirements or specifications is a desirableobjective at each step of the design Finally we must formal-ize some key properties that must be evidenced as part ofcertification processes
This process is illustrated in Figure 3 In this figure weshow three viewpoints the behavioral viewpoint where thefunctions are specified the timing viewpoint where timingbudgets are allocated to the different activities and the safetyviewpoint where fault propagation effect and handling arespecified Typically different viewpoints are developed bydifferent teams using different frameworks and tools Devel-opment of each viewpoint is performed under assumptionsregarding its context of use including the other viewpoints To
RR ndeg 8147
Contracts for System Design 21
VIEWPOINT VIEWPOINT VIEWPOINTBEHAVIORAL TIMING SAFETY
is a conjunctionevery contract
C =and
i Ci
CB1 CB2 CT CS1 CS2
CB1 and CB2 and CT and CS1 and CS2
Figure 3 Conjunction of requirements and viewpoints in top-level design
get the full system specification the different viewpoints mustbe fused As the notations of Figure 3 suggest conjunctionis used for fusing viewpoints thus reflecting that the systemunder design must satisfy all viewpoints Similarly eachviewpoint is itself a conjunction of requirements seen as theldquoatomicrdquo contractsmdashall requirements must be met
3) Design Chain Management Re-using and IndependentDevelopment In Figure 4 we show three successive stages ofthe design At the top level sits the overall system specificationas developed by the OEM As an example it can be obtained asthe conjunction of several viewpoints as illustrated on Figure 3
is delegated forimplementation by a supplier
is delegated forimplementation by a supplier
C11 otimes (C121 otimes C122)otimes (C131 otimes C132)
C11
C12
C13
C11
C121 C122 C131 C132
C121 otimes C122 C131 otimes C132
C11 otimes C12 otimes C13
C1
is refined by the OEM
Figure 4 Stepwise refinement
As a first design step the OEM decomposes its system intoan architecture made of three sub-systems for independentdevelopment by (possibly different) suppliers For each ofthese sub-systems a contract C1j j = 1 2 3 is developedA contract composition denoted by the symbol ldquootimesrdquo
C11 otimes C12 otimes C13
mirrors the composition of sub-systems that defines the archi-tecture For our method to support independent development
this contract composition operator must satisfy the following
if designs are independently performed for eachsub-contract C1j j = 1 2 3 then integratingthese sub-systems yields an implementation thatsatisfies the composed contract C11 otimes C12 otimes C13
(3)
This contract composition must then be qualified against thetop-level contract C1 This qualification must ensure that anydevelopment compliant with C11 otimes C12 otimes C13 should alsocomply with C1 To ensure substitutability in any legal contextcompliance concerns both how the system behaves and whatits allowed contexts of use are any legal context for C1 shouldbe also legal for C11otimesC12otimesC13 and under any legal contextthe integrated system should behave as specified by C1 This isformalized as the refinement relation denoted by the symbol
C11 otimes C12 otimes C13 C1 (4)
Overall the satisfaction of (4) guarantees the correctness ofthis first design step performed by the OEM
Obtaining the three sub-contracts C11 C12 and C13 is the artof the designer based on architectural considerations Contracttheories however offer the following services to the designerbull The formalization of parallel composition and refinement
for contracts allows the designer to firmly assess whether(4) holds for the decomposition step or not
bull In passing the compatibility of the three sub-contractsC11 C12 and C13 can be formally checked
bull Using contracts as a mean to communicate specificationsto suppliers guarantees that the information provided tothe supplier is self-contained the supplier has all theneeded information to develop its sub-system in a waythat subsequent system integration will be correct
Each supplier can then proceed with the independent devel-opment of the sub-system it is responsible for For instance asupplier may reproduce the above procedure
Alternatively this supplier can develop some sub-systemsby reusing off-the-shelf components For example contractC121 would be checked against the interface specification of apre-defined component M121 available from a library and thefollowing would have to be verified does component M121
satisfy C121 In this context shared implementations are ofinterest This is illustrated on Figure 5 where the same off-the-shelf component implements the two referred contracts
To conclude on this analysis the two notions of refinementdenoted by the symbol ldquordquo and composition of contractsdenoted by the symbol ldquootimesrdquo are key Condition (3) ensuresindependent development holds
4) Deployment and Mapping Here we address a specificbut important point related to Contribution 1 At some pointin the design of the system specifications must be realized byusing resources Resources can be pre-defined sub-systems orcomponents or they can consist of computing resources com-prising computing units and communication media (networksbusses and protocols) This methodology was advocated and
RR ndeg 8147
Contracts for System Design 22
C11
C121 C122 C131 C132
C11 otimes (C121 otimes C122)otimes (C131 otimes C132)
C121 otimes C122 C131 otimes C132
C122 and C132
Figure 5 Conjunction for component reuse
systematically exploited in Platform Based Design [171] orPLM-centric design see footnote 4 in Section II How sucha step can be captured in contract based design is explainednext
When deploying an application over a computing plat-form in addition to the functional viewpoint non-functionalviewpoints (safety timing energy and possibly other) areof importance as well The safety viewpoint is concernedwith the risk of primary faults and failures how they couldpropagate throughout the system and what the consequencesfor the resilience of the overall system would be in termsof failure probability The timing viewpoint collects timingrequirements regarding the application (requirements on la-tencies throughput jitter and schedulability) The effectivesatisfaction of safety or timing viewpoints by a considereddeployment depends on 1) the supporting execution platformand 2) the mapping of the application to this executionplatform We thus need to formalize what ldquomappingrdquo meansThe reader is referred to Figure 6 for the following discussion
M4M3
M5M6
M1
M2
M3
M1
M4
M2
M5
M6x34
xd63 xo
63
x34
C2 C1
C3
P
C
xo63
xd63
Figure 6 Mapping the application to the execution platform as C and P
Suppose one has a virtual model of the execution platform
as an architecture composed of several components Suchcomponents would in the context of Figure 6 consist of adescription of the available computing units a descriptionof the bus protocol and frame structure andor a library ofRTOS (Real-Time Operating System) services The resultingcomponents are enhanced with timing information (for thetiming viewpoint) and fault propagation information (for thesafety viewpoint) Application contracts are attached to thedifferent sub-systems or components as described on the toppart of the figure Similarly platform contracts are attachedto the different sub-systems or components of the executionplatform as described on the bottom part of the figureAccordingly we assume
C =andk
(otimesiisinIk Cik
)P =
otimesjisinJ
(and`isinLj
Pj`)
where
bull The overall platform contract P decomposes asotimes
jisinJ Pj(eg the bus and the different computing units inFigure 6) where each Pj is the conjunction of its differentviewpoints (the function what can be computed and theassociated performance how much time it takes and howmuch energy it consumes)
bull The overall application contract is the conjunction ofits different viewpoints Ci with their own architecturaldecomposition
In Figure 6 we only show a single viewpoint29 and we assumethat distant communication between C2 and C3 has alreadybeen refined to a communication medium compliant with thecommunication resources offered by the execution platform
The mapping of the application over the architecture ismodeled by the conjunction CandP defined by the following setof synchronization tuples30 depicted in red in the Figure 6
bull The wire x34 linking M3 to M4 in the application issynchronized in the deployment P with the variablex34 of the left computing unit where x34 represents theoutput of the module implementing M3 and the input ofthe module implementing M4 And similarly for the wirelinking M5 to M6
bull In the deployment the wire x63 linking M6 to M3
must traverse the bus To capture this we first refinethe application architecture by distinguishing the originxo63 of this wire from its destination xd63 In the refinedapplication architecture we assume that xo63 and xd63 arerelated by some buffer of bounded size The deploymentis then captured by synchronizing xo63 with the output xo63
of the module implementing M6 in the right computingunit and by synchronizing xd63 with the input xd63 of themodule implementing M3 in the left computing unit
29Here we assume that the different application viewpoints are developedfor the whole application and then combined by conjunctionmdashthis is just amethodological proposal we could proceed differently
30In in a synchronization tuple both occurrences and values of the differentelements are unified
RR ndeg 8147
Contracts for System Design 23
This formalizes the deployment as the conjunction
C and P =[and
k
(otimesiisinIk Cik
) ]and [otimesjisinJ(and
`isinLjPj`) ]
ensuring that C and P refines C by construction There ishowever no free lunch The formula C and P expressing de-ployment involves a conjunction and is as such a possiblesource of inconsistencies If this happens then C and P cannotbe implemented Finding an execution platform P causingno inconsistency in C and P requires a good understanding ofthe application and its needs The more advanced techniquesdeveloped in Section XI provide assistance for this
Since C and P relates application and computing platformmdashwhich sit at different layers of the designmdashwe call suchcontracts vertical contracts Contracts that are not vertical aresometimes called horizontal in that they are meant to relatecomponents sitting at a same level of the design hierarchymdashapplication level or computing platform level or ECU (Elec-tronic Computing Unit) level
Techniques of mapping application to its execution platformthat are similar to the above one are used in the RT-Buildertool 31 and in the Metropolis platform [20] [80]
E Bibliographical note
Having collected the ldquorequirementsrdquo on contract theories itis now timely to confront these to the previous work referringto or related to the term ldquocontractrdquo
It is difficult to write a comprehensive bibliography onthe general aspects of contract based design The topic ismulti faceted and has been addressed by several communitiessoftware engineering language design system engineeringand formal methods in a broad sense We report here a partialand limited overview of how this paradigm has been tackledin these different communities While we do not claim beingexhaustive we hope that the reader will find her way to thedifferent literatures
Contracts in SW engineering This part of the biblio-graphical note was inspired by the report [168] Design byContract is a software engineering technique popularized byBertrand Meyer [139] [140] following earlier ideas fromFloyd-Hoare logic [169] [113] Floyd-Hoare logic assignsmeaning to sequential imperative programs in the form oftriples of assertions PCQ consisting of a preconditionon program states and inputs a command and a postcondi-tion on program states and outputs Meyerrsquos contracts weredeveloped for Object-Oriented programming They exposethe relationships between systems in terms of preconditionsand postconditions on operations and invariants on states Acontract on an operation asserts that given a state and inputswhich satisfy the precondition the operation will terminatein a state and will return a result that satisfy the postcondi-tion and respects any required invariant properties Contractscontribute to system substitutability Systems may be replacedby alternative systems or assemblies that offer the same or
31httpwwwgeensoftcomenarticlertbuilder
substitutable functionality with weaker or equivalent precon-ditions and strongerequivalent postconditions With the aimof addressing service oriented architectures Meyerrsquos contractswere proposed a multiple layering by Beugnard et al [37]The basic layer specifies operations their inputs outputs andpossible exceptions The behavior layer describes the abstractbehavior of operations in terms of their preconditions andpostconditions The third layer synchronisation correspondsto real-time scheduling of component interaction and messagepassing The fourth quality of service (QoS) level detailsnon-functional aspects of operations The contracts proposedby Beugnard et al are subscribed to prior to service invo-cation and may also be altered at runtime thus extendingthe use of contracts to Systems of Systems [141] So farcontracts consisting of prepostconditions naturally fit imper-ative sequential programming In situations where programsmay operate concurrently interference on shared variablescan occur RelyGuarantee rules [115] were thus added tointerface contracts Rely conditions state assumptions aboutany interference on shared variables during the execution ofoperations by the systemrsquos environment Guarantee conditionsstate obligations of the operation regarding shared variables
The concepts of interface and contract were subse-quently further developed in the Model Driven Engineering(MDE) [120] [172] [131] In this context interfaces aredescribed as part of the system architecture and comprisetyped ports parameters and attributes Contracts on interfacesare typically formulated in terms of constraints on the en-tities of components using the Object Constraint Language(OCL) [150] [180] Roughly speaking an OCL statementrefers to a context for the considered statement and expressesproperties to be satisfied by this context (eg if the context isa class a property might be an attribute) Arithmetic or set-theoretic operations can be used in expressing these propertiesThis method however does not account for functional andextra-functional properties of interfaces ie for behavior andperformance To account for behavior the classical approachin MDE consists in enriching components with methods thatcan be invoked from outside andor state machines Likewiseattributes on port methods have been used to represent non-functional requirements or provisions of a component [51]The effect of a method is made precise by the actual codethat is executed when calling this method The state machinedescription and the methods together provide directly animplementation for the component mdash actually several MDErelated tools such as GME and Rational Rose automaticallygenerate executable code from this specification [21] [132][161] The notion of refinement is replaced by the concept ofclass inheritance From a contract theory point of view thisapproach has several limitations Inheritance for instance isunable to cover aspects related to behavior refinement Noris it made precise what it means to take the conjunctionof interfaces which can only be approximated by multipleinheritance or to compose them
In a continuing effort since his joint work with W Dammon Life Sequence Charts (LSC) in 2000 [64] with its Play-
RR ndeg 8147
Contracts for System Design 24
Engine implementation [107] David Harel has developed theconcept of behavioral programming [108] [106] [109] whichputs in the forefront scenarios as a program developmentparadigmmdashnot just a specification formalism In behavioralprogramming b-threads generate a flow of events via anenhanced publishsubscribe protocol Each b-thread is a pro-cedure that runs in parallel to the other b-threads When ab-thread reaches a point that requires synchronization it waitsuntil all other b-threads reach synchronization points in theirown flow At synchronization points each b-thread specifiesthree sets of events requested events the thread proposes thatthese be considered for triggering and asks to be notifiedwhen any of them occurs waited-for events the thread doesnot request these but asks to be notified when any of themis triggered and blocked events the thread currently forbidstriggering any of these events When all b-threads are at asynchronization point an event is chosen (according to somepolicy) that is requested by at least one b-thread and is notblocked by any b-thread The selected event is then triggeredby resuming all the b-threads that either requested it or arewaiting for it This mechanism was implemented on top ofJava and LSCs The execution engine uses planning and modelchecking techniques to prevent the system from falling intodeadlock where all requested events are blocked Behavioralprogramming is incremental in that new threads can be addedto an existing program without the need for making any changeto this original program new deadlocks that are created bydoing so are pruned away by the execution engine Whilebehavioral programming cannot be seen as a paradigm ofcontracts it shares with contracts the objectives of incrementaldesign and declarative style of specification
Our focusmdashcontracts for systems and CPS The frame-works of contracts developed in the area of Software En-gineering have established as useful paradigms for compo-nent based software system development In this paper wetarget the wider area of computer controlled systems morerecently referred to as Cyber-Physical systems where reactivesystems [104] [110] [100] [136] are encountered that issystems that continuously interact with some environmentas opposed to transformational systems [100] considered inObject-Oriented programming For reactive systems model-based development (MBD) is generally accepted as a keyenabler due to its capabilities to support early validationand virtual system integration MBD-inspired design lan-guages and tools include SysML [149] or AADL [152] forsystem level modeling Modelica [93] for physical systemmodeling Matlab-Simulink [118] for control-law design andScade [144] [32] and TargetLink for detailed software designUML-related standardisation efforts in this area also includethe MARTE UML32 profile for real-time systems Contracttheories for model based development were considered inthe community of formal verification They were initiallydeveloped as specification formalisms able to refuse certaininputs from the environment Dill proposed asynchronous
32 wwwomgmarteorg
trace structures with failure behaviors [81] A trace structureis a representation of a component or interface with two setsof behaviors The set of successes are those behaviors whichare acceptable and guaranteed by the component Converselythe set of failures are behaviors which drive the componentinto unacceptable states and are therefore refused This workfocuses primarily on the problem of checking refinement anddoes not explore further the potentials of the formalism froma methodological point of view The work by Dill was laterextended by Wolf in the direction of synchronous systemsNegulescu later generalizes the algebra to Process Spaceswhich abstract away the specifics of the behaviors and derivesnew composition operators [143] This particular abstractiontechnique was earlier introduced by Burch with Trace Algebrasto construct conservative approximations [47] and later gen-eralized by Passerone and Burch [154] to study generic tracestructures with failure behaviors and to formalize the problemof computing the quotient (there called mirror) [153] Thispaper aims at proposing for model based design of systemsand CPS a new vista on contracts In the next section wepropose an all encompassing meta theory of contracts
V A MATHEMATICAL META-THEORY OF CONTRACTS
In software engineering meta-models are ldquomodels of mod-elsrdquo ie formal ways of specifying a certain family ofmodels Similarly we call here meta-theory a way to specifya particular family of theories In this section we proposea meta-theory of contracts This meta-theory is summarizedin Table IV It comes as a few primitive concepts on topof which derived concepts can be built A number of keyproperties can be proved about the resulting frameworkThese properties demonstrate that contracts are a convenientparadigm to support incremental development and independentimplementability in system design The meta-theory will serveas a benchmark for our subsequent review of concrete contracttheories
The meta-theory we develop here is novel There are veryfew attempts of that kind In fact the only ones we are awareof are the recent works by Bauer et al [22] and Chen et al [59]which follow a different (and complementary) approach Thediscussion of this work is deferred to the bibliographicalsection V-H
A Components and their composition
To introduce our meta-theory we start from a universe Mof possible components each denoted by the symbol M orE and a universe of their abstractions or contracts eachdenoted by the symbol C Our meta-theory does not presumeany particular modeling style neither for components nor forcontractsmdashwe have seen in Section IV an example of a (verysimple) framework for static systems More generally someframeworks may represent components and contracts with setsof discrete time or even continuous time traces other theoriesuse logics or state-based models of various kinds and so on
We assume a composition M1 timesM2 acting on pairs ofcomponents Component composition times is partially not to-
RR ndeg 8147
Contracts for System Design 25
Concept Definition and generic properties What depends on the particulartheory of contracts
Primitive
Component Components are denoted by M they can be open or closed How components are specified
Composabilityof components A type property on pairs of components (M1M2) How this type property is defined
Compositionof components
M1timesM2 is well defined if and only if M1 and M2 are composableIt is required that times is associative and commutative The definition of the composition
Environment An environment for component M is a componentE such that EtimesM is defined and closed
Derived
Contract A contract is a pair C = (EC MC ) where MC is a subsetof components and EC a subset of legal environments
Which family C of contractscan be expressed andhow they are expressedunless otherwise specifiedquantifying is implicitly over C isin C
Consistency C is consistent iff it has at least one component MC 6= empty How consistency is checked
Compatibility C is compatible iff it has at least one environment EC 6= empty How compatibility is checked
Implementation M |=M C if and only if M isinMCE |=E C if and only if E isinEC
How implementation is checked
Refinement Cprime C iff ECprime supe EC and MCprime subeMC Property 1 holds How refinement is checked
GLB andLUBof contracts
C1andC2 = Greatest Lower Bound (GLB) for we assume GLB existC1orC2 = Least Upper Bound (LUB) for we assume LUB exist
Property 2 holds
Whether and howGLB and LUB can beexpressed and computed
Compositionof contracts
C1otimesC2 is defined if M1 |=M C1M2 |=M C2
rArr (M1M2) composable
C1otimesC2 =andC
∣∣∣∣∣∣M1 |=M C1 and M2 |=M C2 and E |=E C
dArrM1 timesM2 |=M C and EtimesM2 |=E C1 and EtimesM1 |=E C2
Assumption 1 is in force Properties 3 4 and 5 holdSay that C1 and C2 are compatible if so is C1otimesC2
How composition isexpressed and computed
Quotient C1C2 =or C | C otimes C2 C1 Property 6 holds How quotient is
expressed and computed
Table IVSummary of the meta-theory of contracts We first list primitive concepts and then derived concepts introduced by the meta-theory
tally defined Two components that can be composed arecalled composable Composability of components is meantto be a typing property In order to guarantee that differentcomposable components may be assembled together in anyorder it is required that component composition times is asso-ciative and commutative Components that exhibit no meansfor interacting with the outside world are called closed othercomponents are open An environment for a component Mis another component E composable with M and such thatM times E is closed
B Contracts
In our primer of Section IV we have highlighted the im-portance of the legal environments associated with contractsfor which an implementation will operate satisfactorily At theabstract level of the meta-theory we make this explicit next
Definition 1 A contract is a pair C = (EC MC ) where
bull MC subeM is the set of implementations of C andbull EC subeM is the set of environments of C
For any pair (EM) isin EC times MC E is an environmentfor M Hence MtimesE must be well defined and closed Acontract possessing no implementation is called inconsistentA contract possessing no environment is called incompatibleWrite
M |=M C and E |=E C
to express that M isinMC and E isin EC respectivelyIn concrete theories of contracts both components and con-tracts are described in some finite (preferably concise) wayIn turn it is not true that every set Mprime subeM of componentscan be represented as Mprime = MC for some contract C andsimilarly for sets of environments To highlight this
we assume a family C of expressible contracts (5)
Only contracts belonging to this family can be consideredThis is made explicit in Table IV
C Refinement and conjunctionTo support independent implementability the concept of
contract refinement must ensure the following if contract Cprime
RR ndeg 8147
Contracts for System Design 26
refines contract C then any implementation of Cprime should 1)implement C and 2) be able to operate in any environment forC Hence the following definition for refinement preorder between contracts Cprime refines C written Cprime C if and onlyif MCprime sube MC and ECprime supe EC As a direct consequence thefollowing property holds which justifies the use of the termldquorefinementrdquo for this relation
Property 1 (refinement)1) Any implementation of Cprime is an implementation of C
M |=M Cprime rArrM |=M C and2) Any environment of C is an environment of Cprime
E |=E C rArr E |=E CprimeThe conjunction of contracts C1 and C2 written C1 and C2 isthe greatest lower bound (GLB) of these two contracts withrespect to refinement ordermdashwe assume such a GLB existsThe intent is to define this conjunction as the intersection ofsets of implementations and the union of sets of environmentsHowever due to (5) not every set of components is thecharacteristic set of a contract The best approximation consistsin taking the greatest lower bound for the refinement relationThe following immediate properties hold
Property 2 (shared refinement)1) Any contract that refines C1 and C2 also refines C1 and C2
Any implementation of C1 and C2 is a shared implementa-tion of C1 and C2 Any environment of C1 or C2 is anenvironment of C1 and C2
2) For C sube C a subset of contractsandC is compatible if
and only if there exists a compatible C isin C
The conjunction operation formalizes the intuitive notion of aldquoset of contractsrdquo or a ldquoset of requirementsrdquo
D Contract composition
The objective of contract composition is to ensure that1) composing respective implementations of each contract
yields an implementation for the composition and2) composing an environment for the resulting composition
with an implementation for C2 yields an environment forC1 and vice-versa
These two properties are essential in supporting top-downdesign by successive decompositions and refinements of con-tracts Contract composition C1 otimes C2 is thus defined on topof component composition as indicated in Table IV with thefollowing assumption in force throughout this meta-theory
Assumption 1 The following condition holds
C1 otimes C2 isin CC1otimesC2
(Note that this assumption is non trivial since it is not true foran arbitrary set C sube C that
andCisinC C isin C) The condition
for C1 otimes C2 to be defined is that every pair (M1M2) ofrespective implementations is composable so that M1 timesM2
is well definedmdashrecall that component composability is atyping property Consequently if E is an environment forM1timesM2 E is composable with both M1 and M2 and EtimesM1
is an environment for M2 and vice-versa Referring to the
formula defining C1 otimes C2 denote by CC1otimesC2 sube C the set ofcontracts specified in the brackets The following lemma willbe instrumental
Lemma 1 Let four contracts be such that Cprime1 C1Cprime2 C2 and C1 otimes C2 is well defined Then so is Cprime1 otimes Cprime2and CCprime1otimesCprime2 supe CC1otimesC2
Proof Since C1otimesC2 is well defined it follows that every pair(M1M2) of respective implementations of these contracts is acomposable pair of components Hence Cprime1otimesCprime2 is well definedaccording to the formula of Table IV Next since Cprime1 C1 andCprime2 C2 and using Assumption 1 M1 |=M Cprime1 and M2 |=M Cprime2implies M1 |=M C1 and M2 |=M C2 similarly E timesM2 |=E C1and EtimesM1 |=E C2 implies EtimesM2 |=E Cprime1 and EtimesM1 |=E Cprime2Therefore replacing in the big brackets defining the contractcomposition C1 by Cprime1 and C2 by Cprime2 can only increase the setCC1otimesC2 2
To conform to the usage we say that C1 and C2 arecompatible contracts if their composition C1 otimes C2 is definedand compatible in the sense of Table IV The followingproperties are a direct corollary of Lemma 1
Property 3 (independent implementability) For all con-tracts C1 C2 Cprime1 and Cprime2 if
1) C1 is compatible with C22) Cprime1 C1 and Cprime2 C2 hold
then Cprime1 is compatible with Cprime2 and Cprime1 otimes Cprime2 C1 otimes C2
Thus compatible contracts can be independently refined Thisproperty holds in particular if Cprime1 and Cprime2 are singletons
Corollary 1 Compatible contracts can be independentlyimplemented
Property 3 is fundamental particularly in top-down designTop-down incremental design consists in iteratively decom-posing a system-level contract C into sub-system contractsCi i isin I for further independent development To ensure thatindependent development will not lead to integration problemsit is enough to verify that
otimesiisinI Ci C We insist that since
contracts are purposely abstract and subsystems are not manythe composition of contracts Ci will not typically result in stateexplosion33
The following property is essential as it states that contractcomposition can be performed in any order and changesin architecture (captured by changes in parenthesizing) areallowed
Property 4 (associativity and commutativity) For all con-tracts C1 C2 C3 and C4 if C1 and C2 are compatible C3 andC4 are compatible and C1otimesC2 is compatible with C3otimesC4 thenC1 is compatible with C3 C2 is compatible with C4 C1 otimes C3is compatible with C2 otimes C4 and
(C1 otimes C2)otimes (C3 otimes C4) = (C1 otimes C3)otimes (C2 otimes C4) (6)
33 This is unlike in compositional verification where timesiisinIMi |=M Pis to be checked where Mi are detailed implementations and P is aproperty In this case the composition timesiisinIMi typically gives raise to stateexplosion Techniques have thus been proposed to verify such properties inan incremental way [176] [62] [98] [1] [121]
RR ndeg 8147
Contracts for System Design 27
Proof To shorten notations write C12 instead of C1 otimesC2 andsimilarly for any subset of 1 2 3 4 By Assumption 1 andthe associativity and commutativity of component composi-tion C1234 is characterized by the following two propertieswhere index i ranges over the set 1 4
Mi |=M Ci rArr M1times timesM4 |=M C1234
E |=E C1234 rArr Etimes (timesj 6=iMj) |=E Ci(7)
Observe that (7) is fully symmetric which proves (6) Nextusing the assumptions regarding compatibility we derive theexistence of at least one environment E satisfying the premiseof the second implication of (7) Since (7) is fully symmetricthis proves the conclusions of Property 4 regarding compati-bility 2
Property 5 (distributivity) If the following contract compo-sitions are all well defined then the following holds
[(C11 and C21)otimes (C12 and C22)] [(C11 otimes C12) and (C21 otimes C22)] (8)
Proof By Lemma 1 C(C11andC21)otimes(C12andC22) supe CC11otimesC12 Taking the GLB of these two sets thus yields[(C11 and C21)otimes (C12 and C22)] (C11 otimes C12) and similarlyfor (C21 otimes C22) Thus (8) follows 2
The use of distributivity is best illustrated in the followingcontext Suppose the system under design decomposes intotwo sub-systems labeled 1 and 2 and each subsystem hastwo viewpoints associated with it labeled by another indexwith values 1 or 2 Contract (C11 and C21) is then the contractassociated with sub-system 1 and similarly for sub-system 2Thus the left hand side of (8) specifies the set of imple-mentations obtained by first implementing each sub-systemindependently and then composing these implementationsProperty 5 states that by doing so we obtain an implemen-tation of the overall contract obtained by first getting thetwo global viewpoints (C11 otimes C12) and (C21 otimes C22) andthen taking their conjunction This property supports inde-pendent implementation for specifications involving multipleviewpoints Observe that only refinement not equality holdsin (8)
E Quotient
The quotient of two contracts is defined in Table IV It isthe adjoint of the product operation otimes in that C1C2 is themost general context C in which C2 refines C1 It formalizesthe practice of ldquopatchingrdquo a component to make it behavingaccording to another specification From its definition inTable IV we deduce the following property
Property 6 (quotient) The following holds
C C1C2 hArr C otimes C2 C1
Proof Immediate from the definition 2
F Discussion
By inspecting Table IV the different notions can be classi-fied into the following two categories
bull Primitive notions that are assumed by the meta-theoryThis category comprises components component com-posability and composition
bull Derived notions comprise contract refinement conjunc-tion composition and quotient consistency and com-patibility for contracts The derived notions follow fromthe primitive ones through set theoretic non effectivedefinitions
The meta-theory offers by itself a number of fundamentalproperties that underpin incremental development and inde-pendent implementability Concrete theories will offer defini-tions for the primitive notions as well as effective means toimplement (or sometimes approximate) the derived notionsObservers and then abstract interpretation we develop nextprovide generic approaches to recover effectiveness
G Observers
Notion Observer
C = (EC MC )(bEC b
MC)
C = C1andC2 bEC = bE
C1 or bEC2 b
MC = bM
C1 and bMC2
C = C1orC2 bEC = bE
C1 and bEC2 b
MC = bM
C1 or bMC2
C = C1otimesC2bEC(E) =
bMC1 (M1) and bM
C2 (M2)
dArrbEC2 (EtimesM1) and bE
C1 (EtimesM2)
bMC(M1 timesM2) = bM
C1 (M1) and bMC2 (M2)
Table VMirroring the algebra of contracts with observers
A typical obstacle in getting finite (or more generallyeffective) representations of contracts is the occurrence ofinfinite data types and functions having infinite domains Thesecan be dealt with by using observers which originate from thebasic notion of test for programs
Definition 2 Let C be a contract An observer for Cis a pair (bE
C bMC) of non-deterministic boolean functions
M 7rarr F T called verdicts such that
bEC(M) outputs F =rArr M 6isin ECbMC(M) outputs F =rArr M 6isin MC
(9)
The functions M 7rarr bEC(M) and M 7rarr bM
C(M) being bothnon-deterministic accounts for the fact that the outcome of atest depends on the stimuli from the environment and possiblyresults from internal non-determinism of the tested componentitself Note the single-sided implication in (9) which reflectsthat tests only provide semi-decisions
Relations and operations of the meta-theory can be mirroredby relations and operations on observers as explained inTable Vmdashwe omit the formulas for the quotient as semi-effectiveness of testing makes it useless Despite GLB andLUB can be mirrored using the formulas of the table nothingcan be said about the relationship of observers for contractsbased on the fact that they are in a refinement ordering Dually
RR ndeg 8147
Contracts for System Design 28
nothing can be inferred in terms of their refinement fromsuch a relationship between the observers Still the followingweaker result holds which justifies how GLB and LUB arerepresented using observers in Table V
Lemma 2 Let (bEC b
MC) be an observer for C and let Cprime C
Then any pair (bE bM) satisfying bE ge bEC and bM le bM
C is anobserver for CprimeThe following immediate results hold regarding consistencyand compatibility
Lemma 31) If bE
C(E) outputs F for all tested environment E then Cis incompatible
2) If bMC(M) outputs F for all tested component M then C
is inconsistent
To summarize Definition 2 provides semi-decision proceduresto check whether a component or an environment are validfor a contract Lemma 3 provides semi-decision proceduresfor checking consistency and compatibility Finally Table Vindicates how operations from the contract algebra can bereflected into operations on observers
Due to the need for exercising all components or environ-ments using observers for checking consistency or compat-ibility is still non-effective For concrete theories exhibitingsome notion of ldquostrongestrdquo environment or component for theconsidered contract a reinforcement of Lemma 3 will ensureeffectiveness
In Section VI where concrete theories are reviewed weindicate for each theory how observers can be constructedand how Lemma 3 specializes
H Bibliographical note
Abstract contract theories and features of our presen-tation Our presentation here is new There is only a smallliterature providing an abstract formalization of the notion ofcontracts The only attempts we are aware of are the recentworks by Bauer et al [22] and Chen et al [59] albeit withdeeply different and complementary approaches
The publication [22] develops an axiomatization of thenotion of specification from which contracts can be derivedin a second step More precisely specifications are abstractentities that obey the following list of axioms it possesses arefinement relation that is a preorder which induces a notionof equivalence of specifications and a parallel compositionthat is associative commutative (modulo equivalence) andmonotonic with respect to refinement It is assumed thatif two specifications possess a common lower bound thenthey possess a greatest lower bound A quotient is alsoassumed which is the residuation of the parallel composi-tion From specifications contracts are introduced as pairs ofspecifications very much like AssumeGuarantee contracts wedevelop in Section VII are pairs of assertions Sets of legalenvironments and sets of implementations are associated tocontracts Finally modal contracts are defined by borrowingideas from modal specifications we discuss in Section VIIIThis abstract theory nicely complements the one we develop
here in that it shows that both specifications and contracts canbe defined as primitive entities and be used to build moreconcrete theories
The work [59] develops the concept of declarative speci-fication which consists of a tuple P = (ΣinΣout TΣ FΣ)where Σin and Σout are input and output alphabets of actionsΣ = Σin ] Σout and TΣ FΣ sube Σlowast such that FΣ sube TΣ
are sets of permissible and inconsistent traces respectivelymdashthis approach find its origins in earlier work by Dill [81]and Negulescu [143] Outputs are under the control of thecomponent whereas inputs are issued by the environmentThus after any successful interaction between the componentand the environment the environment can issue any input αeven if it will be refused by the component If α is refusedby the component after the trace t isin TΣ tα isin FΣ is aninconsistent trace capturing that a communication mismatchhas occurred An environment is called safe if it can preventa component from performing an inconsistent trace For Qto be used in place of P it is required that Q must existsafely in any environment that P can exist in safely this isthe basis on which refinement is defined Alphabet extensionis used by which input actions outside the considered alphabetare followed by an arbitrary behavior for the declarativespecification A conjunction is proposed that is the GLB forrefinement order A parallel composition is proposed whichis monotonic with respect to refinement A quotient is alsoproposed which is the residuation of parallel composition
Observers Observers being related to the wide areaof software and system testing have been widely studiedA number of existing technologies support the design ofobservers and we review some of them now
Synchronous languages [28] [100] [30] are a formalism ofchoice in dealing with observers The family of SynchronousLanguages comprises mainly the imperative language Es-terel [92] [84] and the dataflow languages Lustre [144] andSignal [157] The family has grown with several childrenoffering statecharts-like interfaces and blending dataflow andstatechart-based styles of programming such as in Scade V634Synchronous languages support only systems governed bydiscrete time not systems with continuous time dynamics(ODEs) They benefit from a solid mathematical semantics Asa consequence executing a given program always yields thesame results (results do not depend on the type of simulator)The simulated or analysed program is identical to the codefor embedding Thanks to these unique features specificationscan easily be enhanced with timing andor safety viewpointsThe RT-Builder35 tool on top of Signal is an example offramework supporting the combination of functional and tim-ing viewpoints while analyzing an application deployed overa virtual architecture (see Section IV-D4) The widely usedSimulinkStateflow36 tool by The Mathworks offers similarfeatures One slight drawback is that its mathematical seman-
34httpwwwesterel-technologiescomproductsscade-suite35httpwwwgeensoftcomenarticlertbuilder36httpwwwmathworkscomproductssimulink
RR ndeg 8147
Contracts for System Design 29
tics is less firmly defined (indeed results of executions maydiffer depending on the code executed simulation or generatedC code) On the other hand Simulink supports continuoustime dynamics in the form of systems of interconnectedODEs (Ordinary Differential Equations) thus supporting themodeling of the physical part of the system Using Simulinkpossibly enhanced with SimScape37 allows for includingphysical system models in observers eg as part of the systemenvironment The same comment holds regarding Modelica38
Actually observers have been proposed and advocated in thecontext of Lustre and Scade [101] [102] [103] Esterel [45]and Signal [137] [138] More precisely Scade advocatesexpressing tests using Scade itself Tests can then easily beevaluated at run time while executing a Scade program Toconclude observe that synchronous languages and formalismsdiscussed in this section are commercially available and widelyused
Another good candidate for expressing observers is theProperty Specification Language (PSL) PSL is an industrialstandard [151] [86] [85] for expressing functional (or behav-ioral) properties targeted mainly to digital hardware designWe believe that PSL is indeed very close to several lessestablished but more versatile formalisms based on restrictedEnglish language that are used in industrial sectors otherthan digital hardware eg in aeronautics automobile orautomation Consider the following property
ldquo For every sequence that starts with an a imme-diately followed by three occurrences of b and endswith a single occurrence of c d holds continuouslyfrom the next step after the end of the sequence untilthe subsequent occurrence of e rdquo
This property is translated into its PSL version
[]ab[3]c |=gt (d until e)
PSL is a well-suited specification language for expressingfunctional requirements involving sequential causality of ac-tions and events Although we are not aware of the usageof PSL in the particular context of contract-based design wemention the tool FoCS [2] that translates PSL into checkersthat are attached to designs The resulting checker takes theform of an observer if the PSL specification is properlypartitioned into assumption and guarantee properties More re-cently PSL was also used for the generation of transactors thatmay adapt high-level requirements expressed as transaction-level modules to the corresponding register-transfer implemen-tation [18] [17] It follows that the existing tool support forPSL makes this specification language suitable in the contract-based design using observers We note that the availabilityof formal analysis tools allows the design to be checkedexhaustivelymdashthis is of course at the price of restrictionson data types Another benefit in using PSL as an observer-based interface formalism is an existing methodology for user-guided automated property exploration built around this lan-
37httpwwwmathworkscomproductssimscape38httpswwwmodelicaorg
guage [158] [42] that is supported by the tool RATSY [43]As previously stated PSL is built on top of LTL and regularexpressions One can thus express liveness properties in PSLwhich are not suitable for online monitoring There are twoorthogonal ways to avoid this potential issue (1) restrictingthe PSL syntax to its safety fragment or (2) adapting the PSLsemantics to be interpreted over finite traces [87] A survey ofusing PSL in runtime verification can be found in [85]
Another relevant formalism for building observers consistsof the Live Sequence Charts (LSC) [64] [107] [105] LSCare a graphical specification language based on scenarios thatis an extension of Message Sequence Charts (MSC)39 Atypical LSC consists of a prechart and a main chart Thesemantics is that whenever the prechart is satisfied in a run ofthe system eventually the main chart must also be satisfiedPrecharts should not be confused with assumptions howeverthey are rather sort of ldquoprerequisitesrdquo LSCs are multi-modalin that any construct in the language can be either cold orhot with a semantics of ldquomay happenrdquo or ldquomust happenrdquorespectively If a cold element is violated (say a conditionthat is not true when reached) this is considered a legalbehavior and some appropriate action is taken Violation ofa hot element however is considered a violation of thespecification and is not allowed to happen in an executionLSC are executable The execution of a set of LSCs is calledplay out by the authors [107] Play out is useful for checkingan LSC specification against a property [66] LSC can beused as (expressive) tests to monitor the execution of a designover non-terminating runs While doing so the same rules asabove are applied except that the design controls the emissionof events and the LSC specification is used to react in caseof violation of the specification This is manifested by theabsence of rules explaining the occurrence of some event atrun-time This procedure is called play in by the authors Toconclude LSCs are well suited to express observers
VI PANORAMA OF CONCRETE THEORIES
For the coming series of sections where concrete contracttheories are reviewed the reader is referred to Table IV ofSection V where the meta-theory of contracts is developedWe will illustrate how various concrete contract theories canbe developed by specializing the meta-theory
VII PANORAMA ASSUMEGUARANTEE CONTRACTS
Our static example of Section IV provided an exampleof contract specified using Assumptions and Guarantees As-sumeGuarantee contracts (AG-contracts) Assumptions char-acterize the valid environments for the considered compo-nent whereas the Guarantees specify the commitments ofthe component itself when put in interaction with a validenvironment Various kinds of AG-contract theories can beobtained by specializing the meta-theory in different waysVariations concern how the composition of components isdefined We will review some of these specialization and relatethem to the existing literature
39httpwwwsdl-forumorgMSCindexhtm
RR ndeg 8147
Contracts for System Design 30
In general AG contract theories build on top of componentmodels that are assertions ie sets of behaviors or tracesassigning successive values to variables As we shall seedifferent kinds of frameworks for assertions can be consid-ered including asynchronous frameworks of Kahn ProcessNetworks (KPN) [117] and synchronous frameworks in whichbehaviors are sequences of successive reactions assigningvalues to the set of variables of the considered system We firstdevelop the theory for the simplest case of a fixed alphabetThen we develop the other cases
A Dataflow AG contracts
For this simplest variant all components and contractsinvolve a same alphabet Σ of variables possessing identical40
domain DWith this simplification a component M identifies with an
assertion
P sube Σ 7rarr Dlowast cupDω (10)
ie a subset of the set of all finite or infinite behaviors overalphabet Σ such a behavior associates to each symbol x isin Σa finite or infinite flow of values The flows are not mutuallysynchronized and there is no global clock or logical step Wediscuss in Section VII-D variants of this framework with moresynchronous models of behaviors For convenience we feelfree to use both set theoretic and boolean notations for therelations and operations on assertions
Two components are always composable and we definecomponent composition by the intersection of their respectiveassertions
P1timesP2 = P1andP2 (11)
Formulas (10) and (11) define a framework of asynchronouscomponents with no global clock and no notion of reac-tion Instead a component specifies a relation between thehistories of its different flows When input and output portsare considered as in Section VII-B and components are in-putoutput functions we obtain the model of Kahn ProcessNetworks [117] widely used for the mapping of synchronousprograms over distributed architectures [159] [160]
Definition 3 A contract is a pair C = (AG) of assertionscalled the assumptions and the guarantees The set EC of thelegal environments for C collects all components E such thatE sube A The set MC of all components implementing C isdefined by AtimesM sube GThus any component M such that M le G or notA is animplementation of C and MC = G or notA is the maximalimplementation Observe that two contracts C and Cprime withidentical input and output alphabets identical assumptionsand such that Gprime or notAprime = G or notA possess identical sets ofimplementations MC =MCprime According to our meta-theorysuch two contracts are equivalent Any contract C = (AG)is equivalent to a contract in saturated form (AGprime) such that
40This is only an assumption intended to simplify the notations It is by nomeans essential
Gprime supe notA or equivalently G or A = T the true assertionto exhibit Gprime just take Gprime = G or notA A saturated contractC = (AG) is consistent if and only if G 6= empty and compatibleif and only if A 6= empty
Next for C and Cprime two saturated contracts with identicalinput and output alphabets
refinement Cprime C holds iffAprimegeAGprimeleG (12)
Conjunction follows from the refinement relation for C1 andC2 two saturated contracts with identical input and outputalphabets C1 and C2 = (A1orA2 G1andG2)
Focus now on contract composition C = C1 otimes C2 for twosaturated contractsmdashthis is no loss of generality as we haveseen Contract composition instantiates through the followingformulas cf (1) in Section IV
G = G1andG2
A = max
A∣∣∣∣∣∣AandG2rArrA1
andAandG1rArrA2
(13)
which satisfies Assumption 1 of the meta-theory If further-more contracts are saturated then (13) reformulates as theformulas originally proposed in [29]
G = G1 andG2
A = (A1 andA2) or not(G1 andG2)(14)
Observe that the so obtained contract (AG) is saturatedG orA = (G1 andG2) or (A1 andA2) or not(G1 andG2) = T
No quotient operation is known for AssumeGuaranteecontracts
We finish this section by observing that the two contractsC1 and Cprime1 of Section IV-A1 satisfy Cprime1 C1 according to thetheory of this section guarantees are identical but assumptionsare relaxed
B Capturing exceptions
Referring to the primer of Section IV-A1 and its staticsystem example dividing by zero may raise an exception Forinstance a careless designer may consider instead of M1 aslight variation M prime1 of it where the behaviors are only partiallydefined
M prime1 behaviors (y 6= 0rarr z = xy)
leaving what happens if a value 0 is submitted for y unspeci-fied In practice y = 0 would raise an exception leading to anunpredictable outcome and possibly a crash unless exceptionhandling is offered as a rescue by the execution platform
In this section we show how a mild adjustment of ourtheory of AG contracts can capture exceptions and theirhandling To simplify we develop this again for the case ofa fixed alphabet Σ We only present the add-ons with respectto the previous theories the parts that remain unchanged arenot repeated
Since exceptions are undesirable events caused by the com-ponent itself and not by its inputsmdashfor our simple example the
RR ndeg 8147
Contracts for System Design 31
exception is the improper handling of the division by zeromdashweneed to include inputs and outputs as part of our frameworkfor components
A component is thus a tuple M = (ΣinΣout P ) whereΣ = Σin cup Σout is the decomposition of alphabet Σ intoits inputs and outputs and P sube (Σ 7rarr (Dlowast cupDω)) is anassertion Whenever convenient we shall denote by Σin
M QM PM etc the items defining component M Components M1
and M2 are composable if Σout1 cap Σout
2 = empty If so thenM1timesM2 = (ΣinΣout P ) is well defined with Σout =Σout
1 cup Σout2 Σin = Σminus Σout and P = P1 cap P2
Let us now focus on exceptions To capture improper re-sponse (leading to a ldquocrashrdquo) we distinguish a special elementfail isin D We assume that crash is not revertible ie inany behavior of the component any variable remains at failwhen it reaches that value Referring to the static example ofSection IV we would then set x0 = fail for any x We arenow ready to formalize what it means for a component to befree of exception
Definition 4 A component M is free of exception if1) It accepts all inputs
prΣinM
(PM ) = ΣinM 7rarr (DlowastcupDω)
2) It does not cause by itself the occurrence of fail in itsbehaviors for any behavior σ isin PM if the projectionprΣin
M(σ) of σ to the input alphabet Σin
M does not involvefail then neither does σ
Exception freeness defined in this way is such that if M1 andM2 are both composable and free of exception then M1timesM2
is also free of exception Hence we are free to restrict ouruniverse of components to exception free componentsmdashthusDefinition 4 defines our family of components AG contractsare re-defined accordingly
Definition 5 A contract is a tuple C = (ΣinΣout AG)where Σin and Σout are the input and output alphabets andA and G are assertions over Σ called the assumptions andthe guarantees The set EC of the legal environments for C areall free of exception components E such that Σin
E = ΣoutC
ΣoutE = Σin
C and PE sube A The set MC of all componentsimplementing C is defined by M is free of exception Σin
M =ΣinC and Σout
M = ΣoutC and PEtimesM sube G for every environment
E of CFocus now on the issue of consistency and compatibility forcontracts The following holds
Property 7 Let C = (ΣinΣout AG) be a contract satis-fying the following conditions
prΣinC
(G) = ΣinM 7rarr (DlowastcupDω) (15)
prΣoutC
(A) = ΣoutM 7rarr (DlowastcupDω) (16)
fail does not occur in G andA (17)
Then C is consistent and compatibleProof By condition (15) the component M = (ΣinΣout G)satisfies condition 4 of Definition 4 It may not satisfy condi-tion 2 however To achieve this we must modify in M the
behaviors not belonging to A to avoid fail to occur PreservingM on A will ensure that implementation of C is preservedTo get M prime replace any behavior σ isin G and notA by a behaviorσprime such that prΣin
C(σprime) = prΣin
C(σ) and prΣout
C(σprime) 63 fail
Component M prime obtained in this way is free of exception andimplements C showing that C is consistent Consider next thecomponent E = (ΣoutΣin A) If E is free of exception thenit is an environment for C If this is not the case then we canmodify E on AandnotG as we did for obtaining M prime This yieldsan environment Eprime for C showing that C is compatible 2
Conditions (15) and (16) express that assumptions andguarantees are both input enabled Condition (17) is the keyone Observe that now contract Cprime1 of Section IV-A1 isinconsistent since it has no implementationmdashimplementationsmust be free of exception In turn contract C1 is consistentThis is in contrast to the theory of Section VII-A whereboth contracts were considered consistent (crashes were notruled out) Indeed contract C1 of Section IV-A1 satisfies theconditions of Property 7 whereas Cprime1 does not Addressingexceptions matters
C Dealing with variable alphabets
Since contracts aim at capturing incomplete designs wecannot restrict ourselves to a fixed alphabetmdashit is not known inadvance what the actual alphabet of the complete design willbe Thus the simple variants of Sections VII-A and VII-B haveno practical relevance and we must extend them to dealingwith variable alphabets In particular components will now bepairs M = (ΣM PM ) where ΣM is the alphabet of M andPM is an assertion over ΣM Similarly contracts are triplesC = (ΣC AC GC) where assumptions AC and guarantees GCare assertions over alphabet ΣC
Key to dealing with variable alphabet this is the operationof alphabet equalization that we introduce next For P an as-sertion over alphabet Σ and Σprime sube Σ we consider its projectionprΣprime(P ) over Σprime which is simply the set of all restrictionsto Σprime of all behaviors belonging to P We will also need theinverse projection prminus1
Σprimeprime (P ) for Σprimeprime supe Σ which is the set ofall behaviors over Σprimeprime projecting to Σ as behaviors of P For(Σi Pi) i = 1 2 we call alphabet equalization of (Σ1 P1)and (Σ2 P2) the two assertions (Σprminus1
Σ (Pi)) i = 1 2 whereΣ = Σ1 cup Σ2
We also need to define alphabet equalization when thealphabet Σ decomposes as Σ = Σin ] Σout Equalizing theabove decomposition to a larger alphabet Σprimeprime supe Σ yieldsΣprimeprimeout = Σout whence Σprimeprimein = Σprimeprime Σprimeprimeout follows
Alphabet equalization serves as a preparation step to reusethe framework of Section VII-A when alphabets are variable
This being defined all operations and relations introducedin Section VII-A are extended to the case of variable alphabetsby 1) applying alphabet equalization to the involved assertionsand 2) reusing the operation or relation as introduced inSection VII-A
As pointed out in [29] this generalization yields a contracttheory that is a valid instantiation of the meta-theory (up tothe missing quotient) It is not satisfactory from the practical
RR ndeg 8147
Contracts for System Design 32
standpoint however The reason is that the conjunction oftwo contracts with disjoint alphabets yields a trivial assump-tion T which is very demandingmdashany environment must beaccommodatedmdashand does not reflect the intuition (more onthis will be discussed in Section VIII-D
To summarize Sections VII-A VII-B and VII-C togetherdefine a framework for asynchronous AssumeGuarantee con-tracts where components are of Kahn Process Network type
D Synchronous AG contracts
We obtain variants of this framework of AssumeGuaranteecontracts by changing the concrete definition of what anassertion is and possibly revisiting what the component com-position is We can redefine assertions as
P sube (Σ 7rarr D)lowast cup (Σ 7rarr D)ω (18)
Compare (18) with (10) In both cases assertions are sets ofbehaviors With reference to (10) behaviors were tuples offinite or infinite flows one for each symbol of the alphabetIn contrast in (18) behaviors are finite or infinite sequencesof reactions which are the assignment of a value to eachsymbol of the alphabet By having a distinguished symbolperp isin D to model the absence of an actual data we getthe multiple-clocked synchronous model used by synchronouslanguages [30] Definition (18) for assertions correspond to thesynchronous model of computation whereas (10) correspondsto the Kahn Process Network type of model [117] [142] Thematerial of Sections VII-A VII-B and VII-C can be adaptedto this new model of component composition thus yielding aframework of synchronous AssumeGuarantee contracts
E Observers
The construction of observers for this case is immediate Wedevelop it for the most interesting case in which exceptions arehandled see Sections VII-A and VII-B Let P be an assertionaccording to (10) P defines a verdict bP by setting
bP (σ) = T if and only if σ isin P (19)
Observers must return their verdict in some finite amount oftime Hence on-line interpretation based on Definition 3 isappropriate With this interpretation for C = (ΣinΣout AG)a contract its associated observer is obtained as follows withreference to Definition 2
bull bEC(E) is performed by drawing non-deterministically a
behavior σ of E and then evaluating bA(σ)bull bMC(M) is performed by drawing non-deterministically a
behavior σ of M and then evaluating bA(σ)rArr bM (σ)
Lemma 3 for generic observers specializes to the followingeffective semi-decision procedure
Lemma 4
1) If bA outputs F then C is incompatible2) If bA rArr bG outputs F then C is inconsistent
F Discussion
AssumeGuarantee contracts are a family of instantiationsof our meta-theory This family is flexible in that it canaccommodate different models of communication and differentmodels of exceptions AssumeGuarantee contracts are anadequate framework for use in requirements capture Indeedrequirements are naturally seen as assertions When categoriz-ing requirements into assumptions (specifying the context ofuse of the system under development) and guarantees (that thesystem offers) formalizing the resulting set of requirements asan AG contract seems very natural
Regarding exceptions the special value fail that we intro-duced to capture exceptions is not something that is given inpractice Value fail may subsume various run time errors Al-ternatively for the synchronous AssumeGuarantee contractsfail can capture the failure of a component to be input enabled(able in each reaction to accept any tuple of inputs)
In its present form the framework of AssumeGuaranteecontracts (synchronous or asynchronous) suffers from theneed to manipulate negations of assertions an operation thatis generally not effective except if the framework is restrictedto finite state automata and finite alphabets of actions Forgeneral frameworks using observers or abstract interpretationcan mitigate this in part
G Bibliographical note
By explicitly relying on the notions of Assumptions andGuarantees AG-contracts are intuitive which makes themappealing for the engineer In AG-contracts Assumptions andGuarantees are just properties The typical case is when theseproperties are languages or sets of traces which includes theclass of safety properties [122] [58] [136] [14] [61] AG-contracts were advocated by the SPEEDS project [29] Theywere further experimented in the framework of the CESARproject [63] with the additional consideration of weak andstrong assumptions The theory developed in [29] turns outto be closest to this presentation still exceptions were nothandled in [29] The presentation developed in this paperclarifies the design choices in AG-contract theories
Inspired by [126] another form for AG-contract was pro-posed by [97] [99] when designs are expressed using theBIP programming language [41] [174] To achieve separatedevelopment of components and to overcome the problemsthat certain models have with the effective computation ofthe operators the authors avoid using parallel compositionotimes of contracts Instead they replace it with the concept ofcircular reasoning which states as follows in its simplestform if design M satisfies property G under assumptionA and if design N satisfies assumption A then M times Nsatisfies G When circular reasoning is sound it is possibleto check relations between composite contracts based ontheir components only without taking expensive compositionsIn order for circular reasoning to hold the authors deviserestricted notions of refinement under context and show howto implement the relations in the contract theory for the BIP
RR ndeg 8147
Contracts for System Design 33
framework Compatibility is not addressed and this proposaldoes not consider conjunction
Regarding extensions a notion of contract for real-timeinterfaces is proposed in [40] Sets of tasks are associated tocomponents which are individually schedulable on a processorAn interface for a component is an ω-language containing alllegal schedules Schedulability of a set of components on asingle processor then corresponds to checking the emptinessof their intersection The interface language considered isexpressive enough to specify a variety of requirements likeperiodicity the absence or the presence of a jitter etc An as-sumeguarantee contract theory for interfaces is then developedwhere both assumptions and guarantees talk about boundson the frequency of task arrivals and time to completionsDependencies between tasks can also be captured Refinementand parallel product of contracts are then defined exactly asin the SPEEDS generic approach
In [145] a platform-based design methodology that usesAG analog contracts is proposed to develop reliable ab-stractions and design-independent interfaces for analog andmixed-signal integrated circuit design Horizontal and verti-cal contracts are formulated to produce implementations bycomposition and refinement that are correct by constructionThe effectiveness of the methodology is demonstrated on thedesign of an ultra-wide band receiver used in an intelligenttire system an on-vehicle wireless sensor network for activesafety applications
AG-contracts have been extended to a stochastic setting byDelahaye et al [75] [76] [77] In this work the implementa-tion relation becomes quantitative More precisely implemen-tation is measured in two ways reliability and availabilityAvailability is a measure of the time during which a systemsatisfies a given property for all possible runs of the system Incontrast reliability is a measure of the set of runs of a systemthat satisfy a given property Following the lines of the contracttheories presented earlier satisfaction is assumption-dependentin the sense that runs that do not satisfy the assumptions areconsidered to be ldquocorrectrdquo the theory supports refinementstructural composition and logical conjunction of contractsand compositional reasoning methods have been proposedwhere the stochastic or non-stochastic satisfaction levels canbe budgeted across the architecture For instance assume thatimplementation Mi satisfies contract Ci with probability αifor i = 1 2 then the composition of the two implementationsM1timesM2 satisfies the composition of the two contracts C1otimesC2
with probability at least α1 + α2 minus 1Features of our presentation This presentation of AG-
contracts is new in may respects For the first time it iscast into the meta-theory of contracts with the advantage ofclarifying the definition of refinement and parallel compositionof contractsmdashthis involved some hand waving in the originalwork [29] Also this allowed us to handle exceptions properly
VIII PANORAMA INTERFACE THEORIES
Interface theories are an interesting alternative to As-sumeGuarantee contracts They aim at providing a merged
specification of the implementations and environments associ-ated to a contract via the description of a single entity calledan interface We review some typical instances of interfacetheories with emphasis on interface automata and modalinterfaces Interface theories generally use (a mild variation of)Lynch InputOutput Automata [135] [134] as their frameworkfor components and environments As a prerequisite we thusrecall the background on InputOutput Automata io-automatafor short
A Components as io-automataAn io-automaton is a tuple M = (ΣinΣout Q q0rarr)
wherebull Σin and Σout are disjoint finite input and output alpha-
bets set Σ = Σin cup Σoutbull Q is a finite set of states and q0isinQ is the initial statebull rarr sube QtimesΣtimesQ is the transition relation as usual we
write q αminusrarr qprime to mean (q α qprime) isin rarr and qαminusrarr to
indicate the existence of a qprime such that q αminusrarr qprimeBy concatenation transition relation rarr extends to a relationrarrlowast on Q times Σlowast times Q where Σlowast is the set of all finite wordsover Σ Say that a state qprime is reachable from q if there existssome word m such that q mminusrarrlowast qprime To considerably simplifythe development of the theory we restrict ourselves to
deterministic io-automata ie such thatq
αminusrarr q1 and q αminusrarr q2 implies q2 = q1(20)
Two io-automata M1 and M2 having identical alphabet Σare composable if the usual inputoutput matching conditionholds Σout
1 capΣout2 = empty and their composition M = M1timesM2
is given by
Σin = Σin1 cap Σin
2
Σout = Σout1 cup Σout
2
Q = Q1 timesQ2 and q0 = (q10 q20)
and the transition relation rarr is given by
(q1 q2)αminusrarr (qprime1 q
prime2) iff qi
αminusrarri qprimei i = 1 2
An io-automaton is said closed whenever Σin = empty and openotherwise For Mi i = 1 2 two io-automata and two statesqi isin Qi say that q1 simulates q2 written q2leq1 if
forallα qprime2 such that q2αminusrarr2 qprime2 rArr
q1
αminusrarr1 qprime1
and qprime2leqprime1(21)
Say that
M1 simulates M2 written M2leM1 if q20leq10 (22)
Observe that simulation relation (2122) does not distinguishinputs from outputs neither it distinguishes the componentfrom its environment It is the classical simulation relationmeant for closed systems Due to condition (20) of determin-ism simulation coincides with language inclusion
Variable alphabet is again dealt with using the mechanismof alphabet equalization For M = (ΣinΣout Q q0rarr) anio-automaton and Σprime sup Σ we define
MuarrΣprime
=(Σin cup (Σprime Σ)Σout Q q0rarrprime
)RR ndeg 8147
Contracts for System Design 34
whererarrprime is obtained by adding torarr for each state and eachadded action a self-loop at this state labeled with this action
Componentsmdashand consequently environmentsmdashfor use ininterface theories will be receptive io-automata (also termedinput enabled) ie they should react by proper response toany input stimulus in any state41
M is receptive iff forallq isin Qforallα isin Σin qαminusrarr (23)
Receptiveness is stable under parallel composition
B Interface Automata with fixed alphabet
For reasons that will become clear later we restrict thepresentation of interface automata to the case of a fixedalphabet Σ We begin with the definition of Interface Automatawhich are possibly non-receptive io-automata Moreover wegive their interpretation as contracts according to the meta-theory
Definition 6 An Interface Automaton is a tuple C =(ΣinΣout Q q0rarr) where ΣinΣout Qrarr are as inio-automata
The initial state q0 however may not satisfy q0isinQ If q0isinQholds Interface Automaton C defines a contract by fixing apair (EC MC ) as followsbull The set EC of the legal environments for C collects all
components E such that1) Σin
E = Σout and ΣoutE = Σin Thus E and C seen as
io-automata are composable and E timesC is closed2) For any output action α isin Σin of environment E
such that qEαminusrarrE and any reachable state (qE q)
of E times C then (qE q)αminusrarrEtimesC holds
There exists a unique maximal environment EC isin EC inthat EC timesC simulates EtimesC in the sense of (22) for anyE isin EC EC = (ΣoutΣin Q cup gt q0rarrEC ) where(a) the restriction to Qtimes ΣtimesQ of transition relationrarrEC coincides with rarr
(b) forallq isin Q q αminusrarrEC gt holds if and only if not[qαminusrarr ]
and α isin Σout(c) gt αminusrarrEC gt holds for any α isin Σ
bull The setMC of the implementations of C collects all com-ponents M such that io-automaton C simulates ECtimesMin the sense of (22)
Condition 2) means that environment E is only willing toemit an output if it is accepted as an input by C in thecomposition E times C Regarding the existence and uniquenessof EC observe first that conditions (a) and (b) together implythat EC is receptive Also by (a) and (b) EC times C is strictlyidentical with (emptyΣ Q q0rarr) ie it is obtained from Cseen as an io-automaton by simply turning inputs to outputsConsequently Condition 2) holds and thus EC isin EC By (b)and (c) EC is maximal
The above definition of Interface Automata is heterodoxcompare with the original references [72] [5] Definition 6
41In fact receptiveness is assumed in the original notion of io-automatonby Nancy Lynch [135] [134] We use here a relaxed version of io-automatonfor reasons that will become clear later
introduces the two sets EC and MC whereas no notionof implementation or environment is formally associated toan Interface Automaton in the original definition Also thehandling of the initial state is unusual Failure of q0isinQ tohold typically arises when the set of states Q is emptyOur Definition 6 allows to cast Interface Automata in theframework of the meta-theory of Table IV
Corresponding relations and operations must be instantiatedand we do this next As a first immediate result
Lemma 5 q0 isin Q is the necessary and sufficient conditionfor C to be both consistent and compatible in the sense of themeta-theory ie EC 6= empty and MC 6= empty
Refinement and conjunction Contract refinement as de-fined in Table IV is equivalent to alternate simulation [10]defined as follows for Ci i = 1 2 two contracts say that tworespective states qi i = 1 2 are in alternate simulation writtenq2q1 if
forallα isin Σout2 qprime2 st q2
αminusrarr2 qprime2 rArr
α isin Σout
1
q1αminusrarr1 qprime1
qprime2qprime1
forallα isin Σin1 q
prime1 st q1
αminusrarr1 qprime1 rArr
α isin Σin
2
q2αminusrarr2 qprime2
qprime2qprime1
(24)
Say that C2 refines C1 written C2C1 if q20q10 The firstcondition of (24) reflects the inclusionMC2
subeMC1 whereas
the second condition of (24) reflects the opposite inclusionEC2supe EC1
Alternate simulation can be effectively checkedsee [70] for issues of computational complexity Unfortunatelyno simple formula for the conjunction of contracts is knownSee [83] for the best results in this direction
Parallel composition and quotient Contract compositionC2otimesC1 as defined in the meta-theory is effectively computedas follows for Ci two Interface Automata satisfying the con-ditions of Lemma 5 Consider as a first candidate for contractcomposition the composition C2timesC1 where Ci i = 1 2 areseen as io-automata This first guess does not work becauseof the condition involving environments in the contract compo-sition of the meta-theory More precisely by the meta-theorywe should have
E |=E C rArr [EtimesM2 |=E C1 and EtimesM1 |=E C2]
which requires forallα isin Σouti qi
αminusrarri rArr (q1 q2)αminusrarrC2timesC1
Pairs (q1 q2) not satisfying this are called illegal In words apair of states (q1 q2) is illegal when one Interface Automatonwants to submit an output whereas the other one refuses toaccept itmdashreferring to AssumeGuarantee contracts one couldinterpret this as a mismatch of assumptions and guaranteesin this pair of interfaces Illegal pairs must then be prunedaway Pruning away illegal pairs from C2timesC1 together withcorresponding incoming transitions may cause other illegalpairs to occur The latter must also be pruned away untilfixpoint occurs The result is the contract composition C2otimesC1
RR ndeg 8147
Contracts for System Design 35
As a result of this pruning it may be the case that theresulting contract has empty set of states which by Lemma 5expresses that the resulting composition of the two interfacesis inconsistent and incompatiblemdashin the original literature onInterface Automata [72] [5] it is said that the two interfacesC1 and C2 are incompatible
In [39] incremental design of deterministic Interface Au-tomata is studied Let Cdarr be the interface C with input andoutput actions interchanged Given two Interface Automata C1and C2 the greatest interface compatible with C2 such that theircomposition refines C1 is given by (C2 C1darr)darr Hence the partregarding quotient in the meta-theory is correctly addressed fordeterministic Interface Automata
Dealing with variable alphabets So far we have pre-sented the framework of interface automata for the case of afixed alphabet The clever reader may expect that dealing withvariable alphabets can be achieved by using the mechanismof alphabet equalization via inverse projections42 This is acorrect guess for contract composition It is however not clearif it is also adapted for conjunction for which no satisfactoryconstruction exists as previously indicated
In contrast alphabet equalization and conjunction are el-egantly addressed by the alternative framework of ModalInterfaces we develop now
C Modal Interfaces with fixed alphabet
Modal Interfaces inherit from both the Interface Au-tomata and the originally unrelated notion of Modal Automa-ton (or Modal Transition System) see the bibliographicalnote VIII-G As Interface Automata Modal Interfaces usereceptive io-automata as their components and environmentsThe presentation of Modal Interfaces we develop here isaligned with our meta-theory and thus differs from classicalpresentations Again we begin with the case of a fixedalphabet Σ
Definition 7 We call Modal Interface a tuple of the formC = (ΣinΣout Q q0rarr 99K) where ΣinΣout Q q0 are asin Interface Automata and rarr 99Ksube Q times Σ times Q are twotransition relations called must and may respectively
A Modal Interface C such that q0isinQ induces two (possiblynon receptive) io-automata
and Cmust = (ΣinΣout Q q0rarr)and Cmay = (ΣinΣout Q q0 99K)
A Modal Interface is deterministic if Cmay is deterministic inthe sense of 20 C defines a contract by fixing a pair (EC MC )as follows
The set EC of the legal environments for C collects allcomponents E such that
1) ΣinE = Σout and Σout
E = Σin consequently E andCmust seen as io-automata are composable and E timesCmust is closed the same holds with Cmay in lieu ofCmust
42The inverse projection of an io-automaton is simply achieved by addingin each state a self-loop for each missing symbol
2) For any α isin Σin such that qEαminusrarrE and any reachable
state (qE q) of E times Cmay (qE q)αminusrarrEtimesCmust
There exists a unique maximal environment EC isin EC in thatEC times Cmay simulates E times Cmay in the sense of (22) for anyE isin EC EC = (ΣoutΣin Q cup gt q0rarrEC ) where(a) the restriction to QtimesΣintimesQ of transition relationrarrEC
coincides with rarr the restriction to Q times Σout times Q oftransition relation rarrEC coincides with 99K
(b) for any q isin Q q αminusrarrEC gt holds if and only if not[qα99K ]
and α isin Σout(c) gt αminusrarrEC gt holds for any α isin Σ
The set MC of the implementations of C collects all compo-nents M such that
3) ECtimesCmay simulates ECtimesM in the sense of (22)[only may transitions are allowed for ECtimesM ]
4) for any reachable state (qE qM ) of ECtimesM and (qE q)of ECtimesCmay such that (qE qM )le(qE q) and any ac-tion α isin Σout
M such that q αrarr then (qE qM )αminusrarrECtimesM
[must transitions are mandatory in ECtimesM ]
The first paragraph is a verbatim of the original definition ofModal Interfaces [166] Definition 7 introduces the two setsEC and MC whereas the classical theory of Modal Interfacesconsiders and develops a different notion of model (oftenalso called ldquoimplementationrdquo which is unfortunate) As forInterface Automata in Section VIII-B the handling of initialstate q0 is heterodox Our Definition 7 allows to cast ModalInterfaces in the framework of the meta-theory
To justify the existence and uniqueness of EC observe firstthat conditions (a) and (b) together imply that EC is receptiveCondition (2) follows from (a) Maximality in the sense of(22) follows from (b) and (c)
Consistency and Compatibility We begin with consis-tency Say that state q isin Q of C is consistent if q αrarr impliesq
α99K otherwise we say that it is inconsistent Assume thatC has some inconsistent state q isin Q meaning that for someaction α q αrarr holds but q
α99K does not hold By conditions 3)
and 4) of Definition 7 for any environment E and anyimplementation M of C no state (qE qM ) of EtimesM satisfies(qE qM )leq Hence all may transitions leading to q can bedeleted from C without changing MC Performing this makesstate q unreachable in Cmay thus Condition 2 of Definition 7is relaxed and the set of environments is possibly augmentedSince we have removed may transitions some more stateshave possibly become inconsistent So we must repeat thesame procedure Since the number of states is finite thisprocedure eventually reaches a fixpoint At fixpoint the setQ of states partition as Q = Qcon ]Qincon where Qincon
collects all states that were or became inconsistent as a resultof this procedure and Qcon only collects consistent statesIn addition since the fixpoint has been reached Qincon isunreachable from Qcon As a final step we delete Qincon andcall [C] the so obtained contract The following result holds
Lemma 6
RR ndeg 8147
Contracts for System Design 36
1) Modal Interface [C] satisfies
M[C]
=MC and E[C]supe EC (25)
where the inclusion is strict unless C possesses noinconsistent state
2) [C] offers the smallest set of environments among theModal Interfaces satisfying (25)
3) C is consistent and compatible if and only if Qcon 3 q0In the sequel unless otherwise specified we will only considerModal Interfaces that are consistent and compatible
Refinement and conjunction Conjunction and refinementare instantiated in a very elegant way in the theory of ModalInterfaces Contract refinement in the sense of the meta-theoryis instantiated by the effective notion of Modal refinement weintroduce now Roughly speaking modal refinement consistsin enlarging the must relation (thus enlarging the set of legalenvironments) and restricting the may relation (thus restrictingthe set of implementations) The formalization requires the useof simulation relations
For C a Modal Interface and qisinQ a state of it introducethe following may and must sets
may(q) = α isin Σ | q α99K
must(q) = α isin Σ | q αrarr
Definition 8 (modal refinement) Let Ci i = 1 2 be twoModal Interfaces and let qi be a state of Ci for i = 1 2Say that q2 refines q1 written q2 q1 if
may2(q2) sube may1(q1)must2(q2) supe must1(q1)
and forallα isin Σ
q1
α99K1 qprime1
q2α99K2 qprime2
=rArr qprime2 qprime1
Say that C2 C1 if q20 q10
The following result relates modal refinement with contractrefinement as defined in the meta-theory It justifies the con-sideration of modal refinement Its proof follows by direct useof Definition 7 and Lemma 6
Lemma 7 For C1 and C2 two Modal Interfaces the follow-ing two properties are equivalent(i) MC2
sube MC1and EC2
supe EC1 meaning that contract C2
refines contract C1 following the meta-theory(ii) [C2] [C1] ie [C2] refines contract [C1] in the sense of
modal refinementThe conjunction of two Modal Interfaces is thus the GreatestLower Bound (GLB) with respect to refinement order Itscomputation proceeds in two steps In a first step we wildlyenforce the GLB and compute a pre-conjunction by takingunion of must sets and intersection of may sets
Definition 9 The pre-conjunction43 C1andC2 of two ModalInterfaces is only defined if Σin
1 = Σin2 and Σout
1 = Σout2
43Pre-conjunction was originally denoted by the symbol amp in [164] [167][166]
and is given by Σin = Σin1 Σout = Σout
1 Q = Q1timesQ2q0 = (q10 q20) and its two transition relations are given by
must(q1 q2) = must1(q1) cupmust2(q2)may(q1 q2) = may1(q1) capmay2(q2)
(26)
Due to (26) C1andC2 may involve inconsistent states and thusin a second step the pruning introduced in Lemma 6 must beapplied
C1 and C2 = [C1andC2] (27)
Say that the two Modal Interfaces C1 and C2 are consistent44
if C1 and C2 is consistent in the sense of Lemma 6Parallel composition and quotient For Modal Interfaces
we are able to define both parallel composition and quotient inthe sense of the meta-theory As it was the case for InterfaceAutomata parallel composition for Modal Interfaces raisescompatibility issues and thus a two-step procedure is againfollowed for its computation
Definition 10 The pre-composition C1otimesC2 of two ModalInterfaces is only defined if Σout
1 capΣout2 = empty and is given by
Σout = Σout1 cup Σout
2 Q = Q1timesQ2 q0 = (q10 q20) and itstwo transition relations are given by
must(q1 q2) = must1(q1) capmust2(q2)may(q1 q2) = may1(q1) capmay2(q2)
(28)
Say that a state (q1 q2) of C1otimesC2 is illegal if
may1(q1) cap Σin2 6sube must2(q2)
or may2(q2) cap Σin1 6sube must1(q1)
Illegal states are pruned away from C1otimesC2 as follows Removefrom Cmay
1 times Cmay2 all transitions leading to (q1 q2) As
performing this may create new illegal states the same isrepeated until fixpoint is reached As a final step we delete thestates that are not may-reachable This finally yields C1otimesC2which no more possesses illegal states
The above construction is justified by the following resultLemma 8 C1otimesC2 as defined in Definition 10 instantiates
the contract composition from the meta-theory
Proof (sketch) E is an environment for C iff for any reachablestate (qE q1 q2) of E times Cmay
1 times Cmay2 we have
rs(qE ) sube must1(q1) capmust2(q2) (29)
where rs(q) the ready set of state q is the subset of actionsα such that q αminusrarr holds Let M1 be any implementation ofC1 and consider EtimesM1 We need to prove that EtimesM1 is anenvironment for C2 ie satisfies Condition 2 of Definition 7(we must also prove the symmetric property) Let (qE q1 q2)be a reachable state of EtimesM1timesCmay
2 We must prove
rs(qE ) cap rsM1 (q1 ) cap Σ in2 sube must2(q2)
By (29) it suffices that the following property holds
rsM1(q1 ) cap Σ in
2 sube must2(q2) (30)
44This is the usual wording in the literature
RR ndeg 8147
Contracts for System Design 37
However we only know that rsM1(q1 ) sube may1 (q1 ) Hence
to guarantee (30) we must prune away illegal pairs of statesTo this end we use the same procedure as before we makestate (q1 q2) unreachable in Cmay
1 timesCmay2 by removing all may
transitions leading to that state We complete the reasoning aswe did for the study of consistency 2
Definition 11 The quotient C1C2 of two modal interfacesC1 and C2 is only defined if Σin
1 cap Σout2 = empty and is defined
according to the following two steps procedure First defineC as follows Σout = Σout
1 Σout2 Q = Q1 times Q2 q0 =
(q10 q20) and its two transition relations are given by
must(q1 q2) = must1(q1)
may(q1 q2) = not [may1(q1) cap notmust1(q1)] cupnot [must1(q1) capmust2(q2)] cupnot [may1(q1) cupmay2(q2)]
These formulas may give raise to inconsistent states and thusin a second step we set C1C2 = [C]This definition is justified by the following result [166]showing that Definition 11 instantiates the meta-theory
Lemma 9 C1 otimes C2 C if and only if C2 CC1
Now it may be that (C1C2)otimesC2 possess illegal pairs of states(Definition 10) whence the following improvement whereΣout and Σin are as in Definition 11 and may and mustrefer to the quotient C1C2
Definition 12 Let Cprime be the interface defined on the samestate structure as C1C2 with however the following modali-ties
may prime(q1 q2) = may(q1 q2) cap(may2(q2) cup Σin
)must prime(q1 q2) = must(q1 q2) cup (Σout
1 cap Σout2 capmay2(q2))
define the compatible quotient written C1C2 to be thereduction of Cprime C1C2 = [Cprime]
This construction is justified by the following result
Lemma 10 The compatible quotient C1C2 solves thefollowing problem
max
C∣∣∣∣∣∣C has no inconsistent stateC otimes C2 has no illegal pair of statesC otimes C2 C1
Proof Denote C = C1C2 the compatible quotient definedabove The proof is threefold (i) C is proved to be a solutionof the inequality CotimesC2 C1 (ii) C is proved to be compatiblewith C2 and (iii) every Cprime satisfying the two conditions aboveis proved to be a refinement of C
Remark that reachable states in (C1C2)otimesC2 are of the form(q1 q2 q2) and that for every reachable state pair (q1 q2) inC1C2 state (q1 q2 q2) is reachable in (C1C2)otimes C2
(i) Remark that may prime sube may and must prime supe must HenceC1C2 C1C2 Since the parallel composition is monotonic(C1C2)otimes C2 (C1C2)otimes C2 C1
(ii) For every state (q1 q2 q2) reachable in (C1C2)otimes C2one among the following three cases occurs
bull Assume e isin Σin1 meaning that e is an input for both C2
and C1C2 Hence state (q1 q2 q2) is not illegal becauseof e
bull Assume e isin Σout1 cap Σout
2 Therefore e is an input of thecompatible quotient Remark must prime(q1 q2) sube may2(q2)Hence state (q1 q2 q2) is not illegal because of e
bull Assume e isin Σout1 capΣin
2 meaning that e is an output of thecompatible quotient Remark may prime(q1 q2) sube must2(q2)Therefore state (q1 q2 q2) is not illegal because of e
(iii) Let Cprimeprime be a modal interface such that C1C2 Cprimeprime C1C2 We shall prove that either Cprimeprime C1C2 or that Cprimeprime is notcompatible with C2 Remark that every reachable state (q1 q2)of C1C2 is related to exactly one state qprimeprime of Cprimeprime by the twomodal refinement relations Assume that Cprimeprime is not a refinementof C1C2 meaning that there exists related states (q1 q2)and qprimeprime such that may prime(q1 q2) sube may primeprime(qprimeprime) sube may(q1 q2)and must prime(q1 q2) supe must primeprime(qprimeprime) supe must(q1 q2) and eithermay prime(q1 q2) ( may primeprime(qprimeprime) or must prime(q1 q2) ) must primeprime(qprimeprime)Remark e isin Σin
1 implies that e isin may prime(q1 q2) iff e isinmay(q1 q2) and that e isin must prime(q1 q2) iff e isin must(q1 q2)Therefore the case e isin Σin
1 does not have to be considered
1) Assume there exists e such that e isin may primeprime(qprimeprime) may prime(q1 q2) Remark this implies e isin Σout
1 cap Σin2
meaning that e is an output of the compatible quo-tient Remark also that e 6isin must2(q2) Therefore state(qprimeprime q2) is illegal in Cprimeprime otimes C2
2) Assume there exists e such that e isin must prime(q1 q2) must primeprime(qprimeprime) Remark this implies e isin Σout
1 cap Σout2
meaning that e is an input of the compatible quotientRemark also that e isin may2(q2) Therefore state (qprimeprime q2)is illegal in Cprimeprime otimes C2
2
D Modal Interfaces with variable alphabet
As a general principle every relation or operator introducedin Section VIII-C (for Modal Interfaces with a fixed alphabetΣ) is extended to the case of variable alphabets by 1) extendingand equalizing alphabets and then 2) applying the relations oroperators of Section VIII-C to the resulting Modal InterfacesFor all frameworks we studied so far alphabet extension wasperformed using inverse projections see Section VII-C Forinstance this is the procedure used in defining the compositionof io-automata extending alphabets in io-automata is byadding at each state and for each added action a self-loop labeled with this action The very reason for using thismechanism is that it is neutral for the composition in thefollowing sense it leaves the companion io-automaton freeto perform any wanted local action
So for Modal Interfaces what would be a neutral procedurefor extending alphabets Indeed considering (26) or (28)
RR ndeg 8147
Contracts for System Design 38
yields two different answers namely
for (26)
α isin may1(q1) and α isin whatever2(q2)dArr
α isin whatever(q1 q2)
for (28)
α isin must1(q1) and α isin whatever2(q2)dArr
α isin whatever(q1 q2)
where ldquowhateverrdquo denotes either may or must Consequentlyneutral alphabet extension is by adding
bull may self-loops for the conjunction andbull must self-loops for the composition
The bottom line is that we need different extension proceduresThese observations explain why alphabet extension is properlyhandled neither by Interface Automata (see the last paragraphof Section VIII-B) nor by AG-contracts (see the end ofSection VII-C) These theories do not offer enough flexibilityfor ensuring neutral extension for all relations or operators
We now list how alphabet extension must be performed foreach relation or operator for two Modal Interfaces C1 and C2(the reader is referred to [166] for justifications) Alphabetsare extended as follows where Σprime supe Σ Define the strongextension of C to Σprime written CuarrΣprime
as follows
CuarrΣprime
(Σin)uarrΣprime
= Σin cup (Σprime Σ)
(Σout)uarrΣprime
= Σout
QuarrΣprime
= Q
quarrΣprime
0 = q0
mayuarrΣprime
= may cup (Σprime Σ)
mustuarrΣprime
= must cup (Σprime Σ)
(31)
In (31) the added may and must transitions are all self-loopsThe weak extension of C written CuArrΣprime
is defined using thesame formulas with the only following modification
CuArrΣprime
=
mustuArrΣprime= must
(32)
Observe that the strong extension uses the classical inverseprojection everywhere The weak extension however proceedsdifferently with the must transitions in that it forbids the legalenvironments to submit additional actions as its outputs
Using weak and strong alphabet equalization the relationsand operations introduced in Section VIII-C extend to variablealphabets as indicated now In the following formulas (ΣΣprime)is a pair such that Σ sube Σprime and (Σ1Σ2Σ) denotes a triplesuch that Σ = Σ1 cup Σ2 and satisfying the typing constraints
Σini = Σin cap Σi and Σout
i = Σout cap Σi for i = 1 2
It is understood that contract C has alphabet Σ and so on
Theorem 1 The following relations and operators
M prime |=M C = M prime |=M CuArrΣprime
Eprime |=E C = Eprime |=E CuarrΣprime
C1 C2 = C1 CuArrΣ2
C1 and C2 = CuArrΣ1 and CuArrΣ
2
C1 otimes C2 = CuarrΣ1 otimes CuarrΣ2
C1C2 = CuArrΣ1 CuarrΣ2
(33)
instantiate the meta-theory
Proof The first two formulas just provide definitions so noproof is needed for them Their purpose is to characterizethe weakly and strongly extended Modal Interfaces in termsof their sets of environments and implementations For bothextensions allowed output actions of the implementations areaugmented whereas mandatory actions are not For the weakextension legal environments are not modified in that noadditional output action is allowed for them In contrast for thestrong extension legal environments are allowed to submit anyadditional output action These observations justify the otherformulas 2
E Projecting and Restricting
A difficult step in the management of contracts was illus-trated in Figure 4 of Section IV-D It consists in decomposinga contract C into a composition of sub-contractsotimes
iisinI Ci C (34)
where sub-contract Ci has alphabet Σi = Σini ] Σout
i As aprerequisite to (34) the designer has to guess some topologicalarchitecture by decomposing the alphabet of actions of C as
Σ =⋃iisinI Σi Σi = Σin
i ] Σouti (35)
such that composability conditions regarding inputs and out-puts hold Guessing architectural decomposition (35) relies onthe designerrsquos understanding of the system and how it shouldnaturally decomposemdashthis typically is the world of SysMLFinding decomposition (34) is however technically difficultin that it involves behaviors It is particularly difficult if Cis itself a conjunction of viewpoints or requirements whichtypically occurs in requirements engineering see Section XI
C =andkisinK Ck (36)
The algorithmic means we develop in the remaining part ofthis section will be instrumental in solving (34) They will beused in the Parking Garage example of Section XI
Projecting over a subalphabet Projecting a contract overa sub-alphabet is the first natural tool for consideration Itis the dual operation with respect to alphabet extension thatwas developed in Section VIII-D Two projections can bedefined which can be seen as under- and over-approximationsrespectively by referring to the refinement order
RR ndeg 8147
Contracts for System Design 39
Let C be a Modal Interface with alphabet Σ = Σin cup Σout
and let Σprime sub Σ be a sub-alphabet Define respectively theabstracted projection and refined projection
CdarrΣprime= min Cprime | ΣCprime = Σprime and Cprime C
CdArrΣprime= max Cprime | ΣCprime = Σprime and Cprime C
(37)
where ldquominrdquo and ldquomaxrdquo refer to refinement order for ModalInterfaces with different alphabets see (33) The projectionCdArrΣprime
(respectively CdarrΣprime) is computed via the following on-
the-fly algorithm 1) Perform ε-closure on the set of states byconsidering unobservable the actions not belonging to Σprime andthen 2) Perform determinization by giving priority to mustover may (respectively to may over must) see Table VI fordetails Step 2) of the procedure for computing CdArrΣprime
is apossible source of inconsistencies
The abstracted projection CdarrΣprimeprovides a projected view
of a system-level contract over a small subset of actionsThe abstracted projection is thus a useful tool for contractexploration and debug It is not a synthesis tool however
This is in contrast to the refined projection CdArrΣprime which
satisfies the following result For any finite set Ci | i isin Iof Modal Interfaces with respective alphabets Σi we haveassuming that the left and right hand sides are properlydefinedmdasha typing property on input and output alphabetsotimes
iisinI
[Ci and
(andkisinK C
dArrΣi
k
)]
andkisinK Ck (38)
To show this by symmetry it is enough to show (38) withthe conjunction on the right hand side replaced by any singleCk for k selected from finite set K For any i isin I we haveCdArrΣi
k Ck and thus
Cprimei =def
[Ci and
(andkisinK C
dArrΣi
k
)] Ck (39)
holds for every i from which (38) follows Unfortunately therefined projection quite often gives raise to inconsistenciesIn addition the contract composition arising in left hand sideof (38) is subject to incompatibilities Informally said thistechnique works if the sub-systems are only ldquoloosely coupledrdquoso that neither inconsistencies nor incompatibilities occur Tomitigate this problem we propose an alternative technique forturning a conjunction into a composition
Restricting to a sub-alphabet Let C be a Modal Interfacewith alphabet Σ = Σin cup Σout and let (ΣprimeinΣprimeout) be twoinput and output sub-alphabets such that Σprimeout sube Σout SetΣprime = Σprimein]Σprimeout and define the restriction of C to Σprime denotedby CdarrΣprime via the procedure shown in see Table VII comparewith Table VI Observe that the states of the restriction cor-respond to sets of states of the original Modal Interface Therestriction aims at avoiding incompatibilities when consideringthe composition as the following lemma shows
Lemma 11 If C and CdarrΣprime are both consistent then so istheir compatible quotient CCdarrΣprime see Definition 12Proof Consider two alphabets Σ supe Σprime and a consistent C onalphabet Σ such that CdarrΣprime is also consistent The only casewhere quotient produces inconsistent states is whenever there
input CΣΣprime output Cprime
let proj(OpX) =if X has not been visitedthen
1 mark X visited2 for every α isin Σprime do
21 let Y = ε-closure(Σminus Σprime next(αX))22 let m = OpmC(q α) | q isin X23 add to Cprime a transition (Xα Y ) with modality m24 proj(Op Y )
done
let project(Op C) =1 let X0 = ε-closure(Σminus Σprime q0)2 set initial state of Cprime to X0
3 proj(OpX0)4 reduce Cprime5 return Cprime
let order (cannot maymustle) =
must le may
cannot le may
in CdarrΣprime= project(or C)
CdArrΣprime= project(and C)
Table VIALGORITHM FOR COMPUTING THE PROJECTIONS (37)
input CΣinΣoutΣprimeinΣprimeout output Cprime
let order(cannot maymustlein) = cannot lein may lein must
order(cannot maymustleout) =
must le may
cannot le mayin let rest(X) =
if X has not been visitedthen
1 mark X visited2 for every α isin Σprime do
21 let Y = ε-closure(Σminus Σprime next(αX))22 let m = OpmC(q α) | q isin X
where Op = if α isin Σprimein then orin else andout
23 add to Cprime a transition (Xα Y ) with modality m24 rest(Op Y )
done
let restrict(C) =1 let X0 = ε-closure(Σminus Σprime q0)2 set initial state of Cprime to X0
3 rest(OpX0)4 reduce Cprime5 return Cprime
Table VIIALGORITHM FOR COMPUTING THE RESTRICTION CdarrΣprime
exists an action e and a state pair (qR) in CCdarrΣprime such thate has modality must in q and does not have modality mustin R We prove by contradiction that no such reachable statepair (qR) and action e exist Remark that by definition of therestriction q isin R The restriction is assumed to be in reducedform meaning that it does not contain inconsistent states Twocases have to be considered
1) Action e has modality cannot in R Several sub-caseshave to be considered depending on the IO status ofe and on the fact that the reduction of the restrictionhas turned a may modality for e into a cannot In allcases action e has modality cannot or may in q which
RR ndeg 8147
Contracts for System Design 40
contradicts the assumption2) Action e has modality may in R This implies that e also
has modality may in q which contradicts the assumptionThis finishes the proof of the lemma 2
The following holds by Lemma 10
CdarrΣprime otimes (CCdarrΣprime ) CCCdarrΣprime has no inconsistent state
(CdarrΣprime CCdarrΣprime ) has no incompatible pair of states(40)
By Lemma 11 the only property for checking is the consis-tency of CdarrΣprime This is a significant improvement comparedto the issues raised by the refined projection as explained inthe paragraph following (39) Decomposition (40) can be usedwhile sub-contracting through the following algorithm
Algorithm 1 We are given some system-level contract CThe top-level designer guesses some topological architectureaccording to (35) Then she recursively decomposes
C = C0 C0darrΣ1otimes C1
C0darrΣ1otimes C1darrΣ2
otimes C2 C0darrΣ1
otimes otimes Cnminus1darrΣn
=def C(Σ1) otimes otimes C(Σn)
(41)
which ultimately yields a refinement of C by a compatiblecomposition of local sub-contracts 2
Discussion The operations of projection and restrictionthat we introduced here can probably be made be genericat the level of the meta-theory Observe however that suchoperations explicitly refer to the notion of sub-alphabet whichdoes not exist at the level of the meta-theory In additionModal Interfaces are the only concrete theory in which variablealphabets are properly supported For these two reasons wepreferred to develop these operations for Modal Interfacesonly
F Observers
Here we develop observers for a Modal InterfaceC = (ΣinΣout Q q0rarr 99K) having no inconsistent statemeaning that rarrsube99K With this consistency assumption inforce observers are then obtained as follows with referenceto Definition 2bull Condition 2 of Definition 7 boils down to requiring thatE times Cmust simulates E Simulation testing can thus beused to check this call bE
C(E) the corresponding verdictbull To test for implementations we first construct the max-
imal environment EC and apply testing to check sim-ulation of EC times M by Cmay call bM
C1 the corre-sponding verdict Performing this requires maintainingpairs of states ((qE qM ) (qE q)) in simulation relation(qE qM )le(qE q) For any such pair of states let bM
C2 de-note the verdict answering whether (qE qM )
αminusrarrECtimesMholds each time q αminusrarr holds for any α isin Σout Theoverall verdict for implementation testing is then
bMC1(EC timesM) and bM
C2(EC timesM)
Lemma 3 for generic observers specializes to the followingeffective semi-decision procedure
Lemma 121) If bE
C outputs F then C is incompatible2) If bM
C1 and bMC2 outputs F then C is inconsistent
G Bibliographical note
As explained in [72] [56] [127] [83] [165] [166] Inter-face Theories make no explicit distinction between assump-tions and guarantees
Interface Automata variants and extensions InterfaceAutomata were proposed by de Alfaro and Henzinger [72][70] [5] [54] as a candidate theory of interfaces In thesereferences Interface Automata focused primarily on parallelcomposition and compatibility Quoting [72]
ldquoTwo interfaces can be composed and are compatibleif there is at least one environment where they canwork togetherrdquo
The idea is that the resulting composition exposes as aninterface the needed information to ensure that incompatiblepairs of states cannot be reached This can be achieved byusing the possibility for a component to refuse selectedinputs from the environment at a given state [72] [56] Incontrast to our development in Section VIII-B no sets ofenvironments and implementations are formally associated toan Interface Automaton in the original developments of theconcept A refinement relation for Interface Automata wasdefined in [72]mdashwith the same definition as oursmdashit couldnot however be expressed in terms of sets of implementationsProperties of interfaces are described in game-based logicseg ATL [9] with a theoretical high-cost complexity Theoriginal semantics of an Interface Automaton was given by atwo-player game between an input player that represents theenvironment (the moves are the input actions) and an outputplayer that represents the component itself (the moves are theoutput actions) Despite the availability of partial results [83]the framework of Interface Automata lacks support for theconjunction of interfaces in a general setting and does notoffer the flexibility of modalities Sociable Interfaces [71]combine the approach presented in the previous paragraphwith interface automata [72] [73] by enabling communicationvia shared variables and actions45 First the same actioncan appear as a label of both input and output transitionsSecondly global variables do not belong to any specificinterface and can thus be updated by multiple interfaces Con-sequently communication and synchronization can be one-to-one one-to-many many-to-one and many-to-many Symbolicalgorithms for checking the compatibility and refinement ofsociable interfaces have been implemented in TICC [3]Software Interfaces were proposed in [55] as a pushdownextension of interface automata (which are finite state) Push-down interfaces are needed to model call-return stacks ofpossibly recursive software components This paper contains
45This formalism is thus not purely synchronous and is mentioned in thissection with a slight abuse
RR ndeg 8147
Contracts for System Design 41
also a comprehensive interface description of Tiny OS46 anoperating system for sensor networks Moore machines andrelated reactive synchronous formalisms are very well suitedto embedded systems modeling Extending interface theoriesto a reactive synchronous semantics is therefore meaningfulSeveral contributions have been made in this direction startingwith Moore and Bidirectional Interfaces [56] In Moore Inter-faces each variable is either an input or an output and thisstatus does not change in time Bidirectional Interfaces offeradded flexibility by allowing variables to change IO statusdepending on the local state of the interface Communicationby shared variable is thus supported and for instance allowsdistributed protocols or shared buses to be modeled In bothformalisms two interfaces are deemed compatible wheneverno variable is an output of both interfaces at the same timeand every legal valuation of the output variables of oneinterface satisfies the input predicate of the other The mainresult of the paper is that parallel composition of compatibleinterfaces is monotonic with respect to refinement Note thatMoore and Bidirectional Interfaces force a delay of at leastone transition between causally dependent input and outputvariables exactly like Moore machines In [83] the frame-work of Synchronous Interfaces is enriched with a notion ofconjunction (called shared refinement) This development wasfurther elaborated in [78] In Moore interfaces legal values ofthe input variables and consequent legal values of the outputvariables are not causally related Synchronous Relational In-terfaces [177] [178] have been proposed to capture functionalrelations between the inputs and the outputs associated toa component More precisely inputoutput relations betweenvariables are expressed as first-order logic formulas over theinput and output variables Two types of composition are thenconsidered connection and feedback Given two relationalinterfaces C1 and C2 the first one consists in connecting someof the output variables of C1 to some of the input variablesof C2 whereas feedback composition allows one to connectan output variable of an interface to one of its own inputsThe developed theory supports refinement compatibility andalso conjunction The recent work [112] studies conditions thatneed to be imposed on interface models in order to enforceindependent implementability with respect to conjunctionFinally [53] develops the concept of simulation distancesfor interfaces thereby taking robustness issues into accountby tolerating errors Finally Web services Interfaces wereproposed in [38]
The discussion of variants and extensions related to timeresources and probability is deferred to corresponding sec-tions
Modal Interfaces variants and extensions Propertiesexpressed as sets of traces can only specify what is forbiddenUnless time is explicitly invoked in such properties it isnot possible to express mandatory behaviors for designsModalities were proposed by Kim Larsen [130] [11] [46] asa simple and elegant framework to express both allowed and
46httpwwwtinyosnet
mandatory properties Modal Specifications basically consist inassigning a modality may or must to each possible transition ofa system They have been first studied in a process-algebraiccontext [130] [125] in order to allow for loose specificationsof systems Since then they have been considered for automata[128] and formal languages [163] [164] and applied to a widerange of application domains (see [11] for a complete survey)Informally a must transition is available in every componentthat realizes the modal specification while a may transitionneeds not be A modal specification thus represents a set ofmodelsmdashunfortunately models of modal transition systems areoften call ldquoimplementationsrdquo in the literature which is unfor-tunate in our context We prefer keeping the term ldquomodelrdquoand reserve the term ldquoimplementationrdquo for the entities intro-duced in Sections VIII-B and VIII-C Modal Specificationsoffer built-in conjunction of specifications [129] [167] Theexpressiveness of Modal Specifications has been characterizedas a strict fragment of the Hennessy-Milner logic in [46]and also as a strict fragment of the mu-calculus in [89] Theformalism is rich enough to specify safety properties as well asrestricted forms of liveness properties Modal Interfaces withthe right notion of compatibility were introduced in [165][166] and the problem of alphabet equalization with weakand strong alphabet extensions was first correctly addressed inthe same references In [23] compatibility notions for ModalInterfaces with the passing of internal actions are definedContrary to the approach reviewed before a pessimistic viewof compatibility is followed in [23] ie two Modal Interfacesare only compatible if incompatibility between two interfacescan occur in any environment A verification tool called MIOWorkbench is available The quotient of Modal Specificationswas studied in [124] [164] Determinism plays a role in themodal theory Non-deterministic Modal Interfaces have pos-sibly non-deterministic io-automata as class of componentsThey are much more difficult to study than deterministic onesand corresponding computational procedures are of highercomplexity A Modal Interface is said to be deterministic if itsmay-transition relation is deterministic For nondeterministicModal Interfaces modal refinement is incomplete [128] thereare nondeterministic Modal Interfaces C1 and C2 for whichthe set of implementations of C1 is included in that of C2without C1 being a modal refinement of C2 Hence refinementaccording to the meta-theory is not exactly instantiated butonly approximated in a sound way A decision procedure forimplementation inclusion of nondeterministic Modal Interfacesdoes exist but turns out to be EXPTIME-complete [12] [25]whereas the problem is PTIME-complete if determinism isassumed [167] [26] The benefits of the determinism assump-tion in terms of complexity for various decision problemson modal specifications is underlined in [26] The ldquomergerdquoof non-deterministic Modal Specifications regarded as partialmodels has been considered in [179] This operation consistsin looking for common refinements of initial specifications andis thus similar to the conjunction operation presented hereIn [179] [90] algorithms to compute the maximal commonrefinements (which are not unique when non-determinism is
RR ndeg 8147
Contracts for System Design 42
allowed) are proposed They are implemented in the toolMTSA [82] Assumeguarantee contracts viewed as pairs ofModal Specifications were proposed in [96] It thus com-bines the flexibility offered by the clean separation betweenassumptions and guarantees and the benefits of a modalframework Several operations are then studied refinementparallel composition conjunction and priority of aspects Thislast operation composes aspects in a hierarchical order suchthat in case of inconsistency an aspects of higher priorityoverrides a lower-priority contract The synthesis of ModalInterfaces from higher-level specifications has been studiedfor the case of scenarios In [173] Existential Live SequenceCharts are translated into Modal Specifications hence provid-ing a mean to specify modal contracts Regarding extensionsAcceptance Interfaces were proposed by J-B Raclet [163][164] Informally an Acceptance Interface consists of a set ofstates with for each state a set of ready sets where a readyset is a set of possible outgoing transitions from that stateIn intuitive terms an Acceptance Interface explicitly specifiesits set of possible models Acceptance Interfaces are moreexpressive than Modal Interfaces but at the price of a pro-hibitive complexity for the various relations and operators ofthe theory Modal Interfaces have been enhanced with markedstates by Caillaud and Raclet [27] Having marked statessignificantly improves expressiveness It is possible to specifythat some state must be reachable in any implementation whileleaving the particular path for reaching it unspecified As anexample of use Modal Interfaces with marked states have beenapplied in [4] to the separate compilation of multiple clockedsynchronous programs
The discussion of variants and extensions related to timeresources and probability is deferred to corresponding sec-tions
Features of our presentation The presentation of in-terface theories in this paper is new in many aspects Forthe first time all interface theories are clearly cast in theabstract framework of contracts following our meta-theory Inparticular the association to an interface C of the two sets ECandMC is new It clarifies a number of concepts In particularthe interface theories inherit from the properties of the meta-theory without the need for specific proofs The projectionand restriction operators for Modal Interfaces are new Castinginterface theories into the meta-theory was developed for thebasic interface theories only It would be useful to extend thisto the different variants and see what the benefit would beBenoicirct Caillaud has developed the MICA tool [49] whichimplements Modal Interfaces with all the operations andservices discussed in this section
IX PANORAMA TIMED INTERFACE THEORIES
In this section we develop an instance of an interface theoryfor timed systems This section is meant to be illustrative ofour approach to concrete instances of contract theories It doesnot claim to expose the good instance Our presentation buildson top of [35] To simplify the exposure we restrict ourselves
to the case of a fixed alphabet Σ As usual now we begin withthe component model
A Components as Event-Clock Automata
Timed Automata [6] constitute the basic model for systemsdealing with time and built on top of automata In wordstimed automata are automata enhanced with clocks Predicateson clocks guard both the states (also called ldquolocationsrdquo) andthe transitions Actions are attached to transitions that resultin the resetting of some of the clocks
Event-Clock Automata [7] [8] [35] form a subclass oftimed automata where clock resets are not arbitrary eachaction α comes with a clock hα which is reset exactlywhen action α occurs The interest of this subclass is thatevent-clock automata are determinizable which facilitates thedevelopment of a (modal) theory of contracts The definitionof event-clock automata requires some prerequisites
We are given an underlying finite set H of clocks A clockvaluation is a map ν H 7rarr R+ where R+ denotes the set ofnonnegative reals The set of all clock valuations is denotedby V We denote by 0 the clock valuation assigning 0 to allclocks and by ν + t the clock obtained by augmenting ν withthe constant t For ν a valuation the valuation ν[0hα] assigns0 to hα and keeps the valuation of other clocks unchanged
Clocks can be used to define guards The class of guardsconsidered by [35] consists of finite conjunctions of expres-sions of the form h sim n where h is a clock n is an integerand sim is one of the following relations ltle=ge gt Forg a guard write ν |= g to mean that valuation ν satisfiesguard g For N an integer G(H N) denotes the set of allguards over H involving only integers n lt N + 1 and wewrite G(H) = G(Hinfin)
Definition 13 An event-clock automaton over alphabet Σis a tuple M = (ΣinΣout Q q0 Nrarr) wherebull ΣinΣout Q q0 are as for io-automata elements of Q
are called locationsbull HΣ = hα | α isin Σ is the set of clocksbull N is a finite integer and rarrsube Q times G(HΣ N) times Σ times Q
is the transition relation write qgαminusrarr qprime to mean that
(q g α qprime) isinrarr
The semantics of M is a timed transition system with infinitestate space QtimesV defined as follows transition q
gαminusrarr qprime canfire from state (q ν) isin Q times V iff ν |= g as a result of thisfiring the clock hα is reset to zero thus resulting in the newstate (qprime ν[0hα]) isin Q times V In our Timed Interface theorycomponents are event-clock automata that are
1) deterministic in the following sense
forall(q α ν) isin Qtimes Σtimes V there is at mostone transition q
gαminusrarr qprime such that ν |= g(42)
2) receptive meaning that
forallq isin Qforallα isin Σin qTαminusrarr
holds where T denotes the trivial guard ldquotruerdquo
RR ndeg 8147
Contracts for System Design 43
Instead of further developing our theory we will show how totake advantage of previously developed theories by showingthat event-clock automata are finitely encoded by means of re-gion automata that we introduce next Fix bound N A regionis an equivalence class ϑ of clock valuations ν satisfying thesame set of guards from G(H N) Denote by Θ the set of allsuch regions (bound N is understood) For ϑ isin Θ consider
τ(ϑ) = ϑprimeprime | existνprimeprime isin ϑprimeprimeexistν isin ϑexistt ge 0 st νprimeprime = ν + t
which is the set of all regions that can be obtained from ϑ byletting time elapse Finally for ϑ a region and α an actionϑdarrα is the region obtained from ϑ by resetting clock hα Usingthese notations we associate to each event-clock automatonM = (ΣinΣout Q q0 Nrarr) a Region Automaton which isthe following finite state automaton
R [M ] =(Σin timesΘΣout timesΘ QtimesΘ (q00)rArr
)(43)
where the transition relation rArr is given by
(q ϑ)ϑrdquoα
===rArr (qprime ϑprime) iff
q gαrarr qprime withϑrdquo sube τ(ϑ) cap g andϑprime = ϑrdquodarrα
(44)
Vice-versa any Region Automaton R defines a uniqueevent-clock automaton M [R] by deducing from (44) theminimal guards associated to its transitions Starting from anevent-clock automaton M M [R [M ]] is related to M by astrengthening of its guards However it holds that47
R [M [R [M ]]] = R [M ] (45)
Under the above correspondence components in theevent-clock automaton domain are mapped to components inthe io-automaton domain
B Modal Event-Clock Specifications
In this section we develop the framework of con-tracts on top of our component model of deterministicevent-clock automata To simplify we only develop the caseof a fixed alphabet Σ
Definition 14 A Modal Event-Clock Specification (MECS)is a tuple C = (ΣinΣout Q q0rarr 99K) where ΣinΣoutQ q0 are as in Interface Automata and
rarr sube 99K sube Qtimes G(HΣ)times ΣtimesQ
Using the same construction as above MECS C induces aRegion Modal Event-Clock Specification (RMECS) denoted byR [C] which is a Modal Interface according to Definition 7Accordingly R [C] defines a pair (ER[C]
MR[C]) of sets of
io-automata and we finally define
(EC MC ) =def
(M[ER[C]
]M[MR[C]
])The map C 7rarr R [C] satisfies48
R [M [R [C]]] = R [C] (46)
47It is shown in [35] that M 7rarr R [M ] forms a Galois connection48Again it is a Galois connection [35]
This allows us to lift the contract theory of RMECS (whichare Modal Interfaces) to a contract theory of MECS Whilethis is conceptually elegant it is not efficient since movingfrom MECS to RMECS (from timed models to region models)is ExpTime which is costly To cope with this difficulty theauthors of [35] have provided direct cheap formulas expressedin the MECS domain These formulas provide a partial answerto the issue of complexity In particular the following lemmaholds that was stated and proved in [35]
Lemma 13 For C1 and C2 two MECS having identical inputand output alphabets define C1andC2 symbolically with rules ofthe following form
Glbmay q1
g1α99K qprime1 and q2
g2α99K qprime2
(q1 q2)g1andg2α99K (qprime1 q
prime2)
Glbmustleft q1
g1αrarr qprime1 and q2g2α qprime2
(q1 q2)g1andg2αrarr (qprime1 q
prime2)
where denotes ad libitumrarr or 99K and with Glbmustright
defined symmetrically (see [35] for the complete set of rules)Then we have
R [C1andC2] = R [C1]andR [C2] (47)
Inconsistent states for both sides of (47) correspond A similarlemma holds for contract quotient C1C2 Unfortunately thepruning of inconsistent states cannot be performed directlyin the MECS domain and mapping to regions is mandatoryNevertheless dedicated rules to handle directly inconsistentstates exist in the symbolic versions of the different relationsand operations on MECS As a result the computation ofthe regions is only mandatory when the designer aims atcleaning its contract by pruning the inconsistencies A similarlemma holds for contract composition C1otimesC2 Again pruningincompatible pairs of states cannot be performed directly inthe MECS domain and mapping to regions is mandatory49
C Bibliographical note
This note focuses on interface types of framework Thereader is referrect to the bibliographical note of Section VII-Gfor extensions of AG-contracts addressing time
A first interface theory able to capture the timing aspectsof components is Timed Interfaces [74] Timed Interfacesallows specifying both the timing of the inputs a componentexpects from its environment and the timing of the outputsit can produce Compatibility of two timed interfaces is thendefined and refers to the existence of an environment such thattiming expectations can be met The Timed Interface theoryproposed in [68] fills a gap in the work introduced in [74]by defining a refinement operation In particular it is shownthat compatibility is preserved by refinement This theoryalso proposes a conjunction and a quotient operation and is
49Authors of [35] do not mention this fact for the following reason Theydo not consider the issue of receptiveness for components and therefore theissue of compatibility does not arise
RR ndeg 8147
Contracts for System Design 44
implemented in the tool ECDAR [69] Timed SpecificationTheories are revisited from a linear-time perspective in [60]
The first timed extension of modal transition systems waspublished in [52] It is essentially a timed (and modal) versionof the Calculus of Communicating Systems (by Milner) Basedon regions tool support for refinement checking were imple-mented and made available in the tool EPSILON [95] Anothertimed extension of Modal Specifications was proposed in [36]In this formalism transitions are equipped with a modality anda guard on the component clocks very much like in timedautomata For the subclass of modal event-clock automataan entire algebra with refinement conjunction product andquotient has been developed in [33] [34]
Resources other than time were also consideredmdashwithenergy as the main target Resource Interfaces [57] can beused to enrich a variety of interface formalisms (InterfaceAutomata [72] AssumeGuarantee Interfaces [73] etc) witha resource consumption aspect Based on a two player game-theoretic presentation of interfaces Resource Interfaces allowfor the quantitative specification of resource consumptionWith this formalism it is possible to decide whether compo-sitions of interfaces exceed a given resource usage thresholdwhile providing a service expressed either with Buumlchi condi-tions or thanks to quantitative rewards Because resource usageand rewards are explicit rather then being defined implicitlyas solutions of numerical constraints this formalism doesnot allow one to reason about the variability of resourceconsumption across a set of logically correct models
X PANORAMA PROBABILISTIC INTERFACE THEORIES
Probabilistic systems are non-deterministic systems inwhich choice is controlled by random trial Such systems areuseful for many purposes ranging from physical or biologicalsystems to security protocols intrusion detection and up tosafety and reliability analyses in system design In this sectionas another illustration of our meta-theory we develop a simpleinstance of a probabilistic interface theory Again to simplifythe exposure we restrict ourselves to the case of a fixedalphabet Σ
A Components as Probabilistic Automata
We first introduce Probabilistic Automata with inputs andoutputs also called InputOutput Markov Decision Processesand then we motivate their use in safety analysis
Definition 15 A Probabilistic Automaton with inputs andoutputs (io-PA) is a tuple M = (ΣinΣout Q q0Πrarr)wherebull Σin and Σout are disjoint finite input and output alpha-
bets such that Σin cup Σout = Σbull Q is a finite set of states and q0isinQ is the initial state
we denote by Π(Q) the finite set of all probabilities overQ also called the probabilistic states
bull rarr sube Qtimes ΣtimesΠ(Q) is the transition relation we writeq
αminusrarr π to mean (q α π) isinrarr and q αminusrarr if q αminusrarr πholds for some π
bull In addition we require M to be deterministic in thefollowing sense for any pair (q α) isin Q times Σ q αminusrarr πand q αminusrarr πprime implies π = πprime
A run σ of M starts from initial state q0 and then progressesby a sequence of steps of the form q
αminusrarr π 7rarr qprime wheresupplementary transitions π 7rarr qprime are drawn at random byselecting a successor state qprime isin Q according to probabilityπ A strategy consists in fixing a function ϕ Q rarr Σand using it to select the next action Once a strategy hasbeen fixed jumping from a probabilistic state to the next onegives raise to a time-invariant Markov Chain whose invariantprobability can be computed or statistically estimated Whenall probabilistic states are Dirac measures δqprime selecting qprime asa next state with probability one io-PA M boils down to anio-automaton Thus io-PA subsume io-automata
Two io-PA M1 and M2 are composable if Σout1 capΣout
2 = emptyTwo composable io-PA M1 and M2 compose into M = M1timesM2 as follows
(q1 q2)αminusrarrM π1 otimes π2 iff
q1
αminusrarrM1π1 and
q2αminusrarrM2
π2(48)
where otimes denotes the product of two probabilities thus makingthe two components independent Parallel composition definedin this way has all the desired properties
Similarly the concept of simulation relation is easily de-rived from that of io-automata by preserving probabilitiesfor Mi i = 1 2 two io-PA and two states qi isin Qi say that q1
simulates q2 written q2le q1 if there exists a surjective mapf Q1 7rarr Q2 such that
forallα st q2αminusrarr2 π2 existπ1 isin Π(Q1)
dArr (49) q1αminusrarr1 π1
π2(qprime2) =sumf(qprime1)=qprime2
π1(qprime1)
π1(qprime1) gt 0rArr f(qprime1) le qprime1
Observe that since we consider only deterministic io-PAthere exists at most one π2 such that q2
αminusrarr2 π2 hence thereis no need to quantify over π2 in the precondition of (49) Inprobability theory relation π2(qprime2) =
sumf(qprime1)=qprime2
π1(qprime1) writesπ2 = f(π1) Say that M1 simulates M2 written M2leM1 ifq20leq10 Simulation relation is preserved by composition IfM2leM1 then every strategy ϕ2 Q2 7rarr Σ2 defined over M2
has its counterpart into a matching strategy ϕ1 Q1 7rarr Σ1
over M1 by setting ϕ1(q1) = ϕ2(f(q1)) For i = 1 2 letΩi = QN
i be the set of all sequences of states of Qi and let(ΩiPi) i = 1 2 be the two resulting probability spaces whenmatching strategies are used for M1 and M2 Then the mapf induces a measurable map ψ = (f f ) Ω1 7rarr Ω2 suchthat
intZ(ω2)dP2(ω2) =
intZ(ψ(ω1))dP1(ω1) In particular
the probability distributions with respect to P1 and P2 of anymeasurable function depending only on the successive actionsperformed are identical
The natural use of io-PAs for safetyreliability analysis isto capture faulty situations through states Component states
RR ndeg 8147
Contracts for System Design 45
are partitioned into safe states and faulty states that can beequipped with different fault labels (names of states can dothis no semantic adaptation is needed) The probabilistic partof io-PAs naturally captures the spontaneous occurrence offaults When in a faulty state a component outputs actionsthat can either be used to model fault propagation or maybe alarms for use in system supervision Input actions in afaulty state can be used to either model denial of servicefrom other components (thus resulting in a risk of movingto a faulty state) or may be reconfiguration actions Thusspontaneous occurrence of failures with fault propagation iscaptured by this framework To summarize io-PAs offer anatural framework in which to combine functional and safetyviewpoints
B Simple Modal Probabilistic Interfaces
By following the same steps as for Modal Interfacessee Definition 7 we can define Simple Modal ProbabilisticInterfaces as pairs C = (Cmay Cmust) of io-PAs There is nonew difficulty in doing this Expressiveness of this frameworkhowever is modest whence the attribute ldquosimplerdquo When usedin the context of safetyreliability analysis Simple ModalProbabilistic Interfaces support the specification of fault ac-commodation in systems For example one can specify abouta componentbull that it does not accommodate denial of service inputs
representing fault propagation are disallowed (ldquomust notoccurrdquo)
bull that it must be prepared to possible denial of serviceinputs representing fault propagation are allowed (ldquomustbe acceptedrdquo)
bull that it never generates spontaneous failures actions lead-ing to a probabilistic state from which a faulty state can beimmediately reached are disallowed (ldquomust not occurrdquo)
bull that spontaneous failures are unavoidable actions leadingto a probabilistic state from which a faulty state can beimmediately reached are allowed (ldquomust be acceptedrdquo)
One could argue that io-PA by themselves offer a similarexpressiveness by playing with probabilities Simple ModalProbabilistic Interfaces however offer the full algebra ofcontracts which io-PA donrsquot
C Bibliographical note
This note focuses on interface types of framework Thereader is referred to the bibliographical note of Section VII-Gfor extensions of AG-contracts addressing probability
Exactly like the Interval Markov Chain (IMC) for-malism [116] they generalize Constraint Markov Chains(CMC) [50] are abstractions of a (possibly infinite) sets ofDiscrete Time Markov Chains Instead of assigning a fixedprobability to each transition transition probabilities are keptsymbolic and defined as solutions of a set of first orderformulas Variability across implementations is made possiblenot only with symbolic transition probabilities but also thanksto the labelling of each state by a set of valuations or setsof atomic propositions This allows CMCs to be composed
thanks to a conjunction and a product operators While theexistence of a residuation operator remains an open problemCMCs form an interface theory in which satisfaction andrefinement are decidable and compositions can be computedusing quantifier elimination algorithms In particular CMCswith polynomial constraints form the least class of CMCsclosed under all composition operators Abstract ProbabilisticAutomata (APA) [79] is another specification algebra withsatisfaction and refinement relations product and conjunctioncomposition operators Despite the fact that APAs generalizeCMCs by introducing a labeled modal transition relationdeterministic APAs and CMCs coincide under the mild as-sumption that states are labeled by a single valuation Forboth formalisms parallel composition is restricted to non-interacting components since alphabets of actions must bedisjoint
Our formalism of Simple Modal Probabilistic Interfaces ex-hibits the whole contract algebra Regarding limitations unlikeIMC CMC and APA this model does not allow for specifyingfamilies of transition probabilities and hence it cannot helpfor quantitative reasoning about reliability analysis
XI THE PARKING GARAGE AN EXAMPLE INREQUIREMENTS ENGINEERING
In this section we develop the parking garage exampleintroduced in Section IV-C Some of the material is repeatedfor better readability Despite being simple and small this ex-ample quickly becomes complex for reasons that are intrinsicto the formal management of requirements The MICA tooldeveloped by Benoicirct Caillaud was used to develop it [49]
Requirements are written in constrained English languageand then translated into Modal Interfacesmdashwhile the pre-sented translation is manual automatic translation can beenvisioned50 Once this is completed contracts are formallydefined and the apparatus of contracts can be used In par-ticular important properties regarding certification can beformally defined and checked eg consistency compatibilitycorrectness and completeness In addition support is providedfor turning top-level requirements into an architecture of sub-systems each one equipped with its own requirements Thelatter can then be submitted to independent suppliers forfurther development
A The contract framework
We shall use Modal Interfaces (with variable alphabet) asdeveloped in Sections VIII-C and subsequent ones There arethree main reasons for this choice
1) By offering the may and must modalities Modal Inter-faces are well suited to express mandatory and optionalbehaviors in the specification which we consider impor-tant for requirements engineering
50In fact the contract specification languages proposed in the projectsSPEEDS [29] and CESAR (httpwwwcesarprojecteu) are examples oftranslations from a constrained English language to a formal models ofcontracts similar to Modal Interfaces
RR ndeg 8147
Contracts for System Design 46
2) Being large sets of requirements structured into chaptersrequirements documents are a very fragmented style ofspecification Only Modal Interfaces offer the neededsupport for an accurate translation of concepts such asldquoset of requirementsrdquo ldquoset of chaptersrdquo together with aqualification of who is responsible for each requirement(the considered component or sub-system versus itsenvironment)
3) As we shall see at the top-level conjunction prevailsHowever as soon as the designer refines the top-levelrequirements into an architecture of sub-systems com-position enters the game Turning a conjunction of top-level requirements into a composition of sub-systemsspecifications thus becomes a central task Only ModalInterfaces provide significant assistance for this
Overall the problem considered in claim 3) can be stated asfollows The designer begins with some system-level contractC which is typically specified as a conjunction of viewpointsandor requirements The designer guesses some topologicalarchitecture by decomposing the alphabet of actions of C as
Σ =⋃iisinI Σi Σi = Σin
i ] Σouti (50)
such that composability conditions regarding inputs and out-puts hold Once this is done we expect our contract frameworkto provide help in generating a decomposition of C asotimes
iisinI Ci C (51)
where sub-contract Ci has alphabet Σi = Σini ] Σout
i Guess-ing architectural decomposition (50) relies on the designerrsquosunderstanding of the system and how it should naturallydecomposemdashthis typically is the world of SysML Findingdecomposition (51) is however technically difficult in that itinvolves behaviors The algorithmic means that were presentedin Section VIII-E provide the due answer In this ParkingGarage example we will use both the abstracted projectionand the restriction that were developed in that section
B Top level requirements
In this section we begin with the top-level requirementsThe system under specification is a parking garage subjectto payment by the user At its most abstract level the re-quirements document comprises the different chapters gatepayment and supervisor see Table VIII The gate chapterwill collect the generic requirements regarding entry and exitgates These generic requirements will then be specialized forentry and exit gates respectively
0
gate_close
1gate_opengate_close
vehicle_passgate_open
Figure 7 Requirement Rg1 specified as an io-automaton Prefix ldquordquoindicates an input and prefix ldquordquo indicates an output
gateRg1ldquovehicles shall not pass when gate is closedrdquo see Fig 7Rg2 after vehicle_pass vehicle_pass is forbiddenRg3 after gate_open gate_open is forbidden and
after gate_close gate_close is forbiddenpaymentsupervisor
Table VIIITHE TOP-LEVEL SPECIFICATION WITH CHAPTER gate EXPANDED
REQUIREMENTS WRITTEN IN italics ARE ASSUMPTIONS UNDER WHICHgate SHOULD OPERATE
Focus on the ldquogaterdquo chapter It consists of the three re-quirements shown on Table VIII Requirement Rg1 is bestdescribed by means of an io-automaton shown in Figure 7mdashwe provide an informal textual explanation for it betweenquotes51 The other two requirements are written using con-strained natural language which can be seen as a boilerplatestyle of specification Prefix ldquordquo indicates an input and prefixldquordquo indicates an output
The first two requirements are not under the responsibilityof the system since they rather concern the car driver Thus itdoes not make sense to include them as part of the guaranteesoffered by the system Should we remove them This wouldbe problematic If drivers behave the wrong way unexpectedthings can occur for sure The conclusion is that 1) we shouldkeep requirements Rg1 and Rg2 and 2) we should handlethem differently than Rg3 which is a guarantee offered by thesystem Indeed Rg1 and Rg2 are assumptions under whichthe gate operates as guaranteed In the sequel assumptions arewritten in italics
So far we have specified gate as a list of requirementsRequirement Rg1 specified as an io-automaton can be con-sidered formal Requirements Rg2 and Rg3 are formulatedin constrained natural language and are ready for subsequentformalization eg as io-automata Are we done Not yetWe need to give a formal meaning to what it means to havea collection of requirements and what it means to distinguishassumptions from guarantees The contract framework wedevelop next will provide support for this
C Formalizing requirements as contracts
We shall use Modal Interfaces (with variable alphabet) asdeveloped in Sections VIII-C and subsequent ones Thuswe first need to explain how the specification of ldquogaterdquo inTable VIII translates into Modal Interfaces
We first observe that each requirement Rgj of Table VIIIis a sentence that can be formalized as an io-automaton see
51 We take the convention that the variables of the resulting io-automatonare those mentioned in the text of the requirement Some adjustment is neededto this convention however as exemplified by Figure 7 Suppose that somerequirement says ldquogate_open never occursrdquo This is translated by havingno mention of gate_open in the corresponding io-automaton To expressthis ldquonegativerdquo fact we must keep track of the fact that gate_open belongsto the alphabet of actions of the io-automaton Thus when performing thetranslation the explicit list of inputs and outputs should be explicitly givenTo avoid such additional notational burden we have cheated by omitting thisunless necessary
RR ndeg 8147
Contracts for System Design 47
Figure 7 for such a formalization of requirement Rg1 Ac-cordingly each chapter D = gatepaymentsupervisorof Table VIII is structured as a pair
D = ((A1 Am) (G1 Gn)) (52)
where the Ais (the assumptions) and the Gjs (the guarantees)are io-automata in which all involved actions possess thesame status (input or output) throughout all Ais and Gjs Thetranslation of a specification of the form (52) into a ModalInterface is performed by applying the following two series ofrules
Rules 1 We adopt the following rules for the translation ofguarantees (in the form of io-automata) into Modal InterfacesRG
1 Unless otherwise explicitly stated transitions labeledby an output action of the considered system are givena may modality the rationale for doing this is that thedefault semantics for guarantees is ldquobest effortrdquo A mustmodality is assigned if the requirement specifies itmdashegby having a ldquomustrdquo in the sentence
RG2 Transitions labeled by an input action of the considered
system are given a must modality the rationale for doingthis is that as part of its guarantees the component mustnot refuse an input that is ldquolegallyrdquo submitted by theenvironment
RG3 Guarantees in a same requirements chapter D combine
by conjunctionApplying Rules 1 to the set of guarantees of D yields thecontract encoding these guarantees denoted by GD 2
Performing this for the single guarantee Rg3 of gate yieldsthe Modal Interface shown in Figure 8
0 1gate_opengate_close
0 1gate_opengate_close
Figure 8 Translating the guarantee Rg3 of gate as an io-automaton (top)and then as a Modal Interface Ggate (bottom) using Rules 1
Rules 2 We adopt the following rules for the translationof assumptions (in the form of io-automata) into ModalInterfacesRA
1 We exchange the status inputoutput in every assump-tion thus taking the point of view of the environment
RA2 Having done this we apply Rules 1 to the assumptions
So far this yields a draft Modal Interface A that must besatisfied by every environment
RA3 This is not enough however as we really want envi-
ronments that submit all legal stimuli To ensure this wesimply turn in A all may transitions to must transitionswhich yields A
Applying Rules 2 to the set of assumptions of D yields theModal Interface AD encoding these assumptions 2
Performing this for the assumptions Rg1 and Rg2 of gateyields the Modal Interface shown in Figure 9
1 0
gate_close
1gate_opengate_close
gate_openvehicle_pass
2 0
gate_open
1vehicle_passgate_open
3 (11)
gate_close
(10)
gate_opengate_closevehicle_pass
gate_open
4 0
gate_close
1gate_openvehicle_passgate_close
gate_open
Figure 9 Translating the assumptions of gate as a Modal Interface Agate
using Rules 2 1 translation of Rg1 2 translation of Rg2 3 the resultingconjunction 4 the final result after applying rule RA
3 and renaming the states
So far we have represented any chapter D of the require-ments document as a pair of Modal Interfaces (AD GD) withmirroring inputoutput statuses for their actionsmdashevery inputof AD is an output of GD and vice-versa It is the merit ofModal Interfaces to allow for a direct representation of thispair of assumption and guarantee in the form of a single ModalInterface by using the following formula for A and G twoModal Interfaces with mirroring inputoutput statuses for theiractions
(AG) is represented by the quotient (AotimesG)A (53)
which is the contract characterizing the components thatimplement G in the context of A see Section V-E Performingthis for the whole chapter gate yields the Modal Interfaceshown in Figure 10 Some comments are in order regardingthis Modal Interfacebull Regarding the guarantees offered by the component
Allowed outputs possess a may modality which reflectsthat Guarantees specify what the component may deliverOther actions are forbidden
bull Regarding the context of operation Legal inputs to thegate (eg vehicle_through when exiting state ldquo1rdquo) havea must modality This complies with the intuition that
RR ndeg 8147
Contracts for System Design 48
gate(x) where x isinentry exitRg1(x) ldquovehicles shall not pass when x_gate is closedrdquo see Fig 7Rg2(x) after vehicle_pass vehicle_pass is forbiddenRg3 after x_gate_open x_gate_open is forbidden and after x_gate_close x_gate_close is forbidden
paymentRp1 ldquouser inserts a coin every time a ticket is inserted and only thenrdquo Fig omittedRp2 ldquouser may insert a ticket only initially or after an exit ticket has been issuedrdquo Fig omittedRp3 ldquoexit ticket is issued after ticket is inserted and payment is made and only thenrdquo Fig omitted
supervisorRg1(entry)Rg1(exit)Rg2(entry)Rg2(exit)Rs1 initially and after entry_gate close entry_gate open is forbiddenRs2 after ticket_issued entry_gate open must be enabledRs3 ldquoat most one ticket is issued per vehicle entering the parking and tickets can be issued only if requested
and ticket is issued only if the parking is not fullrdquo see Fig 12Rs4 ldquowhen the entry gate is closed the entry gate may not open unless a ticket has been issuedrdquo Fig omittedRs5 ldquothe entry gate must open when a ticket is issuedrdquo Fig omittedRs6 ldquoexit gate must open after an exit ticket is inserted and only thenrdquo Fig omittedRs7 ldquoexit gate closes only after vehicle has exited parkingrdquo Fig omitted
Table IXREQUIREMENTS FOR THE TOP-LEVEL
0
1vehicle_pass
2gate_open
vehicle_passgate_closegate_open
gate_close3vehicle_pass
gate_close
vehicle_pass
Figure 10 Chapter gate of the top-level requirements document translatedinto a Modal Interface Cgate
the component should not refuse legal stimuli from itsenvironment Violation of the contract by its environmentoccurs when an illegal input is submitted by the environ-ment (vehicle_through when exiting state 0 or state 3) Asa consequence the whole contract gets relaxed which isreflected by the move to the special state ldquo2rdquo from whichany action is allowedmdashsuch a state is often called a ldquotoprdquostate Note that this top state resulted from computing thequotient
The same procedure applies to all chapters gate paymentand supervisor of the top-level textual specification shownin Table IX (it is an expansion of Table VIII) In particu-lar the Modal Interfaces encoding chapters payment andsupervisor of the top-level are displayed in Figures 11 to 13Figure 13 showing the contract associated to the supervisor isunreadable and the reader may wonder why we decided to putit here We indeed wanted to show that when contract designis performed formally and carefully top-level contracts rapidlybecome complex even for modest sets of requirements So theformal management of requirements and their translation intoformal contracts must be tool-assisted
Finally the whole top-level contract C is the conjunctionof the contracts representing chapters gate payment and
supervisor of the top-level requirements document
C = Cgate and Cpayment and Csupervisor (54)
Owing to the complexity of Csupervisor shown in Figure 13we do not show the Modal Interface C formalizing the fulldocument Nevertheless the latter was generated and can thenbe exploited as we develop next The above specificationonly covers the functional viewpoint of the system Otherviewpoints might be of interest as well eg regarding timingbehavior and energy consumption They would be developedwith the same method and combined to the above contract Cusing conjunction
D Sub-contracting to suppliers
In this section we apply the technique developed in Sec-tion VIII-E for generating an architecture of sub-systems withtheir associated sets of requirements Each sub-system canthen be submitted for independent development to a differentsupplier
The duty of the designer is to specify an architecture ldquoagravela SysMLrdquo as shown on Figure 14 Some comments arein order regarding this architecture The considered instanceof a parking garage consists of one entry gate one exitgate and one payment machine Compare with the top-levelspecification of Table IX The latter comprises a generic gatea payment machine and a supervisor each one with its setof requirements In contrast the architecture of Figure 14involves no supervisor The supervisor is meant to be dis-tributed among the two gates The architecture of Figure 14seems to be very loosely coupled First the PaymentMachineseems to be totally independent In fact the ticket that isinserted in the exit gate must coincide with the one issued bythe PaymentMachine It turns out that this reflects a missingassumption regarding the environment of the system (namelythe user of the parking) Then the two gates seem to have the
RR ndeg 8147
Contracts for System Design 49
0 1ticket_insert_payment 2
coin_insert_paymentticket_insert_payment
3
coin_insert_payment
ticket_insert_paymentcoin_insert_paymentexit_ticket_issue
exit_ticket_issueticket_insert_paymentcoin_insert_payment
Figure 11 Chapter payment of the top-level requirements documenttranslated into a Modal Interface Cpayment
(a0)
vehicle_exit (b0)request_enter
(a1)vehicle_enter
request_entervehicle_exit
ticket_issue
vehicle_enter
vehicle_exit(b1)
request_enter
(a2)
vehicle_enter
vehicle_exitticket_issuerequest_enter
vehicle_enter
vehicle_exit
vehicle_enter
(b2)request_enter
vehicle_exit
vehicle_enter
request_enter
Figure 12 Modal Interface for Rs3
0
entry_gate_close
1
exit_ticket_insert
7
vehicle_entervehicle_exit
44
request_enter
entry_gate_closeexit_ticket_insert
2
exit_gate_open
vehicle_entervehicle_exit
43
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
3
request_enter
vehicle_enter
75
vehicle_exit
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
4
ticket_issue
vehicle_enter
72
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
vehicle_enter
5
vehicle_exit
11
entry_gate_open
exit_gate_openexit_ticket_insertexit_gate_closeentry_gate_closevehicle_enterentry_gate_openvehicle_exitrequest_enter
ticket_issue
vehicle_entervehicle_exit
exit_ticket_insertrequest_enter
6
exit_gate_open
8
exit_gate_close
59
entry_gate_open
vehicle_enter
vehicle_exit exit_ticket_insertrequest_enter
exit_gate_open
exit_gate_close
58
entry_gate_open
vehicle_entervehicle_exit
request_enter
9
exit_ticket_insert
45
entry_gate_open
exit_gate_open
vehicle_entervehicle_exitexit_ticket_insert
request_enter
10
entry_gate_open
vehicle_exit
entry_gate_openexit_ticket_insertrequest_enter
exit_gate_open
entry_gate_close
47
ticket_issue
68
vehicle_enter
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insertrequest_enter
12
ticket_issue
69
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
49
vehicle_enter
13
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
19
request_enter
77
entry_gate_open
50
vehicle_exit
vehicle_enter
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
20
entry_gate_open
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
21
ticket_issue
34
vehicle_enter
71
entry_gate_close
vehicle_exit
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
22
vehicle_enter
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
23request_enter
84
entry_gate_open
127
vehicle_exit
vehicle_enter
exit_ticket_insertrequest_enter
exit_gate_open
24
vehicle_exit
33
entry_gate_open
vehicle_entervehicle_exit
exit_ticket_insertrequest_enter
16
exit_gate_open
17
exit_gate_close
25
entry_gate_open
vehicle_enter
vehicle_exit
exit_gate_openexit_ticket_insertrequest_enter
exit_gate_close
26
entry_gate_open
vehicle_entervehicle_exit
request_enter
18
exit_ticket_insert
114
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
80
entry_gate_open
vehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
81ticket_issue
79
entry_gate_close
99
vehicle_enter
vehicle_exit
exit_gate_open
entry_gate_open
exit_ticket_insertrequest_enter
82vehicle_enter
vehicle_entervehicle_exitexit_gate_open
exit_ticket_insert
31
request_enter
83
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
32
entry_gate_open
vehicle_exitexit_ticket_insertrequest_enter
entry_gate_open
exit_gate_open
vehicle_enter
91
entry_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
vehicle_enter
92
entry_gate_close
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
35
request_enter
101
entry_gate_close
entry_gate_open
60
vehicle_exit
vehicle_enter
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
36
vehicle_exit
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
37
exit_gate_open
125
exit_gate_close
93
entry_gate_close
entry_gate_open
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
exit_gate_open
38
vehicle_exit
exit_gate_close
94
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
39
exit_gate_open
40
exit_gate_close
entry_gate_close
entry_gate_open
vehicle_enter
ticket_issue
vehicle_exitexit_ticket_insertrequest_enter
exit_gate_open
exit_gate_close
entry_gate_open
73entry_gate_close
vehicle_entervehicle_exit
ticket_issue
request_enter
41
exit_ticket_insert
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
ticket_issue
entry_gate_open
exit_ticket_insertrequest_enter
42
exit_gate_open
entry_gate_close
entry_gate_close
ticket_issue
vehicle_enter
entry_gate_open
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
exit_gate_open vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
exit_ticket_insert
entry_gate_close
request_enterentry_gate_open
46
ticket_issue
124
vehicle_enter
vehicle_exit
entry_gate_open
request_enter
exit_ticket_insert
126
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
48
vehicle_enter
vehicle_entervehicle_exit
exit_gate_open
request_enterexit_ticket_insert
113
entry_gate_open
vehicle_exit
request_enter
exit_ticket_insertentry_gate_open
exit_gate_open
105
entry_gate_close
vehicle_enter
request_enter
vehicle_enter
exit_ticket_insert
entry_gate_openexit_gate_open
56
vehicle_exit
74entry_gate_close
vehicle_exit
exit_ticket_insertentry_gate_open
57
exit_gate_open
entry_gate_close
123
exit_gate_close
vehicle_enter
request_enter
vehicle_exit
exit_ticket_insert
entry_gate_openexit_gate_open
request_enter
76
entry_gate_close
exit_gate_close
61
vehicle_enter
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
14
ticket_issue
entry_gate_close
vehicle_enter
vehicle_exit
exit_gate_closeentry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
15
vehicle_enter
vehicle_exit
vehicle_enter
request_enter
exit_gate_openexit_ticket_insert
vehicle_exit
86
entry_gate_open
exit_gate_close
vehicle_entervehicle_exit
request_enter
entry_gate_openexit_ticket_insert
51
exit_gate_open
52
exit_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit
exit_ticket_insertexit_gate_open exit_gate_close
vehicle_entervehicle_exit
request_enter
53
exit_ticket_insert
entry_gate_open
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
54
exit_gate_open
67entry_gate_open
request_enter
vehicle_enter
vehicle_exit
exit_ticket_insertexit_gate_open
55
entry_gate_open
entry_gate_close
request_enter
vehicle_exit
exit_ticket_insert
entry_gate_openexit_gate_open
vehicle_enter
vehicle_enter
entry_gate_open
exit_ticket_insertexit_gate_open
70
request_enter
62
vehicle_exit
entry_gate_close
vehicle_enter
ticket_issue
entry_gate_open
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
entry_gate_close
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_exit
vehicle_entervehicle_exit
ticket_issue
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_close
exit_gate_open
vehicle_enter
ticket_issue
exit_gate_close
vehicle_exit exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
entry_gate_open
exit_ticket_insert
63
exit_gate_open
64exit_gate_close
entry_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit exit_ticket_insertexit_gate_open
exit_gate_close
entry_gate_close
entry_gate_close
vehicle_entervehicle_exit
request_enter
65
exit_ticket_insert
entry_gate_open
entry_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
66exit_gate_open
entry_gate_open
entry_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit
exit_ticket_insertexit_gate_open
entry_gate_close
vehicle_exit
request_enter
exit_gate_open
exit_ticket_insertentry_gate_open
vehicle_enter
vehicle_entervehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insert
78
request_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
vehicle_enter
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
vehicle_exit
exit_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
exit_gate_close
vehicle_enter
request_enter
vehicle_exit
entry_gate_closeexit_gate_openexit_ticket_insert
entry_gate_close
vehicle_exit
request_enter
exit_ticket_insert
entry_gate_open
vehicle_enter
vehicle_entervehicle_exit
exit_ticket_insert
request_enter
104entry_gate_close
112entry_gate_open
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enter
95entry_gate_close
entry_gate_openvehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
exit_ticket_insert
entry_gate_close
request_enterentry_gate_open
115
ticket_issue
98
vehicle_enter
vehicle_exit
exit_ticket_insert
entry_gate_open
request_enter
116
vehicle_enter
vehicle_entervehicle_exit
exit_ticket_insert
30
request_enter
107
entry_gate_open
vehicle_entervehicle_exit
exit_ticket_insert
request_enter97
entry_gate_open
vehicle_exit
exit_ticket_insert
request_enterentry_gate_open
vehicle_enter
96entry_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
89
request_enter
106
entry_gate_closeentry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insert
90
request_enter
100
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
entry_gate_closeexit_ticket_insertrequest_enter
exit_gate_open
vehicle_enter
entry_gate_closeexit_gate_openexit_ticket_insertrequest_enter
vehicle_exit
vehicle_entervehicle_exit
ticket_issue
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_close
exit_gate_open
vehicle_enter
ticket_issue
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
vehicle_enter
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
102
vehicle_exit
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
103
exit_gate_open
exit_gate_close
vehicle_enter
vehicle_exit
request_enterexit_ticket_insert
entry_gate_closeexit_gate_open
exit_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
request_entervehicle_enter
entry_gate_closeexit_ticket_insertentry_gate_open
exit_gate_open
request_enter
vehicle_enter
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insert
85
vehicle_exit
vehicle_exit
entry_gate_close
entry_gate_openexit_ticket_insert
exit_gate_open
request_enter
117
vehicle_enter
exit_gate_close
vehicle_exit
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insert
request_enter
87
vehicle_enter
exit_gate_close
exit_gate_close
entry_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
27
ticket_issue
vehicle_enter
vehicle_exit
exit_gate_close
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
28
vehicle_enter
vehicle_exit
vehicle_enter
exit_gate_close
exit_ticket_insertexit_gate_open
29request_enter
111
entry_gate_open
vehicle_exit
vehicle_enter
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
exit_gate_open
109
entry_gate_open
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
vehicle_enter
108
entry_gate_close
vehicle_exit
vehicle_enter
exit_gate_close
exit_gate_openexit_ticket_insert
88
request_enter
vehicle_exit
110
entry_gate_close
entry_gate_open
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
exit_gate_close
entry_gate_close
vehicle_entervehicle_exit
entry_gate_open
exit_ticket_insert
request_enter
entry_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enterentry_gate_close
vehicle_enter
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
exit_gate_close
entry_gate_close
entry_gate_open
exit_ticket_insert
exit_gate_open
vehicle_enter
request_enter
vehicle_exit
exit_gate_close
entry_gate_close
entry_gate_open
exit_ticket_insertexit_gate_open
vehicle_enter
vehicle_exit
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
exit_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enter
entry_gate_close
vehicle_exit
request_enter
vehicle_enterentry_gate_close
exit_ticket_insert
entry_gate_openexit_gate_open
exit_gate_close
vehicle_exit
request_enter
vehicle_enter
exit_ticket_insert
entry_gate_close
entry_gate_open
vehicle_exit
exit_gate_close
entry_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
128ticket_issue
vehicle_enter
vehicle_exit
exit_gate_close
exit_gate_open
entry_gate_open
exit_ticket_insertrequest_enter
129vehicle_enter
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insert
130
request_enter
122entry_gate_open
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
120
entry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
vehicle_enter
119entry_gate_close
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insert
118
request_enter
121
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_gate_close
entry_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
exit_gate_closeexit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
exit_gate_open
exit_gate_close
request_enter
exit_ticket_insertentry_gate_close
vehicle_exit
exit_gate_open
exit_gate_close
request_enter
vehicle_enter
entry_gate_close
exit_ticket_insertentry_gate_open
vehicle_entervehicle_exit
request_enter
exit_gate_open
entry_gate_open
exit_ticket_insert
exit_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
entry_gate_open
vehicle_exit
exit_ticket_insert
request_enter
vehicle_enter
entry_gate_closeentry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
vehicle_enter
exit_ticket_insertrequest_enter
entry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
entry_gate_close
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_open
Figure 13 Chapter supervisor of the top-level requirements documenttranslated into a Modal Interface Csupervisor for a capacity of two for theparking garage
shared input ldquovehicle exitrdquo as their only interaction But thisshared input is involved in requirement Rs3 which forbidsthe entry if the parking is full
In Figure 15 we show the result of applying to the ar-chitecture of Figure 14 the Algorithm 1 developed in Sec-tion VIII-E which yields by construction a refinement of thetop-level contract C by a decomposition into local contracts
C C(ΣEntryGate)otimes C(ΣExitGate)otimes C(ΣPaymentMachine)
(55)
Local contract C(ΣEntryGate) is the more complex one becauseit involves countingmdashwe have assumed a capacity of two tokeep it simple Remarkably enough the decomposition (55)involves small sub-systems compared to Csupervisor (Fig 13)and the global contract C the restriction operation is to beacknowledged for this strong reduction in size
E The four ldquoCrdquo
Requirements capture and management are important mat-ters for discussion with certification bodies These bodieswould typically assess a number of quality criteria from egthe following list elaborated by INCOSE [114] AccuracyAffordability Boundedness Class Complexity Completeness
request enter
ticket issue
entry gate open
entry gate closeEntryGate
vehicle enter
vehicle exit
exit ticket insert ExitGateexit gate open
exit gate close
ticket insert payment
coin insert paymentPaymentMachine exit ticket issue
Figure 14 System architecture as specified by the designer
0
vehicle_exit
1
request_enter
3
vehicle_enter
request_entervehicle_exit
2ticket_issue
vehicle_enter
request_entervehicle_exit
vehicle_enter
4
entry_gate_open
entry_gate_closeentry_gate_open
ticket_issuevehicle_enterrequest_entervehicle_exit
entry_gate_close
request_entervehicle_exit
5vehicle_enter
vehicle_enter
6
request_enter
15
entry_gate_close
16
vehicle_exit vehicle_enter
request_enter
7
vehicle_exit
8
entry_gate_close
entry_gate_closevehicle_enter
request_entervehicle_exit
vehicle_exit
vehicle_enter
request_enter
9ticket_issue
vehicle_exit
vehicle_enter
request_enter
10
entry_gate_open
vehicle_exit
entry_gate_closerequest_enter
11
vehicle_enter
vehicle_enter
vehicle_exit12
request_enter
14entry_gate_close
vehicle_enter
vehicle_exit
request_enter
13entry_gate_close
vehicle_enter
vehicle_exit request_enter
vehicle_enter
request_enter
vehicle_exit
vehicle_exit
vehicle_enter
request_enter
entry_gate_close
vehicle_enter
request_entervehicle_exit
0 1exit_ticket_insert
4
vehicle_exit
exit_ticket_insert
2
exit_gate_open
vehicle_exit
exit_ticket_insert
3vehicle_exitexit_gate_close
exit_ticket_insertvehicle_exit
exit_ticket_insertexit_gate_close
vehicle_exitexit_gate_open
0 1ticket_insert_payment 2
coin_insert_paymentticket_insert_payment
3
coin_insert_payment
ticket_insert_paymentcoin_insert_paymentexit_ticket_issue
exit_ticket_issueticket_insert_paymentcoin_insert_payment
Figure 15 The three restrictions of the global contract C for the three sub-systems EntryGate (top) ExitGate (mid) and PaymentMachine (bottom)
Conciseness Conformance Consistency Correctness Criti-cality Level Orthogonality Priority Risk Unambiguousnessand Verifiability In this section we focus on four quality crite-ria that are considered central by certification authorities andare relevant to contracts namely Completeness CorrectnessConsistency and Compatibility
1) Consistency amp Compatibility Consistency and compat-ibility have been formally defined in the meta-theory seeSection V and Table IV therein In particular those formaldefinitions can be formally checked Thus the question ariseswhether these formal definitions suitably reflect the commonsense meaning of these terms
According to the common meaning a set of requirementsis consistent if it is not self-contradicting The intent is thatthere is no point in trying to implement an inconsistent set ofrequirements as no such implementation is going to exist
RR ndeg 8147
Contracts for System Design 50
It turns out that the existence of implementations is theformal definition of consistency according to the meta-theoryClearly the formal definition of consistency meets its commonsense interpretation We illustrate consistency on the top-levelspecification of Table IX Referring to this table we havestrengthened Rs6 and Rs7 in some way Lack of consistencyis revealed by checking the mutual consistency of these tworequirements with the requirement Rg3 applied to the exitgate After the following scenario
exit_ticket_insertexit_gate_openexit_ticket_insert
event exit_gate_open has modality must in left-hand interfaceand modality cannot in right-hand interface
According to the common meaning an architecture of sub-systems as characterized by their respective specifications iscompatible if these sub-systems ldquomatch togetherrdquo in that theycan be composed and the resulting system can interact withthe environment as expectedmdashuse cases can be operated aswished As explained in Table IV of Section V this is theformal definition of compatibility in the meta-theory Againthe formal definition of compatibility meets its common senseinterpretation
2) Correctness Correctness can only be defined withreference to another specification We propose to translateldquocorrectnessrdquo by one of the following properties dependingon the case (see Table IV for the notations)bull ldquois a correct implementation ofrdquo written |=Mbull ldquois a correct environment ofrdquo written |=Ebull ldquorefinesrdquo written
3) Completeness Completeness raises a difficulty Al-though the term ldquocompletenessrdquo speaks for itself it cannotbe formally defined what it means to be complete for a top-level specification in the form of a set of requirements Thereason is that we lack a reference against which completenesscould be checked Hence the only way to inspect a top-level specification for completeness is to explore it manuallyThe best help for doing this is to execute the specificationThus specifications must be executable Fortunately ModalInterfaces are executable and this way undesirable behaviorscan be revealed We illustrate this on the top-level specificationof Table IX where Rs6 is changed into ldquoexit gate must openafter an exit ticket is insertedrdquo (by omitting ldquoand only thenrdquo)Lack of completeness is revealed by simulation The followingscenario can occur
exit_ticket_insertexit_gate_openvehicle_exitexit_gate_closeexit_gate_open
which allows vehicles to exit without having inserted an exitticket an unwanted behavior This reveals that the specificationwas not tight enough ie incomplete So far for completenessof the top-level specification
In contrast completeness can be formally defined whena reference C is available We propose to say that Cprime isincomplete with reference to C if
1) Cprime does not refine C but2) there exists Cprimeprime Cprime such that Cprimeprime is consistent and
compatible and refines CThe rationale for this definition is that Cprime is not precise enoughbut can be made so by adding some more requirementsNote that Cprime is incomplete with reference to C if and onlyif Cprime and C is consistent and compatible This criterion is ofparticular relevance when Cprime =
otimesiisinI Ci is an architecture of
sub-contracts where Ci is to be submitted to supplier i forindependent development
F Discussion
Requirements engineering is considered very difficult Re-quirements are typically numerous and very difficult to struc-ture Requirements concern all aspects of the system func-tion performance energy reliabilitysafety Hence systemsengineers generally use several frameworks when expressingrequirements The framework of contracts expressed as ModalInterfaces that we have proposed here improves the situationin a number of aspectsbull It encompasses a large part of the requirements52
bull It can accommodate different concrete formalisms Inour example we have blend textual requirements withrequirements specified as state machines Richer for-malisms such as Stateflow diagrams can be accom-modated in combination with abstract interpretationtechniquesmdashthis is not developed here
bull We have shown how to offer formal support to importantproperties such as the four Crsquos during the process ofcertification
bull We have proposed a correct-by-construction approach tothe difficult step of moving from the top-level specifi-cation in the form of a requirements document to anarchitecture of sub-contracts for the suppliers53
XII CONTRACTS IN THE CONTEXT OF AUTOSAR
In this section we use AUTOSAR as an industrial exampleof how to leverage contracts within an existing standard toextend it
A The AUTOSAR context
AUTOSAR54 is a world-wide development partnership in-cluding almost all players in the automotive domain electronics
52 According to figures that were given to us by industrials 70-80 of therequirements can be expressed using the style we have developed here Otherrequirements typically involve physical characteristics of the system or definethe range for some parameters
53 The framework of AssumeGuarantee contracts that is used in Section XIIdoes not offer this for two reasons First it lacks the quotient and secondlocal alphabets are not properly handled In contrast AssumeGuarantee con-tracts are very permissive in how they can be expressed In particular dataflowdiagrams (Simulink) can be used to express assumptions and guarantees
54httpwwwautosarorg
RR ndeg 8147
Contracts for System Design 51
supply chain It has been created with the purpose of de-veloping an open industry standard for automotive softwarearchitectures To achieve the technical goals of modularityscalability transferability and reusability of functions AU-TOSAR provides a common software infrastructure based onstandardized interfaces for the different layers The AUTOSARproject has focused on the objectives of location indepen-dence standardization of interfaces and portability of codeWhile these goals are undoubtedly of paramount importancetheir achievement may not be sufficient for improving thequality of software systems As for most other embeddedsystem car electronics is characterized by functional as well asnon functional properties assumptions and constraints [111]Therefore an AUTOSAR based development process benefitsfrom adding contracts as the this section will demonstrate
B The contract framework
Extensive use of SimulinkStateflow modeling is performedfor system design in the automobile sector It is thus naturalto try reusing this modeling style for defining contractsSince AG contracts of Section VII simply rely on specify-ing assertions regardless of how they are actually describedwe use AG contracts for this AUTOSAR case study SinceSimulinkStateflow diagrams are very flexible contracts canbe expressed for all viewpoints (function timing safety) Inturn reasoning on such contracts is beyond the capability ofautomatic tools Consequently checking for implementationand refinement relations will be performed manually on smallmodels In contrast the powerful contract algebra developedin the meta-theory is fully generic and does not depend onthe nature and complexity of the considered models Themodularity it offers will thus be the main help offered bycontract based design in this case study As another featureof this this study the distinction between ldquohorizontalrdquo andldquoverticalrdquo contracts is used see Section IV-D4 Finally thefollowing variation of AG contracts is used
Assertions consist of a timed extension of the weaklysynchronous model (18) namely
P sube ((Σ 7rarr D) cup R+)lowast cup ((Σ 7rarr D) cup R+)
ω (56)
meaning that the assertion proceeds by a succession of stepsconsisting of either assignment of values to variables (includ-ing the special status absent for multiple-clocked assertions)or time progress Composition is by intersection P1timesP2 =def
P1 and P2 with alphabet equalization by inverse projection asin see Section VII-C Following Section VII-B componentsare tuples M = (ΣinΣout P ) where Σ = Σin cup Σout is thedecomposition of alphabet Σ into its inputs and outputs andP is an assertion following (56) Components must be free ofexception in the sense of Definition 4
A contract is a tuple C = (ΣinΣoutAs AwG) whereΣ = Σin cup Σout is the decomposition of alphabet Σ intoits inputs and outputs As and Aw the strong and weakassumptions and G the guarantees are assertions over ΣThe set EC of the legal environments for C collects all com-ponents E such that E sube A The set MC of all components
implementing C is defined by (As andAw)timesM sube G meaningthat implementations guarantee G under the condition that theenvironment satisfies the stronger condition AsandAw In otherwords in this framework legal environments are constrainedby strong assumptions only whereas the conjunction of strongand weak assumptions is required to guarantee G Weakassumptions are useful for design iterations in case strictobligations for the context of use may not be realizable
To conclude on this framework its difference is onlymethodological since any contract with strong and weakassumptions C = (ΣinΣoutAs AwG) is equivalent to anordinary AG contract (ΣinΣoutAsG or notAw) Thus thereader is referred to Section VII Adding time to the paradigmdoes not change anything to the relations or operators definedin that section
However adding time results in decidability and complexityissues The latter problem can be fixed in part by usingobservers see Sections V-G and VII Other proofs can be car-ried on manuallymdashthis is feasible for undecidable propertieswhen the needed reasoning only involves a small part of theanalyzed system involving few locally interacting componentsThe added value of our contract framework is to supportthe combination of proofs into a validation for the overallsystem taking into account detailed design decisions capturedin system and ECU configurations
C Exterior Light Management System
To illustrate the benefits of contract-based systems engineer-ing in AUTOSAR we consider as an example an excerpt of anExterior Light Management for an automobile55 We focus onthe parts responsible for sensing driver inputs and actuatingthe rear direction indicator lights and brake lights With thisexample we show how requirements can be refined to contractsand discuss the added value of contracts for negotiationsbetween OEM and suppliers We will also illustrate the useof vertical contracts eg to specify the expected latency ofthe communication solution and computations from the timingviewpoint and a failure hypothesis in terms of reliability
1) Function and timing We begin our study by showinghow AUTOSAR models can be enhanced with contracts
System
ext_pedal
ext_lamp
ext_tssext_wls
ext_rlaext_rra
Figure 16 Virtual Functional Bus model
The Virtual Functional Bus model Figure 16 shows the Vir-tual Functional Bus (VFB) model encompassing the exteriorlights management This software composition specifies the
55A case-study from the German SPES2020 project
RR ndeg 8147
Contracts for System Design 52
interfaces exposed by the component to the sensors deliveringdriver inputs (brake pedal warn light button turn signallever) and to the actuators controlling the lights Ports witharrowheads denote an asynchronous data flow interface whichis a SenderReceiverInterface Here it is a special kind calledServiceInterface which means the data is provided by somelocal service located in the BasicSoftware stack of an ECU(Electronic Computing Unit) The requirements document ofthe system contains one timing-related requirementbull R1 If the driver presses the brake pedal the brake lights
must light not later than 25msWe formalize in Table X this requirement as a contract by
using a pattern-based contract specification language (terms inbold-face are keywords)
CR1
As whenever ext_pedal occursext_pedal does not occur during[ext_pedalext_lamp]ext_pedal occurs sporadicwith minperiod 25ms
Aw trueG delay between ext_pedal and
ext_lamp within [0ms25ms]
Table XHORIZONTAL CONTRACT OF VFB MODEL
Indicator
BrakePedalSensor PedalToLamp
TurnSwitchSensor
WarnLightsSensor
SwitchLightActuator
RearLeftActuator
RearRightActuator
BrakeLampActuator
ext_pedal
pos_pedal_out lamp_intensity ext_lamp
ext_tss
ext_wls
tss
wls
ext_rla
ext_rra
rla_signalrra_signal
emcyBrake
pos_pedal_in
Figure 17 Decomposed Virtual Functional Bus model
Decomposed VFB Software composition Figure 17 showsthe decomposed VFB model AssemblySwConnectors link theports of parts of the composition and are subject to commu-nication refinement The components used in the compositionand their functions are as followsbull BrakePedalSensor receives the position of the brake pedal
(ext_pedal) and distributes it to other components
bull PedalToLamp reads the brake pedal position (pos_pedal)and calculates requested brightness of the brake indicatorlights (lamp_intensity)
bull BrakeLampActuator reads the requested brightness of thebrake indicator lights (lamp_intensity) and actuates thebrake lamps accordingly (ext_lamp)
bull TurnSwitchSensor reads the position of the lever and for-wards it (tss)
bull WarnLightsSensor reads status of the warn blink button andforwards it (wls)
bull Indicator reads the status of the warn blink button the leverposition and cyclically toggles the left and right signals(rla_signal rra_signal)
bull Rear(Left|Right)Actuator reads its input signal ((rla|rra)_signal)and actuates the bulb (ext_(rla|rra))
bull SwitchLightActuator reads left and right signals((rla|rra)_signal) and provides feedback on the dashboard
Horizontal (functional) contracts associated to the VFBmodel For the decomposed VFB model we derive horizontalcontracts specifying the desired IO behavior of the parts Asan example for the component BrakePedalSensor we state thecontracts shown in Table XI Contract CfIOBPS
specifies that
CfIOBPS
Afs whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Afw true
Gf whenever ext_pedal occurspos_pedal_out occurs
CfSIGNALBPS
Afs whenever pos_pedal_out occurs
pos_pedal_out does not occur during[pos_pedal_outpos_pedal_in]
Afw true
Gf whenever pos_pedal_out occurspos_pedal_in occurs
Table XIA SAMPLE OF THE HORIZONTAL CONTRACTS OF THE DECOMPOSED VFB
MODEL SUPERSCRIPT f REFERS TO ldquoFUNCTIONrdquo
provided that the pedal is not ldquomultiply pressedrdquo then thepos_pedal message traverses the BrakePedalSensor and then thewire following it with some unspecified delay In particular nomessage is lost due to a miss by this block Similar contractsare stated for all blocks of the VFB model thus resultingin a set Cf
IO of contracts For all AssemblySwConnectors ofthe composition horizontal contracts are specified that aresimilar to that of CfSIGNALBPS
resulting in a set CfSIGNAL
of contracts This contract scheme guarantees a reliable datatransport by each wire of the VFB model no matter how thecommunication is refined
So far we have stated contracts for each block and eachwire of the VFB model Compose the above contracts usingcontract composition (14) ie compute
CfVFB =otimes(otimes
C | C isin CfIO)
otimes(otimesC | C isin Cf
SIGNAL) (57)
RR ndeg 8147
Contracts for System Design 53
The guarantee offered by overall contract CfVFB is the con-junction of the guarantees of the constitutive contracts Hencecontract CfVFB guarantees that messages reliably traverse theVFB model with however an unspecified delay On the otherhand contract composition (14) assumes the conjunction ofall assumptions stated for each blockmdashthe guarantee offeredby CfVFB and the strong assumption of CR1
discharge all ofthese assumptions
At this point we observe that contract CfVFB involves notiming characteristics and thus functional contract CfVFB doesnot refine the initial contract CR1 To overcome this timingcontracts are added in the next step that will complement thisfunctional contract with timing viewpoint based on expectedperformance characteristics of the computing platform
Budgeting time using contracts We now state additionalcontracts such as the ones shown in Table XII Observethat for those contracts weak assumptions are used see Sec-tion XII-B regarding the motivations for doing this Observealso that we repeated the functional strong assumption56
Again stating similar contracts for each block and wire of the
CtIOBPS
Ats whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Atw ext_pedal occurs sporadic
with minperiod 15msGt delay between ext_pedal and
pos_pedal_out within [0ms15ms]
CtSIGNALBPS
Ats whenever pos_pedal_out occurs
pos_pedal_out does not occur during[pos_pedal_outpos_pedal_in]
Atw pos_pedal_out occurs sporadic
with minperiod 2msGt delay between pos_pedal_out and
pos_pedal_in within [0ms2ms]
Table XIITIMING CONTRACT OF DECOMPOSED VFB MODEL SUPERSCRIPT t
INDICATES THAT THESE CONTRACTS DEAL WITH TIMING
VFB model yields two sets CtIO and Ct
SIGNAL of contractsand we consider
CtVFB =otimes
(otimesC | C isin Ct
IO)otimes(otimesC | C isin Ct
SIGNAL)(58)
The next step is to combine for each component (blockor wire) of the VFB model the two functional and timingviewpoints using conjunction ie to compute
CVFB =otimes(otimes[
Cf and Ct]| (Cf Ct) isin CIO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin CSIGNAL
) (59)
where CIO collects for each block the pair of functional andtiming contracts associated with it and similarly for CSIGNAL
56 If we do not do this then when taking the conjunction of functionaland timing contracts the functional strong assumption gets absorbed by thestrong assumption of the timing contract since the latter is equal to T Seethe discussion regarding AssumeGuarantee contracts with variable alphabetsat the end of Section VII-C
At this point we observe that the architecture of the VFBmodel is a directed acyclic graph
Consider the conjunction C = Cf and Ct = (AG) for eachblock or wire As an example focus on block IOBPS whichis the first block of VFB seen as a directed acyclic graphRegarding the combination of strong and weak assumptionswe have A = Afs and Atw which is weaker than As theassumption of CR1
in Table X Regarding guarantees we haveG = Gf and Gt which ensures that messages traverse thecomponent without duplication or loss and with a delay lessthan the ldquominperiodrdquo of the input signal (15ms) Also guar-antee G offered by this block is strong enough to dischargethe assumption of the next wire when performing contractcomposition Reproducing the same reasoning inductivelyalong all blocks and wires of the VFB model seen as an acyclicgraph shows that
CVFB CR1(60)
Consequently submitting the pairs of contracts (Cf Ct) asso-ciated to each component for separate development possiblyby different suppliers will ensure correct integration (providedimplementations by the suppliers are correct with respect totheir contracts) In particular the component BrakePedalSensorbelongs to the chassis domain and is implemented by adifferent supplier than the other components
Discussion The above step of our contract based designmethodology leads to the following important notices
1) So far our proof steps were all manual Our contractbased reasoning however was instrumental in ensuring thatelementary proof steps were combined correctly Reasoningbased on intuition when component composition and view-point combination both occur is very likely to lead to wrongconclusions There is a strong added value in contract basedreasoning even if elementary proof steps are manual
2) Manual reasoning can be complemented by the use ofobservers Again it is important that the use of observerswhen component composition and viewpoint combination bothoccur is performed correctly Our development in Section V-Gprovides the formal support for this For the pattern basedlanguage used here a framework for checking refinement ofcontracts using an observer based strategy is described in [94]
3) The responsibility of establishing the sub-contracts sub-mitted to the different suppliers is assigned to the OEM inaccordance with his role as integrator Components belongingto different domains of a car (engine chassis etc) are likely tooriginate from different vendorssuppliers By using our abovereasoning the OEM can decompose its contract specificationspassing them to supplier(s) For example the componentBrakePedalSensor is the only one in the VFB model that belongsto the chassis domain and other components are developed byone or more different suppliers Thus in decomposition (59)the two sets of contracts CIO and CSIGNAL are partitioned
RR ndeg 8147
Contracts for System Design 54
eg for subcontracting to two different suppliers
Csupplier1VFB =
otimes(otimes[Cf and Ct
]| (Cf Ct) isin C1
IO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin C1
SIGNAL
)Csupplier2VFB =
otimes(otimes[Cf and Ct
]| (Cf Ct) isin C2
IO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin C2
SIGNAL
)Each supplier can then safely develop its own sub-systemindependently We develop this in the next sub-section
Implementation of software components and vertical as-sumptions Each of the software components being part ofthe software system composition (cf Figure 17) is a Compo-sitionSoftwareComponents as this allows the supplier to reusealready designed components We thus consider one suchcomponent with its contract C = Cf and Ct consisting of thefunctional contract Cf in conjunction with the timing contractCt The supplier can then follow two different approaches fordeveloping this component
In a first approach the supplier reuses a composition
C =otimes
iisinI Ci (61)
of off-the-shelf components available from a library Twosituations can then occurbull The easy case is when refinement holds C C This
means that for C = (As Aw G) guarantees are strongenough and assumptions are weak enough to implyrefinement with respect to the contract C specified bythe OEM
bull A more realistic (but also more delicate) case is when thefollowing weaker relations are satisfied
C Cf (62)G sube G (63)
As and Aw supe Afs andAfw (64)
but the conditions requested on timing assumptions forrefinement C C to hold are not satisfied
As and Aw 6supe Ats andAtw (65)
Under (65) composition from library C cannot be usedas such It can however still be used as a valid imple-mentation provided that some additional missing verticalassumption regarding timing is stated such that
As and Aw supe Ats andAtw and Atw︸ ︷︷ ︸for negotiation
(66)
(66) requires a negotiation in which additional verticalassumption Atw is returned back to the OEM as an ad-ditional performance requirement for the ECU platformIf this is accepted by the OEM then development by thesupplier using off-the-shelf components from the library(61) can proceed
The alternative approach is to implement the componentEventually this results in a composition of AtomicSoftwareCom-ponents This component type has an internal behavior specifi-cation comprising so called Runnables which are the smallest
executable entities known to AUTOSAR For each runnableactivation conditions are defined by means of RTEEvents con-trolled by the RuntimeEnvironment on the corresponding ECUand data accesses referring ports of the owning component AnRTEEvent can be configured to occur either cyclically (time-triggered) or by the data arrival on some input port of theowning component (event-triggered)
Figure 18 depicts the internal behavior of componentBrakePedalSensor This component consists of a single
BrakePedalSensor
BPSRunnable
pos_pedal_out
P=10ms
ext_pedal
Figure 18 Internal behavior of BrakePedalSensor-component
CfIBBPS
Afs whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Afw true
Gf whenever ext_pedal occurspos_pedal_out occurs
CtIBBPS
Ats whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Atw ext_pedal occurs sporadic
with minperiod 10msBPSRunnableact occurs each 10msdelay between BPSRunnableact andpos_pedal_out within [0ms10ms]
Gt delay between ext_pedal andpos_pedal_out within [0ms10ms + 10ms]
CprimetIBBPS
Aprimets whenever ext_pedal occursext_pedal does not occur during[ext_pedalpos_pedal_out]
Aprimetw ext_pedal occurs sporadicwith minperiod 10msBPSRunnableact occurs each 10msdelay between BPSRunnableact andpos_pedal_out within [0ms5ms]
Gprimet delay between ext_pedal andpos_pedal_out within [0ms10ms + 5ms]
Table XIIICONTRACTS FOR INTERNAL BEHAVIOR OF
BRAKEPEDALSENSOR-COMPONENT
runnable BPSRunnable which is activated cyclically with aperiod of 10ms Upon its activation it reads the sensorvalues from the ECU abstraction component and writes the
RR ndeg 8147
Contracts for System Design 55
position of the brake pedal on its provided SenderReceiverport The timing behavior of the component owning a time-triggered runnable can be characterized by the contract shownin Table XIII top
We now focus on the second situation in which the supplierwants to reuse components from a library to implementcontract C = CfIOBPS
and CtIOBPS We consider the case where
a component BrakePedalSensor has already been implementedand characterized by C = CfIBBPS
and CtIBBPSNow observe that
relation (62) holds However G 6sube G Taking a closer lookat Atw we see it assumes a worst case response time forBPSRunnable Thus the guarantee Gt can be strengthened ifweak assumption Atw is replaced by Aprimetw ensuring a shorterresponse time The supplier would then consider the con-tract Cprime = CfIBBPS
and CprimetIBBPS where the re-adjusted contract
CprimetIBBPScorresponds to assuming Aprimetw and guaranteeing Gprimet
For that modified contract relations (62ndash65) hold Howeverstrengthening an assumption is not a refinement Thereforeapplying this modification cannot be performed by the supplieron its own but rather requires negotiation with the OEM Ifthe OEM is willing to accept the stronger assumption Aprimetwthe component from the libary can be used and the modifiedcontract of the supplier is refined Cprime Cprimesupplier1
VFB The next process steps in the AUTOSAR methodology called
System configuration and ECU configuration define the targetarchitecture (ECUs and communication network) as well asthe deployment of the application software components onthat distributed architecture Thus satisfaction of the contractsspecified for the application needs to be verified for the givenarchitecture and deployment (cf IV-D4) We develop this inthe next two sub-sections
ECU configuration and vertical contracts During thefollowing discussion we assume that for each componentimplementation a contract similar to Cprime has been specifiedand possibly an associated Aprimetw has been negotiated Observethat Aprimetw may invalidate refinement of system requirements bythe VFB contract Consider the example above Aprimetw assumesan activation of BPSRunnable each 10ms and a worst caseresponse time less than 5ms This additional weak assumptionis now part of Cprimesupplier1
VFB However it is neither dischargedby any guarantee of CprimeVFB nor by the strong assumption ofCR1 Thus we need to verify that 1 all vertical assumptionscollected during previous steps are discharged during system-and ECU configuration and 2 all guarantees are met bysoftware components and connectors For both tasks state-of-the-art verification techniques can be used
As an example focus on the vertical assumption Aprimetw ofthe BrakePedalSensor-component and consider the ECU con-figuration depicted in Figure 19 The ECU hosts the twocomponents BrakePedalSensor and PedalToLamp of the VFBmodel57 These components are integrated with a layered basicsoftware stack on an ECU That stack consists of multipleBasicSoftwareModules (BSWM) Each of these modules has aset of standardized interfaces and is implemented by a set
57To simplify we omit port emcyBrake
RTE
BrakePedal
SensorPedalToLamp
BSW
COMOSt1 t2
Complex
Device
Driver
ext_pedal
pos_pedal_out
pos_pedal_in
lamp_intensity
isr
Figure 19 Extracting platform contracts from ECU configuration
of BswModuleEntities These are analogous to the Runnables ofapplication software components and are either executed by adedicated OS task or interrupt service routine Therefore weexpect BasicSoftwareModules to be characterized by contractsin a way similar to the internal behavior of applicationcomponents (cf contracts in Table XIII) In case a BSWM hasa BswModuleEntity that is not mapped to some task or interruptservice routine that entity is an ldquoordinaryrdquo function calledwithin the context of another BswModuleEntity or Runnable Inthe example ECU configuration two BSWMs are shown
bull A ComplexDeviceDriver which has direct access to thesensor of the ECU that detects position of the brake pedal
bull An AUTOSAR COM module and a CAN interface (notshown here)
The components and BSWMs own a single runnable eachbsw entity respectively The ECU configuration maps BP-SRunnable to task t1 of the operating system (OS) and PTL-Runnable to task t2 The BswModuleEntity of the ComplexDe-viceDriver is mapped to an interrupt service routine while theentity of the COM module is simply a function for sendinga signal That function is used by the AUTOSAR runtimeenvironment (RTE) to realize the communication specified onVFB-level by means of the connectors For each task of theOS the ECU configuration specifies at least its priority andwether it is preemptable The activation of a task is specifiedby linking an alarm of the OS to that task Those alarmscan also be configured to occur cyclically For each cyclicalarm we generate a contract PALARMi
with trivial strongand weak assumptions and as guarantee the cycle time ofthe alarm The example ECU configuration contains a singlealarm whose contract is listed in Table XIV top Furthermore
PALARM1
As trueAw trueG Alarmi occurs each 10ms
PBPSRunnable
As trueAw trueG delay between BPSRunnableact and
pos_pedal_out within [1ms4ms]
Table XIVPLATFORM CONTRACTS OBAINED BY ANALYSIS OF ECU CONFIGURATION
RR ndeg 8147
Contracts for System Design 56
we can extract from the AUTOSAR model of the componentimplementation a set of execution time specifications for eachRunnable owned by the component Again the same appliesto BswModuleEntities With this information we can create atask network and obtain response times for each Runnableand BswModuleEntity (if executed by some task or interruptservice routine) using tools like SymTAS58 or chronVAL59Afterwards we generate for each Runnable and BswModuleEntity(if executed by task or ISR) a contract PRunnablei
with stongand weak assumption T and as guarantee the reponse timeinterval determined by analysis For the ECU configurationsketched in Figure 19 BPSRunnable has a response time thatlies in the interval [1ms 4ms] resulting in the contract shownin Table XIV bottom Similar contracts are stated for all tasksand alarms extracted from the ECU configurations We thencompose these contracts and the contracts of the BSWMswhich yields the contract P characterizing the executionplatform Following the approach outlined in Section IV-D4we compose the VFB contract with the platform contract andcheck for refinement ie
CprimeVFB otimes P CprimeVFB (67)
The vertical assumption Aprimetw is discharged in the compositionof the VFB and platform contracts and refinement holdsFurthermore with Aprimetw being discharged refinement of thesystem requirement holds again
CprimeVFB otimes P CR1(68)
The approach outlined here to analyze the mapping of applica-tion software components and their associated contracts on anECU network by creating contracts from ECU configurationsand results of response time analysis has been implemented ina framework That framework includes a meta-model support-ing contract-based design and enables to 1 specify contractsfor components in foreign models and 2 check for refinementbetween contracts belonging to different models [24]
Inter-ECU communication During system configurationthe leaves of the hierarchical software composition calledAtomicSoftwareComponents are mapped to ECUs of the targetarchitecture Thus we know for each connector of the VFBmodel whether it must be implemented by the communicationnetwork interconnecting the ECUs
For both intra- and inter-ECU communication the designmust be verified against the corresponding contracts of theVFB model ie the set of contracts[
Cf and Ct] ∣∣ (Cf Ct) isin CSIGNAL
(69)
Again available analysis techniques can be used Suppose asignal from the VFB model is mapped to a frame transmittedon a CAN bus The OEM can then for each such contractuse the combination of strong and weak assumptions A =Afs and Atw as specification of the minimal inter-arrival timesof subsequent occurrences of the signal Taking into account
58httpwwwsymtavisioncomsymtashtml59httpwwwinchroncomchronvalhtml
the priority of each CAN frame given by its identifier theresponse time of each signal can be computed and comparedagainst the guarantee G = Gf andGt
If the communication network whose configuration is partof the AUTOSAR system configuration is successfully verifiedagainst the contracts defined in (69) deployment of the VFBmodel on the target architecture is correct with regard tothe VFB contract and the design fulfills the initial systemrequirement CR1
Discussion The above development highlights themethodological value of contracts for system design in AU-TOSAR context at later design stages First both contractconjunction and composition are used Then modificationsthat are not refinements are pinpointed which forces thesupplier to engage on a negotiation with the OEM regardingsystem specifications Without the solid support of contractsand its rules such kind of reasoning would be error prone
2) Safety The virtual function bus (VFB) concept wasintended to enable a distributed development of software com-ponents independently from the underlying hardware architec-ture The specification of the interfaces in the 3x releases didnot support the kind of non functional property necessary todevelop safety aspects of critical systems This fact lead to thedevelopment of the previously mentioned Timing Extensionand Safety Extension to Methodology and Templates Thesafety extension directly addresses the use of contracts forthe specification of safety relevant properties driven by theneed for compliance to the upcoming ISO26262 standardThe ISO26262 not only requires comprehensive checking ofrequirements but also states explicitly the need for usingassumptions on the environment to develop a safety relevantelement on the supplier side (ldquosafety element out of contextrdquo)In particular the standard distinguishes betweenbull A functional safety concept comprising the functional
safety requirements their allocation to architectural el-ements and their interaction necessary to achieve thesafety goals This is used to demonstrate that the risksrelated to an item of a vehicle are addressed by anadequate functional architecture
bull A technical safety concept used to demonstrate that thefunctional safety concept is addressed by an adequatetechnical solution
As a simple example for this approach we take the functionalarchitecture of Figure 20 showing the decomposition of theSafeBrakeIndication function into the ldquonormalrdquo BrakeIndicationfunction and the SignalingFailureDetection safety function in casethe BrakeIndication fails The corresponding safety goal requiresthat a loss of the braking indication function shall be detectedThis is formalized as contract CS0 shown in Table XV Thiscontract states that under a given failure hypothesis (ldquonodouble failurerdquo) either the brake lamp is activated or the driveris warned by the SignalingFailureDetection function This contractis attached to the function SafeBrakeIndication
For the subfunction BrakeIndication we show in Table XVIa contract CS1 stating the correct behavior in the absence
RR ndeg 8147
Contracts for System Design 57
CS0
As trueAw Only one of Fail(BrakeIndication)
and Fail(SignalFailureDetection) occursG Whenever BreakRequest occurs then
BreakIndication or SignalFailureDetection is performed
Table XVHORIZONTAL CONTRACT REPRESENTING FUNCTIONAL SAFETY
REQUIREMENT
ltltFunctiongtgt SafeBrakeIndication
ltltFunctiongtgt BrakeIndication
ltltSafetyFunctiongtgt SignalingFailureDetection
ltltFunctionalExchangegtgt BrakeRequest
ltltFunctionalExchangegtgt Detect(BrakeIndicationFail)
Figure 20 Functional architecture including safety function
of a failure of this function For the SignalingFailureDetection
CS1
As trueAw Absence of Fail(BrakeIndication)G Whenever BrakeRequest occurs then
BrakeIndication is performed
Table XVIHORIZONTAL CONTRACT FOR FUNCTION OF BRAKING LAMP
the associated contract states that a detected failure of thesub-function BrakeIndication is correctly indicated under theassumption that the provided function itself is not impacted bya failure see Table XVII An easy manual inspection shows
CS2
As trueAw Absence of fail(SignalingFailureDetection)G Whenever detect(fail(BrakeIndication))
SignalingFailureDetection is performed
Table XVIIHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
that the composition of CS1 otimes CS2 refines CS0 ie we haveformally validated the functional safety concept
The next step consists in allocating these functions tosoftware components on the VFB and developing a simpletechnical safety concept The corresponding technical architec-ture is shown in Figure 21 For the sake of simplicity we onlyconsider corrupted data while transmitting under failure modeThe affected communication links are marked in blue in Fig-ure 21 Thus fail(BrakeIndication) is mapped to fail(pos_pedal) andfail(lamp_intensity) In the same way fail(SignalingFailureDetection)is mapped to fail(mal_indication) This mapping is not furtherelaborated in this paper
For defining the technical safety concept so-called prop-agation contracts are used Propagation contracts expresshow failures (from the environment of the component) are
BrakePedal Sensor
PedalTo Lamp
BrakeLamp Actuator
MalfunctionIndication
lamp_intensity pos_pedal
ext_pedal mal_indication
ext_lamp
ext_indication
Figure 21 Extract of Indicator System
processed by the component According to the ISO 26262 (seeFigure 22) Faults Errors and Failures are distinguished by thepatterns used for the contracts
Figure 22 The role of Faults Errors and failures
For instance the contract CS4 of Table XVIII states that theerror state of the PedalToLamp component is caused by a failurein the communication
CS4
As trueAw trueG Mode PedalToLampError is caused by
fail(pos_pedal)
Table XVIIIHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
The nominal behavior is again given by the contract with anassumption about the absence of the communication failuresee Table XIX
Similarly the error state of the BreakLampActuator iscaused by a failure on the second communication link(fail(lamp_intensity)) or by a failure propagated from the PedalTo-Lamp component see Table XX The nominal behavior of the
RR ndeg 8147
Contracts for System Design 58
CS5
As trueAw Absence of fail(pos_pedal)G Whenever pos_pedal occurs then
lamp_intensity occurs
Table XIXEXEMPLARY CONTRACT FOR NOMINAL BEHAVIOR SPECIFICATION
BrakePedalSensor and the MalfunctionIndicator is formed similarlyto CS5
CS6
As trueAw trueG Mode BreakLampActuatorError is caused by
fail(lamp_intensity) or mode PedalToLampError
Table XXHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
The composition of contracts CS4 CS7
together with thenot stated simple nominal contracts entails the contract CS8
shown on Table XXI stating the functional safety requirement
CS8
As trueAw only one of faila failb failcG Whenever ext_pedal occurs then
ext_lamp or ext_indication occurs
Table XXICONTRACT STATING THE TECHNICAL SAFETY REQUIREMENT
Contract CS8is directly related to the functional safety goal
and includes the allocation to a technical safety concept Thisway a consistency between the functional and the technicalsafety concept has been established Furthermore thanks tothe formal pattern-based specification language the refinementrelations ensure that the concepts themselves are correct
To conclude let us mention other safety related use-caseswhich benefit from contract based specification such as theautomatic generation of fault-trees or FMEA tables as well asthe safe-state management
D Integrating Contracts in AUTOSAR
An important challenge is to smoothly integrate the use ofcontracts as part of AUTOSAR methodology We advocate amigration in two steps
TodaymdashOffering a Smooth Integration of Contract-BasedSystem Engineering with AUTOSAR The metamodel under-lying the CESAR reference technology platform has beencarefully designed to support a seamless design flow fromthe derivation of high-level requirements of new automotivefunctions to the level of detailed application design defined asthe entry point in the AUTOSAR design methodology The keyfor this smooth integration has been laid by AUTOSAR itselfby enforcing a clean separation between application develop-ment on the one side and deployment to distributed target
architectures on the other side Regarding layered design thejoint scope of CESAR and AUTOSAR ranges from systems-of-systems levels for Car2X applications to the introductionof new automotive functions and down to the detailed designlevel As illustrated in the previous section such phases wouldbuild on established design processes and currently used de-sign tools where contracts and viewpoints are conservativelyadded as additional flavor to existing design methodologiesFull hand-over to AUTOSAR takes place at the detailed designstage where component contracts get implemented using theAUTOSAR component model thus providing the entry pointfor the AUTOSAR design methodology
Following the AUTOSAR flow system configurations andECU configurations describe the detailed target hardware Wecan then automatically extract from system and ECU con-figurations all information for performing real-time analysisVertical assumptions on the component level can be derivedby back-annotation from the underlying target hardware Alter-natively vertical assumptions can be seen as constraining thetarget architecture (regarding its timing characteristics) and canthus be used to constrain the design space for possible targetarchitectures Finally when deploying components to ECUscommunications of the virtual functional bus are mapped to theinter-component communications on the physical architecture
The FuturemdashIntegrating Contracts in AUTOSAR The cur-rent AUTOSAR release is expressive enough to represent real-time contracts Using the concept of timing chains both end-to-end deadlines as well as assumed response times for compo-nent execution and communication can be expressed Howeverthe current release was not designed for extensibility thereis no established notion of viewpoints and hence no anchorto easily migrate from the current setting to one supportingmultiple viewpoints As pointed out before the decision asto which viewpoints should or should not be anchored is abusiness decision However given that ISO 26262 has becomebinding we see the need for a systematic integration of thesafety viewpoint
In fact a safety extension has already been proposed forinclusion in AUTOSAR It allows to use contracts for theencapsulation of Basic SoftWare (BSW) modules applicationsoftware components entities of the hardware architecture(like ECUs and buses) and the characterization of commu-nication services Such encapsulation would for instancedistinguish between BSW modules that (1) contribute to safety(safety mechanisms) and (2) those that could potentiallyimpact systemrsquos safety (by providing their failure propagationbehavior) A typical example for (1) would be the func-tion inhibition manager that maintains function inhibitionswhenever for instance implausible outputs are generated Atypical example for (2) would be an error that occurs inthe communication services or an error that is generated incommunication HW that impacts communication services
The objective of the extension is to provide an ISO 26262compliant traceability This allows for instance to deal withcompliance between functional safety (where functions haz-ards and safety functions are collected in the functional
RR ndeg 8147
Contracts for System Design 59
model) and technical safety of the AUTOSAR architectureinstance (guaranteeing that the AUTOSAR implementationmdashusing given safety functions of the AUTOSAR architecturemdashindeed implements the identified functional safety concept)
Since timing and safety viewpoints will be supported inAUTOSAR it is at least worthwhile to consider introducingthe concepts of viewpoints systematically Doing so will easetheir activation at times when other market factors such aspower-management mandate their introduction
E Summary and discussion
We have proposed a smooth path for integrating contractsin the context of AUTOSAR at the level of detailed designWe believe that the main aspects for consideration whileintroducing contracts are the handling of time budgets andthe specification of failure modes and failure propagation incombination with the functional aspect itself Vertical contractswere instrumental in handling time budgets Such contractsrelate two different layers of the AUTOSAR framework
XIII CONCLUSION
This paper presented past and recent results as well asnovel advances in the area of contracts and their theory Byencompassing (functional and non-functional) behaviors thenotion of contract we considered here represents a significantstep beyond the one originally developed in the softwareengineering community
A What contracts can do for the designer
This paper demonstrates that contracts offer a number ofadvantages
Contracts offer a technical support to legal customer-supplier documents Concurrent developmentmdashboth withinand across companiesmdashcalls for smooth coordination andintegration of the different design activities Properly definingand specifying the different concurrent design tasks is andremains a central difficulty Obligations must therefore beagreed upon together with suspensive conditions seen aslegal documents By clearly establishing responsibilities ourformalization of contracts constitutes the technical counterpartof such legal documents Contracts are an enabling technologyfor concurrent development
Contracts offer support to certification By providing for-mal arguments that can assess and guarantee the qualityof a design throughout all design phases (including earlyrequirements capture) contracts offer support for certificationBy providing sophisticated tools in support of modularityreuse in certification is made easier
Contracts comply with formal and semi-formal approachesThe need for being ldquocompletely formalrdquo has hampered for along time formal verification in many industrial sectors inwhich flexibility and intuitive expression in documentationsimulation and testing were and remain preferred As theAUTOSAR use case of Section XII demonstrated using con-tracts makes semi-formal design safer Small analysis stepsare within the reach of human reasoning A valid system
wide analysis for both component-based and refinement-baseddesigns is typically beyond the reach of human reasoningContract based design enables it
Contracts improve requirement engineering As illustratedin the Parking Garage example of Section XI contracts areinstrumental in decoupling top-level system architecture fromthe architecture used for sub-contracting to suppliers Formalsupport is critical in choosing alternative solutions and migrat-ing between different architectures with relatively small effortOf course contracts are not the only important technologyfor requirements engineeringmdashtraceability is essential anddeveloping domain specific ontologies is also important
Contracts can be used in any design process Contractsoffer a orthogonal support for all methodologies and can beused in any flow as a supporting technology in composing andrefining designs
B Status of research
The area of contracts benefits from many advances inresearch that were not targeted to it Interface theories weredeveloped by the community of game theorymdashcomponent andenvironment are seen as two players in a game Modalitiesaimed to offer more expressive logics were born at theboundary between logics and formal verification Contractsas a philosophy originated both from software engineeringand formal verification communities with the paradigms ofPre-conditionPost-condition or AssumeGuarantee It is notuntil the 2000rsquos that the concept of contracts presented hereas a tool to support system design emerged In this evolutionvarious formalisms and theories were borrowed to developa rigorous framework This paper was intended to show thepower of a unified theoretical background for contracts the useof contracts in present methodologies and the challenges for itseffective applications in future applications The mathematicalelegance of the concepts underpinning this area providesconfidence in a sustained continuation of the research effort
C Status of practice
The use of contract-based techniques in system design isin its infancy in industry Further maturation is needed forits paradigm and concepts to become on one side clearand simple to be widely accepted by engineers in their day-to-day work and on the other side developed enough toallow for the development of tools for automatic verificationand synthesis While powerful contract-based proof-of-concepttools are being experimentedmdashsome of them were presentedin this papermdashthe robustness of the tools and the underlyingtechniques is still weak and contract-based design flows andmethodologies are not yet fully developed nor mature
D The way forward
The ability of contracts to accommodate semi-formal andformal methodologies should enable a smooth and rapid mi-gration from theory and proof-of-concepts to robust flows andmethodologies The need for jointly developing new systemswhile considering issues of intellectual property will make
RR ndeg 8147
Contracts for System Design 60
it attractive to rely on contracts in supplier chains In ouropinion contracts are primarily helpful for early stages ofsystem design and particularly requirement engineering whereformal methods are desperately needed to support distributedand concurrent development by independent actors
We have illustrated in this paper how suppliers can be givensub-contracts that are correct by construction and can be auto-matically generated from top-level specification We believehowever that the semi-assistedsemi-manual use of contractssuch as exemplified by our AUTOSAR case study is alreadya significant help useful for requirements engineering tooAltogether a contract engine (such as the MICA tool presentedin Section XI) can be used in combination with both manualreasoning and dedicated formal verification engines (eg fortargeting the timing viewpoint or the safety viewpoint) as thebasis for future development that will make contracts mainstream
REFERENCES
[1] Martiacuten Abadi and Leslie Lamport Conjoining specifications ACMTrans Program Lang Syst 17(3)507ndash534 1995
[2] Yael Abarbanel Ilan Beer Leonid Gluhovsky Sharon Keidar andYaron Wolfsthal FoCs - Automatic Generation of Simulation Checkersfrom Formal Specifications In E Emerson and A Sistla editors Com-puter Aided Verification volume 1855 of Lecture Notes in ComputerScience pages 538ndash542 Springer Berlin Heidelberg 2000
[3] B Thomas Adler Luca de Alfaro Leandro Dias da Silva MarcoFaella Axel Legay Vishwanath Raman and Pritam Roy Ticc A Toolfor Interface Compatibility and Composition In Proc of the 18thInternational Conference on Computer Aided Verification (CAVrsquo06)volume 4144 of Lecture Notes in Computer Science pages 59ndash62Springer 2006
[4] Albert Benveniste and Benoicirct Caillaud and Jean-Baptiste RacletApplication of Interface Theories to the Separate Compilation ofSynchronous Programs In IEEE Conf on Decision and Control dec2012
[5] Luca De Alfaro and Thomas A Henzinger Interface-based design InIn Engineering Theories of Software Intensive Systems proceedings ofthe Marktoberdorf Summer School Kluwer 2004
[6] Rajeev Alur and David L Dill A theory of timed automata TheoreticalComputer Science 126(2)183ndash235 1994
[7] Rajeev Alur Limor Fix and Thomas A Henzinger A determinizableclass of timed automata In David L Dill editor CAV volume 818 ofLecture Notes in Computer Science pages 1ndash13 Springer 1994
[8] Rajeev Alur Limor Fix and Thomas A Henzinger Event-clockautomata A determinizable class of timed automata Theor ComputSci 211(1-2)253ndash273 1999
[9] Rajeev Alur Thomas A Henzinger and Orna Kupferman Alternating-time temporal logic J ACM 49(5)672ndash713 2002
[10] Rajeev Alur Thomas A Henzinger Orna Kupferman and Moshe YVardi Alternating refinement relations In Proc of the 9th InternationalConference on Concurrency Theory (CONCURrsquo98) volume 1466 ofLecture Notes in Computer Science pages 163ndash178 Springer 1998
[11] Adam Antonik Michael Huth Kim G Larsen Ulrik Nyman andAndrzej Wasowski 20 Years of Modal and Mixed SpecificationsBulletin of European Association of Theoretical Computer Science1(94) 2008
[12] Adam Antonik Michael Huth Kim Guldstrand Larsen Ulrik Nymanand Andrzej Wasowski Complexity of Decision Problems for Mixedand Modal Specifications In FoSSaCS pages 112ndash126 2008
[13] Road vehicles ndash functional safety Standard ISO 26262[14] Christel Baier and Joost-Pieter Katoen Principles of Model Checking
MIT Press Cambridge 2008[15] Felice Balarin Jerry R Burch Luciano Lavagno Yosinori Watanabe
Roberto Passerone and Alberto L Sangiovanni-Vincentelli Con-straints specification at higher levels of abstraction In Proceedingsof the Sixth IEEE International High-Level Design Validation and Test
Workshop (HLDVT01) pages 129ndash133 Monterey CA November 7ndash92001 IEEE Computer Society Los Alamitos CA USA
[16] Felice Balarin Abhijit Davare Massimiliano DrsquoAngelo Douglas Dens-more Trevor Meyerowitz Roberto Passerone Alessandro Pinto Al-berto Sangiovanni-Vincentelli Alena Simalatsar Yoshinori WatanabeGuang Yang and Qi Zhu Platform-based design and frameworksMETROPOLIS and METRO II In Gabriela Nicolescu and Pieter JMosterman editors Model-Based Design for Embedded Systems chap-ter 10 page 259 CRC Press Taylor and Francis Group Boca RatonLondon New York November 2009
[17] Felice Balarin and Roberto Passerone Functional verification method-ology based on formal interface specification and transactor generationIn Proceedings of the Conference on Design Automation and Test inEurope (DATE06) pages 1013ndash1018 Munich Germany March 6ndash102006 European Design and Automation Association 3001 LeuvenBelgium
[18] Felice Balarin and Roberto Passerone Specification synthesis andsimulation of transactor processes IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 26(10)1749ndash1762October 2007
[19] Felice Balarin Roberto Passerone Alessandro Pinto and Alberto LSangiovanni-Vincentelli A formal approach to system level designMetamodels and unified design environments In Proceedings of theThird ACM and IEEE International Conference on Formal Methodsand Models for Co-Design (MEMOCODE05) pages 155ndash163 VeronaItaly July 11ndash14 2005 IEEE Computer Society Los Alamitos CAUSA
[20] Felice Balarin Yosinori Watanabe Harry Hsieh Luciano LavagnoClaudio Passerone and Alberto L Sangiovanni-Vincentelli Metropo-lis An Integrated Electronic System Design Environment IEEEComputer 36(4)45ndash52 2003
[21] Krishnakumar Balasubramanian Aniruddha Gokhale Gabor KarsaiJanos Sztipanovits and Sandeep Neema Developing applicationsusing model-driven design environments IEEE Computer 39(2)33ndash40 2006
[22] Sebastian S Bauer Alexandre David Rolf Hennicker Kim GuldstrandLarsen Axel Legay Ulrik Nyman and Andrzej Wasowski Movingfrom specifications to contracts in component-based design In Juande Lara and Andrea Zisman editors FASE volume 7212 of LectureNotes in Computer Science pages 43ndash58 Springer 2012
[23] Sebastian S Bauer Philip Mayer Andreas Schroeder and Rolf Hen-nicker On Weak Modal Compatibility Refinement and the MIOWorkbench In Proc of 16th International Conference on Tools andAlgorithms for the Construction and Analysis of Systems (TACASrsquo10)volume 6015 of Lecture Notes in Computer Science pages 175ndash189Springer 2010
[24] Andreas Baumgart Eckard Boumlde Matthias Buumlker Werner Damm Guumln-ter Ehmen Tayfun Gezgin Stefan Henkler Hardi Hungar BernhardJosko Markus Oertel Thomas Peikenkamp Philipp Reinkemeier IngoStierand and Raphael Weber Architecture Modeling Technical reportOFFIS March 2011
[25] Nikola Benes Jan Kretiacutenskyacute Kim Guldstrand Larsen and Jiriacute SrbaChecking Thorough Refinement on Modal Transition Systems IsEXPTIME-Complete In Martin Leucker and Carroll Morgan editorsICTAC volume 5684 of Lecture Notes in Computer Science pages112ndash126 Springer 2009
[26] Nikola Benes Jan Kretiacutenskyacute Kim Guldstrand Larsen and Jiriacute SrbaOn determinism in modal transition systems Theoretical ComputerScience 410(41)4026ndash4043 2009
[27] Benoicirct Caillaud and Jean-Baptiste Raclet Ensuring Reachability byDesign In Int Colloquium on Theoretical Aspects of Computing sept2012
[28] Albert Benveniste and Geacuterard Berry The synchronous approach toreactive and real-time systems Proceedings of the IEEE 79(9)1270ndash1282 1991
[29] Albert Benveniste Benoicirct Caillaud Alberto Ferrari LeonardoMangeruca Roberto Passerone and Christos Sofronis Multiple view-point contract-based specification and design In Proceedings of theSoftware Technology Concertation on Formal Methods for Componentsand Objects FMCOrsquo07 volume 5382 of Lecture Notes in ComputerScience pages 200ndash225 Springer October 2008
[30] Albert Benveniste Paul Caspi Stephen A Edwards Nicolas Halb-wachs Paul Le Guernic and Robert de Simone The SynchronousLanguages 12 years later Proceedings of the IEEE 91(1)64ndash83 2003
RR ndeg 8147
Contracts for System Design 61
[31] Luca Benvenuti Alberto Ferrari Leonardo Mangeruca EmanueleMazzi Roberto Passerone and Christos Sofronis A contract-basedformalism for the specification of heterogeneous systems In Proceed-ings of the Forum on Specification Verification and Design Languages(FDL08) pages 142ndash147 Stuttgart Germany September 23ndash25 2008
[32] Gerard Berry The effectiveness of synchronous languages for thedevelopment of safety-critical systems White paper Esterel Technolo-gies 2003
[33] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet A compositional approach on modal specifications for timedsystems In Proc of the 11th International Conference on FormalEngineering Methods (ICFEMrsquo09) volume 5885 of Lecture Notes inComputer Science pages 679ndash697 Springer 2009
[34] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet Modal event-clock specifications for timed component-baseddesign Science of Computer Programming 2011 To appear
[35] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet Modal event-clock specifications for timed component-baseddesign Science of Computer Programming 2012 to appear
[36] Nathalie Bertrand Sophie Pinchinat and Jean-Baptiste Raclet Refine-ment and consistency of timed modal specifications In Proc of the3rd International Conference on Language and Automata Theory andApplications (LATArsquo09) volume 5457 of Lecture Notes in ComputerScience pages 152ndash163 Springer 2009
[37] Antoine Beugnard Jean-Marc Jeacutezeacutequel and Noeumll Plouzeau Makingcomponents contract aware IEEE Computer 32(7)38ndash45 1999
[38] Dirk Beyer Arindam Chakrabarti and Thomas A Henzinger Webservice interfaces In Allan Ellis and Tatsuya Hagino editors WWWpages 148ndash159 ACM 2005
[39] Purandar Bhaduri and S Ramesh Interface synthesis and protocolconversion Formal Aspects of Computing 20(2)205ndash224 2008
[40] Purandar Bhaduri and Ingo Stierand A proposal for real-time interfacesin speeds In Design Automation and Test in Europe (DATErsquo10) pages441ndash446 IEEE 2010
[41] Simon Bliudze and Joseph Sifakis The Algebra of Connectors -Structuring Interaction in BIP IEEE Trans Computers 57(10)1315ndash1330 2008
[42] R Bloem and B Jobstmann Manual for property-based synthesis toolTechnical Report Prosyd D223 2006
[43] Roderick Bloem Alessandro Cimatti Karin Greimel Georg HofferekRobert Koumlnighofer Marco Roveri Viktor Schuppan and RichardSeeber RATSY - A New Requirements Analysis Tool with SynthesisIn Tayssir Touili Byron Cook and Paul Jackson editors CAV volume6174 of Lecture Notes in Computer Science pages 425ndash429 Springer2010
[44] Grady Booch James Rumbaugh and Ivar Jacobson Unified ModelingLanguage User Guide The (2nd Edition) (Addison-Wesley ObjectTechnology Series) Addison-Wesley Professional 2005
[45] Amar Bouali XEVE an Esterel Verification Environment In Alan JHu and Moshe Y Vardi editors CAV volume 1427 of Lecture Notesin Computer Science pages 500ndash504 Springer 1998
[46] Geacuterard Boudol and Kim Guldstrand Larsen Graphical versus logicalspecifications Theor Comput Sci 106(1)3ndash20 1992
[47] Jerry R Burch Trace Algebra for Automatic Verification of Real-Time Concurrent Systems PhD thesis School of Computer ScienceCarnegie Mellon University August 1992
[48] Jerry R Burch Roberto Passerone and Alberto L Sangiovanni-Vincentelli Overcoming heterophobia Modeling concurrency in het-erogeneous systems In Proceedings of the 2nd International Confer-ence on Application of Concurrency to System Design (ACSD01) pages13ndash32 Newcastle upon Tyne UK June 25ndash29 2001 IEEE ComputerSociety Los Alamitos CA USA
[49] Benoicirct Caillaud Mica A Modal Interface Compositional AnalysisLibrary October 2011 httpwwwirisafrs4toolsmica
[50] Benoicirct Caillaud Benoicirct Delahaye Kim G Larsen Axel LegayMikkel Larsen Pedersen and Andrzej Wasowski Compositional designmethodology with constraint Markov chains In Proceedings of the7th International Conference on Quantitative Evaluation of SysTems(QEST) 2010 IEEE Computer Society 2010
[51] Daniela Cancila Roberto Passerone Tullio Vardanega and MarcoPanunzio Toward correctness in the specification and handling ofnon-functional attributes of high-integrity real-time embedded systemsIEEE Transactions on Industrial Informatics 6(2)181ndash194 May 2010
[52] Karlis Cerans Jens Chr Godskesen and Kim Guldstrand LarsenTimed Modal Specification - Theory and Tools In Costas Courcou-betis editor CAV volume 697 of Lecture Notes in Computer Sciencepages 253ndash267 Springer 1993
[53] Pavol Cernyacute Martin Chmelik Thomas A Henzinger and ArjunRadhakrishna Interface simulation distances In Marco Faella andAniello Murano editors GandALF volume 96 of EPTCS pages 29ndash42 2012
[54] Arindam Chakrabarti A Framework for Compositional Design andAnalysis of Systems PhD thesis EECS Department University ofCalifornia Berkeley Dec 2007
[55] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger MarcinJurdzinski and Freddy Y C Mang Interface compatibility checkingfor software modules In Ed Brinksma and Kim Guldstrand Larseneditors CAV volume 2404 of Lecture Notes in Computer Sciencepages 428ndash441 Springer 2002
[56] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger andFreddy Y C Mang Synchronous and Bidirectional Component Inter-faces In Proc of the 14th International Conference on Computer AidedVerification (CAVrsquo02) volume 2404 of Lecture Notes in ComputerScience pages 414ndash427 Springer 2002
[57] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger andMarieumllle Stoelinga Resource Interfaces In Rajeev Alur and InsupLee editors EMSOFT volume 2855 of Lecture Notes in ComputerScience pages 117ndash133 Springer 2003
[58] Edward Y Chang Zohar Manna and Amir Pnueli Characterizationof temporal property classes In Werner Kuich editor ICALP volume623 of Lecture Notes in Computer Science pages 474ndash486 Springer1992
[59] Taolue Chen Chris Chilton Bengt Jonsson and Marta ZKwiatkowska A compositional specification theory for componentbehaviours In Helmut Seidl editor ESOP volume 7211 of LectureNotes in Computer Science pages 148ndash168 Springer 2012
[60] Chris Chilton Marta Z Kwiatkowska and Xu Wang Revisiting timedspecification theories A linear-time perspective In Marcin Jurdzinskiand Dejan Nickovic editors FORMATS volume 7595 of Lecture Notesin Computer Science pages 75ndash90 Springer 2012
[61] E Clarke O Grumberg and D Peled Model Checking MIT Press1999
[62] Edmund M Clarke David E Long and Kenneth L McMillanCompositional model checking In LICS pages 353ndash362 1989
[63] W Damm E Thaden I Stierand T Peikenkamp and H HungarUsing Contract-Based Component Specifications for Virtual Integra-tion and Architecture Design In Proceedings of the 2011 DesignAutomation and Test in Europe (DATErsquo11) March 2011 To appear
[64] Werner Damm and David Harel LSCs Breathing life into messagesequence charts Formal Methods in System Design 19(1)45ndash80 2001
[65] Werner Damm Angelika Votintseva Alexander Metzner BernhardJosko Thomas Peikenkamp and Eckard Boumlde Boosting reuse ofembedded automotive applications through rich components In Pro-ceedings of FIT 2005 - Foundations of Interface Technologies 2005
[66] Werner Damm and Bernd Westphal Live and let die LSC basedverification of UML models Sci Comput Program 55(1-3)117ndash1592005
[67] Abhijit Davare Douglas Densmore Trevor Meyerowitz AlessandroPinto Alberto Sangiovanni-Vincentelli Guang Yang and Qi Zhu Anext-generation design framework for platform-based design In DesignVerification Conference (DVCon) San Josersquo California 2007
[68] Alexandre David Kim G Larsen Axel Legay Ulrik Nyman andAndrzej Wasowski Timed IO automata A complete specificationtheory for real-time systems In Proc of the 13th ACM InternationalConference on Hybrid Systems Computation and Control (HSCCrsquo10)pages 91ndash100 ACM 2010
[69] Alexandre David Kim Guldstrand Larsen Axel Legay Ulrik Nymanand Andrzej Wasowski ECDAR An Environment for CompositionalDesign and Analysis of Real Time Systems In Proc of the 8thInternational Symposium on Automated Technology for Verificationand Analysis (ATVArsquo10) volume 6252 of Lecture Notes in ComputerScience pages 365ndash370 2010
[70] Luca de Alfaro Game Models for Open Systems In VerificationTheory and Practice volume 2772 of Lecture Notes in ComputerScience pages 269ndash289 Springer 2003
[71] Luca de Alfaro Leandro Dias da Silva Marco Faella Axel LegayPritam Roy and Maria Sorea Sociable Interfaces In Proc of
RR ndeg 8147
Contracts for System Design 62
the 5th International Workshop on Frontiers of Combining Systems(FroCosrsquo05) volume 3717 of Lecture Notes in Computer Sciencepages 81ndash105 Springer 2005
[72] Luca de Alfaro and Thomas A Henzinger Interface automata In Procof the 9th ACM SIGSOFT International Symposium on Foundations ofSoftware Engineering (FSErsquo01) pages 109ndash120 ACM Press 2001
[73] Luca de Alfaro and Thomas A Henzinger Interface theories forcomponent-based design In Thomas A Henzinger and Christoph MKirsch editors EMSOFT volume 2211 of Lecture Notes in ComputerScience pages 148ndash165 Springer 2001
[74] Luca de Alfaro Thomas A Henzinger and Marieumllle Stoelinga TimedInterfaces In Proc of the 2nd International Workshop on EmbeddedSoftware (EMSOFTrsquo02) volume 2491 of Lecture Notes in ComputerScience pages 108ndash122 Springer 2002
[75] Benoicirct Delahaye Modular Specification and Compositional Analysisof Stochastic Systems PhD thesis Universiteacute de Rennes 1 2010
[76] Benoicirct Delahaye Benoicirct Caillaud and Axel Legay ProbabilisticContracts A Compositional Reasoning Methodology for the Designof Stochastic Systems In Proc 10th International Conference onApplication of Concurrency to System Design (ACSD) Braga PortugalIEEE 2010
[77] Benoicirct Delahaye Benoicirct Caillaud and Axel Legay Probabilisticcontracts A compositional reasoning methodology for the designof systems with stochastic andor non-deterministic aspects FormalMethods in System Design 2011 To appear
[78] Benoicirct Delahaye Uli Fahrenberg Thomas A Henzinger Axel Legayand Dejan Nickovic Synchronous interface theories and time trig-gered scheduling In Holger Giese and Grigore Rosu editorsFMOODSFORTE volume 7273 of Lecture Notes in Computer Sci-ence pages 203ndash218 Springer 2012
[79] Benoicirct Delahaye Joost-Pieter Katoen Kim G Larsen Axel LegayMikkel L Pedersen Falak Sher and Andrzej Wasowski AbstractProbabilistic Automata In Ranjit Jhala and David A Schmidt editorsVMCAI volume 6538 of Lecture Notes in Computer Science pages324ndash339 Springer 2011
[80] Douglas Densmore Sanjay Rekhi and Alberto L Sangiovanni-Vincentelli Microarchitecture Development via Metropolis SuccessivePlatform Refinement In DATE pages 346ndash351 IEEE ComputerSociety 2004
[81] David L Dill Trace Theory for Automatic Hierarchical Verificationof Speed-Independent Circuits ACM Distinguished Dissertations MITPress 1989
[82] Nicolaacutes DrsquoIppolito Dario Fischbein Marsha Chechik and SebastiaacutenUchitel MTSA The Modal Transition System Analyser In Proc ofthe 23rd IEEEACM International Conference on Automated SoftwareEngineering (ASErsquo08) pages 475ndash476 IEEE 2008
[83] Laurent Doyen Thomas A Henzinger Barbara Jobstmann and TatjanaPetrov Interface theories with component reuse In Proceedings of the8th ACM amp IEEE International conference on Embedded softwareEMSOFTrsquo08 pages 79ndash88 2008
[84] Dumitru Potop-Butucaru and Stephen Edwards and Geacuterard BerryCompiling Esterel Springer V 2007 ISBN 0387706267
[85] Cindy Eisner PSL for Runtime Verification Theory and Practice InOleg Sokolsky and Serdar Tasiran editors RV volume 4839 of LectureNotes in Computer Science pages 1ndash8 Springer 2007
[86] Cindy Eisner Dana Fisman John Havlicek Michael JC GordonAnthony McIsaac and David Van Campenhout Formal Syntax andSemantics of PSL - Appendix B of Accellera LRM January 2003Technical report IBM 2003
[87] Cindy Eisner Dana Fisman John Havlicek Yoad Lustig AnthonyMcIsaac and David Van Campenhout Reasoning with temporal logicon truncated paths In Warren A Hunt Jr and Fabio Somenzi editorsCAV volume 2725 of Lecture Notes in Computer Science pages 27ndash39Springer 2003
[88] Johan Eker Joumlrn W Janneck Edward A Lee Jie Liu Xiaojun LiuJ Ludvig Stephen Neuendorffer S Sachs and Yuhong Xiong Tamingheterogeneity - the ptolemy approach Proc of the IEEE 91(1)127ndash144 2003
[89] G Feuillade Modal specifications are a syntactic fragment of the Mu-calculus Research Report RR-5612 INRIA June 2005
[90] Dario Fischbein and Sebastiaacuten Uchitel On correct and completestrong merging of partial behaviour models In Proc of the 16thACM SIGSOFT International Symposium on Foundations of SoftwareEngineering (SIGSOFT FSErsquo08) pages 297ndash307 ACM 2008
[91] F Fleurey P A Muller and J M Jzquel Weaving executabilityinto object-oriented meta-languages In Proceedgins of the 8th In-ternational Conference on Model Driven Engineering Languages andSystems (MODELS05) October 2005
[92] Freacutedeacuteric Boussinot and Robert de Simone The Esterel languageProceedings of the IEEE 79(9)1293ndash1304 1991
[93] Peter Fritzson Principles of Object-Oriented Modeling and Simulationwith Modelica 21 Wiley 2003
[94] Tayfun Gezgin Raphael Weber and Maurice Girod A RefinementChecking Technique for Contract-Based Architecture Designs InFourth International Workshop on Model Based Architecting andConstruction of Embedded Systems ACES-MBrsquo11 volume 7167 ofLecture Notes in Computer Science Springer October 2011
[95] Jens Chr Godskesen Kim Guldstrand Larsen and Arne Skou Auto-matic verification of real-time systems using Epsilon In Son T Vuongand Samuel T Chanson editors PSTV volume 1 of IFIP ConferenceProceedings pages 323ndash330 Chapman amp Hall 1994
[96] G Goumlssler and J-B Raclet Modal Contracts for Component-basedDesign In Proc of the 7th IEEE International Conference on SoftwareEngineering and Formal Methods (SEFMrsquo09) IEEE Computer SocietyPress November 2009
[97] Susanne Graf and Sophie Quinton Contracts for BIP HierarchicalInteraction Models for Compositional Verification In John Derrick andJuumlri Vain editors FORTE volume 4574 of Lecture Notes in ComputerScience pages 1ndash18 Springer 2007
[98] Orna Grumberg and David E Long Model checking and modularverification ACM Trans Program Lang Syst 16(3)843ndash871 1994
[99] Imene Ben Hafaiedh Susanne Graf and Sophie Quinton Reasoningabout Safety and Progress Using Contracts In Proc of ICFEMrsquo10volume 6447 of LNCS pages 436ndash451 Springer 2010
[100] Nicolas Halbwachs Synchronous programming of reactive systemsKluwer Academic Pub 1993
[101] Nicolas Halbwachs Fabienne Lagnier and Christophe Ratel Program-ming and Verifying Real-Time Systems by Means of the SynchronousData-Flow Language Lustre IEEE Trans Software Eng 18(9)785ndash793 1992
[102] Nicolas Halbwachs Fabienne Lagnier and Pascal Raymond Syn-chronous observers and the verification of reactive systems In MauriceNivat Charles Rattray Teodor Rus and Giuseppe Scollo editorsAMAST Workshops in Computing pages 83ndash96 Springer 1993
[103] Nicolas Halbwachs and Pascal Raymond Validation of synchronousreactive systems From formal verification to automatic testing In P SThiagarajan and Roland H C Yap editors ASIAN volume 1742 ofLecture Notes in Computer Science pages 1ndash12 Springer 1999
[104] David Harel Statecharts A visual formalism for complex systemsSci Comput Program 8(3)231ndash274 1987
[105] David Harel Hillel Kugler Shahar Maoz and Itai Segall Acceleratingsmart play-out In Jan van Leeuwen Anca Muscholl David PelegJaroslav Pokornyacute and Bernhard Rumpe editors SOFSEM volume5901 of Lecture Notes in Computer Science pages 477ndash488 Springer2010
[106] David Harel Robby Lampert Assaf Marron and Gera Weiss Model-checking behavioral programs In Samarjit Chakraborty Ahmed Jer-raya Sanjoy K Baruah and Sebastian Fischmeister editors EMSOFTpages 279ndash288 ACM 2011
[107] David Harel and Rami Marelly Come Letrsquos Play Scenario-BasedProgramming Using LSCs and the Play-Engine Springer-Verlag 2003httpwwwwisdomweizmannacil~harelComeLetsPlaypdf
[108] David Harel Assaf Marron and Gera Weiss Behavioral programmingCommun ACM 55(7)90ndash100 2012
[109] David Harel Assaf Marron Guy Wiener and Gera Weiss Behavioralprogramming decentralized control and multiple time scales InCristina Videira Lopes editor SPLASH Workshops pages 171ndash182ACM 2011
[110] David Harel and Amir Pnueli On the development of reactive systemsIn K R Apt editor Logic and Models for Verification and Specificationof Concurrent Systems volume F13 of NATO ASI Series pages 477ndash498 Springer-Verlag 1985
[111] H Heinecke W Damm B Josko A Metzner H KopetzA Sangiovanni-Vincentelli and M Di Natale Software Componentsfor Reliable Automotive Systems In Design Automation and Test inEurope 2008 DATE rsquo08 pages 549ndash554 march 2008
[112] Thomas A Henzinger and Dejan Nickovic Independent imple-mentability of viewpoints In Radu Calinescu and David Garlan edi-
RR ndeg 8147
Contracts for System Design 63
tors Monterey Workshop volume 7539 of Lecture Notes in ComputerScience pages 380ndash395 Springer 2012
[113] C A R Hoare An axiomatic basis for computer programmingCommun ACM 12(10)576ndash580 1969
[114] INCOSE Incose systems engineering handbook 2010 httpwwwincoseorgProductsPubsproductssehandbookaspx
[115] Cliff B Jones Specification and design of (parallel) programs In IFIPCongress pages 321ndash332 1983
[116] B Jonsson and K G Larsen Specification and refinement ofprobabilistic processes In Logic in Computer Science (LICS) pages266ndash277 IEEE Computer 1991
[117] Gilles Kahn The Semantics of Simple Language for Parallel Program-ming In IFIP Congress pages 471ndash475 1974
[118] S Karris Introduction to Simulink with Engineering ApplicationsOrchard Publications 2006
[119] G Karsai J Sztipanovits A Ledeczi and T Bapty Model-integrated development of embedded software Proceedings of theIEEE 91(1)145ndash164 January 2003
[120] Gabor Karsai Janos Sztipanovitz Akos Ledczi and Ted Bapty Model-integrated development of embedded software Proceedings of theIEEE 91(1) January 2003
[121] Orna Kupferman and Moshe Y Vardi Modular model checking InWillem P de Roever Hans Langmaack and Amir Pnueli editorsCOMPOS volume 1536 of Lecture Notes in Computer Science pages381ndash401 Springer 1997
[122] Leslie Lamport Proving the correctness of multiprocess programsIEEE Trans Software Eng 3(2)125ndash143 1977
[123] C Larman and VR Basili Iterative and incremental developments abrief history Computer 36(6)47ndash56 June 2003
[124] Kim G Larsen and L Xinxin Equation solving using modal transitionsystems In Proceedings of the 5th Annual IEEE Symp on Logic inComputer Science LICSrsquo90 pages 108ndash117 IEEE Computer SocietyPress 1990
[125] Kim Guldstrand Larsen Modal specifications In Automatic Verifica-tion Methods for Finite State Systems volume 407 of Lecture Notes inComputer Science pages 232ndash246 Springer 1989
[126] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski In-terface InputOutput Automata In Jayadev Misra Tobias Nipkowand Emil Sekerinski editors FM volume 4085 of Lecture Notes inComputer Science pages 82ndash97 Springer 2006
[127] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski ModalIO Automata for Interface and Product Line Theories In ProgrammingLanguages and Systems 16th European Symposium on ProgrammingESOPrsquo07 volume 4421 of Lecture Notes in Computer Science pages64ndash79 Springer 2007
[128] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski OnModal Refinement and Consistency In Proc of the 18th InternationalConference on Concurrency Theory (CONCURrsquo07) pages 105ndash119Springer 2007
[129] Kim Guldstrand Larsen Bernhard Steffen and Carsten Weise A con-straint oriented proof methodology based on modal transition systemsIn Proc of the 1st International Workshop on Tools and Algorithmsfor Construction and Analysis of Systems (TACASrsquo95) volume 1019of Lecture Notes in Computer Science pages 17ndash40 Springer 1995
[130] Kim Guldstrand Larsen and Bent Thomsen A Modal Process LogicIn Proceedings of the Third Annual Symposium on Logic in ComputerScience (LICSrsquo88) pages 203ndash210 IEEE 1988
[131] A Ledeczi A Bakay M Maroti P Volgyesi G Nordstrom J Sprin-kle and G Karsai Composing domain-specific design environmentsIEEE Computer 34(11)44 ndash51 November 2001
[132] Akos Ledeczi Miklos Maroti Arpad Bakay Gabor Karsai JasonGarrett Charles Thomason Greg Nordstrom Jonathan Sprinkle andPeter Volgyesi The generic modeling environment In Proceedingsof the IEEE International Workshop on Intelligent Signal Processing(WISP2001) Budapest Hungary May 24ndash25 2001
[133] Edward A Lee Cyber physical systems Design challenges TechnicalReport UCBEECS-2008-8 EECS Department University of Califor-nia Berkeley Jan 2008
[134] Nancy A Lynch Inputoutput automata Basic timed hybrid proba-bilistic dynamic In Roberto M Amadio and Denis Lugiez editorsCONCUR volume 2761 of Lecture Notes in Computer Science pages187ndash188 Springer 2003
[135] Nancy A Lynch and Eugene W Stark A proof of the kahn principlefor inputoutput automata Inf Comput 82(1)81ndash92 1989
[136] Zohar Manna and Amir Pnueli Temporal verification of reactivesystems Safety Springer 1995
[137] Herveacute Marchand Patricia Bournai Michel Le Borgne and Paul LeGuernic Synthesis of Discrete-Event Controllers Based on the SignalEnvironment Discrete Event Dynamic Systems 10(4)325ndash346 2000
[138] Herveacute Marchand and Mazen Samaan Incremental Design of aPower Transformer Station Controller Using a Controller SynthesisMethodology IEEE Trans Software Eng 26(8)729ndash741 2000
[139] B Meyer Applying ldquodesign by contractrdquo IEEE Computer 25(10)40ndash51 October 1992
[140] Bertrand Meyer Touch of Class Learning to Program Well UsingObject Technology and Design by Contract Springer SoftwareEngineering 2009
[141] MW Maier Architecting Principles for Systems of Systems SystemsEngineering 1(4)267ndash284 1998
[142] Walid A Najjar Edward A Lee and Guang R Gao Advances in thedataflow computational model Parallel Computing 25(13-14)1907ndash1929 1999
[143] Radu Negulescu Process Spaces and the Formal Verification ofAsynchronous Circuits PhD thesis University of Waterloo Canada1998
[144] Nicolas Halbwachs and Paul Caspi and Pascal Raymond and DanielPilaud The synchronous data flow programming language LustreProceedings of the IEEE 79(9)1305ndash1320 1991
[145] P Nuzzo A Sangiovanni-Vincentelli X Sun and A PuggelliMethodology for the design of analog integrated interfaces usingcontracts IEEE Sensors Journal 12(12)3329ndash3345 Dec 2012
[146] Object Management Group (OMG) Model driven architecture (MDA)FAQ [online] httpwwwomgorgmda
[147] Object Management Group (OMG) Unified Modeling Language(UML) specification [online] httpwwwomgorgspecUML
[148] Object Management Group (OMG) A UML profile for MARTE beta1 OMG Adopted Specification ptc07-08-04 OMG August 2007
[149] Object Management Group (OMG) System modeling languagespecification v11 Technical report OMG 2008
[150] Object constraint language version 20 OMG Available Specificationformal06-05-01 Object Management Group May 2006
[151] The Design Automation Standards Committee of the IEEE Com-puter Society editor 1850-2010 - IEEE Standard for PropertySpecification Language (PSL) IEEE Computer Society 2010
[152] J Hudak P Feiler D Gluch The Architecture Analysis and DesignLanguage (AADL) An Introduction Software Engineering Institute(SEI) Technical Note CMUSEI-2006-TN-011 February 2006
[153] Roberto Passerone Semantic Foundations for Heterogeneous SystemsPhD thesis Department of Electrical Engineering and Computer Sci-ences University of California Berkeley Berkeley CA 94720 May2004
[154] Roberto Passerone Jerry R Burch and Alberto L Sangiovanni-Vincentelli Refinement preserving approximations for the design andverification of heterogeneous systems Formal Methods in SystemDesign 31(1)1ndash33 August 2007
[155] Roberto Passerone Luca de Alfaro Thomas A Henzinger and AlbertoSangiovanni-Vincentelli Convertibility verification and converter syn-thesis Two faces of the same coin In Proceedings of InternationalConference on Computer Aided Design San Jose CA 2002
[156] Roberto Passerone Imene Ben Hafaiedh Susanne Graf Albert Ben-veniste Daniela Cancila Arnaud Cuccuru Seacutebastien Geacuterard FrancoisTerrier Werner Damm Alberto Ferrari Leonardo Mangeruca Bern-hard Josko Thomas Peikenkamp and Alberto Sangiovanni-VincentelliMetamodels in Europe Languages tools and applications IEEEDesign and Test of Computers 26(3)38ndash53 MayJune 2009
[157] Paul Le Guernic and Thiserry Gautier and Michel Le Borgne andClaude Le Maire Programming real-time applications with SignalProceedings of the IEEE 79(9)1321ndash1336 1991
[158] I Pill B Jobstmann R Bloem R Frank M Moulin B SterinM Roveri and S Semprini Property simulation Technical ReportProsyd D121 2005
[159] Dumitru Potop-Butucaru Benoicirct Caillaud and Albert BenvenisteConcurrency in synchronous systems Formal Methods in SystemDesign 28(2)111ndash130 2006
[160] Dumitru Potop-Butucaru Robert de Simone and Yves Sorel Neces-sary and sufficient conditions for deterministic desynchronization InChristoph M Kirsch and Reinhard Wilhelm editors EMSOFT pages124ndash133 ACM 2007
RR ndeg 8147
Contracts for System Design 64
[161] Terry Quatrani Visual modeling with Rational Rose 2000 and UML(2nd ed) Addison-Wesley Longman Ltd Essex UK UK 2000
[162] R Sudarsan and SJ Fenves and RD Sriram and F Wang A productinformation modeling framework for product lifecycle managementComputer-Aided Design 371399ndash1411 2005
[163] Jean-Baptiste Raclet Quotient de speacutecifications pour la reacuteutilisationde composants PhD thesis Ecole doctorale Matisse universiteacute deRennes 1 November 2007
[164] Jean-Baptiste Raclet Residual for Component Specifications In Procof the 4th International Workshop on Formal Aspects of ComponentSoftware (FACSrsquo07) 2007
[165] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct CaillaudAxel Legay and Roberto Passerone Modal interfaces Unifyinginterface automata and modal specifications In Proceedings of theNinth International Conference on Embedded Software (EMSOFT09)pages 87ndash96 Grenoble France October 12ndash16 2009
[166] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct CaillaudAxel Legay and Roberto Passerone A modal interface theory forcomponent-based design Fundamenta Informaticae 108(1-2)119ndash149 2011
[167] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct Caillaudand Roberto Passerone Why are modalities good for interfacetheories In Proc of the 9th International Conference on Applicationof Concurrency to System Design (ACSDrsquo09) IEEE Computer SocietyPress 2009
[168] Richard Payne and John Fitzgerald Evaluation of ArchitecturalFrameworks Supporting Contract-Based Specification Technical Re-port CS-TR-1233 Computing Science Newcastle University UK Dec2010 available from httpwwwcsnclacukpublicationstrspapers1233pdf
[169] Robert W Floyd Assigning meaning to programs In JT Schwartzeditor Proceedings of Symposium on Applied Mathematics volume 19pages 19ndash32 1967
[170] A Sangiovanni-Vincentelli S Shukla J Sztipanovits G Yang andD Mathaikutty Metamodeling An emerging representation paradigmfor system-level design Special Section on Meta-Modeling IEEEDesign and Test 26(3)54ndash69 2009
[171] Alberto Sangiovanni-Vincentelli Quo vadis sld Reasoning aboutthe trends and challenges of system level design Proc of the IEEE95(3)467ndash506 2007
[172] D Schmidt Model-driven engineering IEEE Computer pages 25ndash31February 2006
[173] German Sibay Sebastian Uchitel and Viacutector Braberman ExistentialLive Sequence Charts Revisited In ICSE 2008 30th InternationalConference on Software Engineering ACM May 2008
[174] Joseph Sifakis Component-Based Construction of HeterogeneousReal-Time Systems in Bip In Giuliana Franceschinis and KarstenWolf editors Petri Nets volume 5606 of Lecture Notes in ComputerScience page 1 Springer 2009
[175] Functional safety of electricalelectronicprogrammable electronicsafety-related systems Standard IEC 61508
[176] Eugene W Stark A proof technique for relyguarantee properties InS N Maheshwari editor FSTTCS volume 206 of Lecture Notes inComputer Science pages 369ndash391 Springer 1985
[177] Stavros Tripakis Ben Lickly Thomas A Henzinger and Edward ALee On relational interfaces In Proc of the 9th ACM amp IEEEInternational conference on Embedded software (EMSOFTrsquo09) pages67ndash76 ACM 2009
[178] Stavros Tripakis Ben Lickly Thomas A Henzinger and Edward ALee A theory of synchronous relational interfaces ACM TransProgram Lang Syst 33(4)14 2011
[179] Sebastiaacuten Uchitel and Marsha Chechik Merging partial behaviouralmodels In Proc of the 12th ACM SIGSOFT International Symposiumon Foundations of Software Engineering (SIGSOFT FSErsquo10) pages43ndash52 ACM 2004
[180] Jos Warmer and Anneke Kleppe The Object Constraint LanguageGetting Your Models Ready for MDA Addison-Wesley LongmanPublishing Co Inc Boston MA USA 2nd edition 2003
RR ndeg 8147
RESEARCH CENTRERENNES ndash BRETAGNE ATLANTIQUE
Campus universitaire de Beaulieu35042 Rennes Cedex
PublisherInriaDomaine de Voluceau - RocquencourtBP 105 - 78153 Le Chesnay Cedexinriafr
ISSN 0249-6399
- Introduction
-
- The Present System Design
- The Future CPS and SoS
- The Need for a Methodological Effort
- Contract based design
- Readers guide
-
- System Design Challenges
-
- Complexity of Systems
- Complexity of OEM-Supplier Chains
- Managing Requirements
- Managing Risks
- System-wide Optimization
-
- How Challenges have been addressed so far
-
- Complexity of Systems and System-wide Optimization
-
- Layered design
- Component-based design
- The V-model process
- Model-Based Design
- Virtual Integration
- Platform Based Design
-
- Complexity of OEM-Supplier Chains Standardization and Harmonization
-
- Standardization of design entities
- Harmonization of processes and certification
-
- Managing Requirements Traceability and Multiple Viewpoints
- Cross-company Shared Risk Management
- The Need for Contracts
-
- Contracts what why where and how
-
- Contracts
-
- Components and their Environment Contracts
-
- Contract Operators
-
- Contract Composition and System Integration
- Contract Refinement and Independent Development
- Contract Conjunction and Viewpoint Fusion
-
- Contracts in requirement engineering
- Contract Support for Design Methodologies
-
- Supporting open systems
- Managing Requirements and Fusing Viewpoints
- Design Chain Management Re-using and Independent Development
- Deployment and Mapping
-
- Bibliographical note
-
- A Mathematical Meta-theory of Contracts
-
- Components and their composition
- Contracts
- Refinement and conjunction
- Contract composition
- Quotient
- Discussion
- Observers
- Bibliographical note
-
- Panorama of concrete theories
- Panorama AssumeGuarantee contracts
-
- Dataflow AG contracts
- Capturing exceptions
- Dealing with variable alphabets
- Synchronous AG contracts
- Observers
- Discussion
- Bibliographical note
-
- Panorama Interface theories
-
- Components as io-automata
- Interface Automata with fixed alphabet
- Modal Interfaces with fixed alphabet
- Modal Interfaces with variable alphabet
- Projecting and Restricting
- Observers
- Bibliographical note
-
- Panorama Timed Interface Theories
-
- Components as Event-Clock Automata
- Modal Event-Clock Specifications
- Bibliographical note
-
- Panorama Probabilistic Interface Theories
-
- Components as Probabilistic Automata
- Simple Modal Probabilistic Interfaces
- Bibliographical note
-
- The Parking Garage an example in Requirements Engineering
-
- The contract framework
- Top level requirements
- Formalizing requirements as contracts
- Sub-contracting to suppliers
- The four ``C
-
- Consistency amp Compatibility
- Correctness
- Completeness
-
- Discussion
-
- Contracts in the context of Autosar
-
- The Autosar context
- The contract framework
- Exterior Light Management System
-
- Function and timing
- Safety
-
- Integrating Contracts in Autosar
- Summary and discussion
-
- Conclusion
-
- What contracts can do for the designer
- Status of research
- Status of practice
- The way forward
-
- References
-
ISS
N02
49-6
399
ISR
NIN
RIA
RR
--81
47--
FR+E
NG
RESEARCHREPORTNdeg 8147November 2012
Project-Teams S4
Contracts for SystemsDesignAlbert Benveniste Benoicirct Caillaud Dejan NickovicRoberto Passerone Jean-Baptiste Raclet Philipp ReinkemeierAlberto Sangiovanni-Vincentelli Werner DammTom Henzinger Kim Larsen
RESEARCH CENTRERENNES ndash BRETAGNE ATLANTIQUE
Campus universitaire de Beaulieu35042 Rennes Cedex
Contracts for Systems Design
Albert Benvenistelowast Benoicirct Caillauddagger Dejan NickovicDagger
Roberto Passeronesect Jean-Baptiste Racletpara Philipp Reinkemeier
Alberto Sangiovanni-Vincentellilowastlowast Werner Dammdaggerdagger
Tom HenzingerDaggerDagger Kim Larsen
Project-Teams S4
Research Report ndeg 8147 mdash November 2012 mdash 64 pages
This work was funded in part by the European STREP-COMBEST project number 215543 the European projects CESAR of the ARTEMIS JointUndertaking and the European IP DANSE the Artist Design Network of Excellence number 214373 the MARCO FCRP TerraSwarm grant the iCyPhyprogram sponsored by IBM and United Technology Corporation the VKR Center of Excellence MT-LAB and the German Innovation Alliance on EmbeddedSystems SPES2020
lowast INRIA Rennes France corresp author AlbertBenvenisteinriafrdagger INRIA Rennes FranceDagger Austrian Institute of Technology (AIT)sect University of Trento Italypara IRIT-CNRS Toulouse France Offis and University of Oldenburglowastlowast University of California at Berkeleydaggerdagger Offis and University of OldenburgDaggerDagger IST Austria Klosterneuburg
Aalborg University Danmark
Abstract Systems design has become a key challenge and differentiating factor over the last decadesfor system companies Aircrafts trains cars plants distributed telecommunication military or health caresystems and more involve systems design as a critical step Complexity has caused system design timesand costs to go severely over budget so as to threaten the health of entire industrial sectors Heuristicmethods and standard practices do not seem to scale with complexity so that novel design methods andtools based on a strong theoretical foundation are sorely neededModel-based design as well as other methodologies such as layered and compositional design have beenused recently but a unified intellectual framework with a complete design flow supported by formaltools is still lacking albeit some attempts at this framework such as Platform-based Design have beensuccessfully deployedRecently an rdquoorthogonalrdquo approach has been proposed that can be applied to all methodologies proposedthus far to provide a rigorous scaffolding for verification analysis and abstractionrefinement contract-based design Several results have been obtained in this domain but a unified treatment of the topic thatcan help in putting contract-based design in perspective is still missing This paper intends to providesuch treatment where contracts are precisely defined and characterized so that they can be used in designmethodologies such as the ones mentioned above with no ambiguity In addition the paper provides animportant link between interfaces and contracts to show similarities and correspondences Examples ofthe use of contracts in design are provided as well as in depth analysis of existing literature
Key-words system design component based design contract interface
Contrats pour la conception de systegravemesReacutesumeacute Cet article fait le point sur le concept de contrat pour la conception de systegravemes Les contrats que nous proposonsportent non seulement sur des proprieacuteteacutes de typage de leurs interfaces mais incluent une description abstraite de comportementsNous proposons une meacuteta-theacuteorie ou si lrsquoon veut une theacuteorie geacuteneacuterique des contrats qui permet le deacuteveloppement seacutepareacute desous-systegravemes Nous montrons que cette meacuteta-theacuteorie se speacutecialise en lrsquoune ou lrsquoautre des theacuteories connues
Mots-cleacutes conception des systegravemes composant contrat interface
Contracts for System Design 4
CONTENTS
I Introduction 6I-A The Present System Design 6I-B The Future CPS and SoS 6I-C The Need for a Methodological Effort 6I-D Contract based design 7I-E Readerrsquos guide 7
II System Design Challenges 8II-A Complexity of Systems 8II-B Complexity of OEM-Supplier Chains 9II-C Managing Requirements 9II-D Managing Risks 10II-E System-wide Optimization 10
III How Challenges have been addressed so far 10III-A Complexity of Systems and System-
wide Optimization 10III-A1 Layered design 11III-A2 Component-based design 11III-A3 The V-model process 11III-A4 Model-Based Design 12III-A5 Virtual Integration 12III-A6 Platform Based Design 13
III-B Complexity of OEM-Supplier ChainsStandardization and Harmonization 13III-B1 Standardization of design
entities 13III-B2 Harmonization of processes
and certification 14III-C Managing Requirements Traceability
and Multiple Viewpoints 14III-D Cross-company Shared Risk Management 14III-E The Need for Contracts 15
IV Contracts what why where and how 16IV-A Contracts 16
IV-A1 Components and their Envi-ronment Contracts 16
IV-B Contract Operators 17IV-B1 Contract Composition and
System Integration 17IV-B2 Contract Refinement and In-
dependent Development 18IV-B3 Contract Conjunction and
Viewpoint Fusion 18IV-C Contracts in requirement engineering 19IV-D Contract Support for Design Method-
ologies 20IV-D1 Supporting open systems 20IV-D2 Managing Requirements and
Fusing Viewpoints 20IV-D3 Design Chain Management
Re-using and IndependentDevelopment 21
IV-D4 Deployment and Mapping 21IV-E Bibliographical note 23
V A Mathematical Meta-theory of Contracts 24V-A Components and their composition 24V-B Contracts 25V-C Refinement and conjunction 25V-D Contract composition 26V-E Quotient 27V-F Discussion 27V-G Observers 27V-H Bibliographical note 28
VI Panorama of concrete theories 29
VII Panorama AssumeGuarantee contracts 29VII-A Dataflow AG contracts 30VII-B Capturing exceptions 30VII-C Dealing with variable alphabets 31VII-D Synchronous AG contracts 32VII-E Observers 32VII-F Discussion 32VII-G Bibliographical note 32
VIII Panorama Interface theories 33VIII-A Components as io-automata 33VIII-B Interface Automata with fixed alphabet 34VIII-C Modal Interfaces with fixed alphabet 35VIII-D Modal Interfaces with variable alphabet 37VIII-E Projecting and Restricting 38VIII-F Observers 40VIII-G Bibliographical note 40
IX Panorama Timed Interface Theories 42IX-A Components as Event-Clock Automata 42IX-B Modal Event-Clock Specifications 43IX-C Bibliographical note 43
X Panorama Probabilistic Interface Theories 44X-A Components as Probabilistic Automata 44X-B Simple Modal Probabilistic Interfaces 45X-C Bibliographical note 45
XI The Parking Garage an example in Require-ments Engineering 45
XI-A The contract framework 45XI-B Top level requirements 46XI-C Formalizing requirements as contracts 46XI-D Sub-contracting to suppliers 48XI-E The four ldquoCrdquo 49
XI-E1 Consistency amp Compatibility 49XI-E2 Correctness 50XI-E3 Completeness 50
XI-F Discussion 50
RR ndeg 8147
Contracts for System Design 5
XII Contracts in the context of AUTOSAR 50XII-A The AUTOSAR context 50XII-B The contract framework 51XII-C Exterior Light Management System 51
XII-C1 Function and timing 51XII-C2 Safety 56
XII-D Integrating Contracts in AUTOSAR 58XII-E Summary and discussion 59
XIII Conclusion 59XIII-A What contracts can do for the designer 59XIII-B Status of research 59XIII-C Status of practice 59XIII-D The way forward 59
References 60
RR ndeg 8147
Contracts for System Design 6
I INTRODUCTION
A The Present System Design
System companies such as automotive avionics and con-sumer electronics companies are facing significant difficultiesdue to the exponentially raising complexity of their productscoupled with increasingly tight demands on functionalitycorrectness and time-to-market The cost of being late tomarket or of imperfections in the products is staggering aswitnessed by the recent recalls and delivery delays that systemindustries had to bear
In 2010 Toyota had to recall 10 Million cars worldwidefor reasons that ranged from the infamous sticky acceleratorpedals to steering and engine problems The last recall atthe end of August 2010 was for the engine control moduleToyota is not alone in this situation Most of the automotivemakers had one or more major recalls in the recent past(see eg httpwwwautorecallsus) involving electronics aswell as mechanical parts Boeing and Airbus Industries hadsignificant delays in the delivery of their latest planes (787and A380) For the A380 underlying causes were cited asissues in the cabling system configuration management anddesign process In particular the complexity of the cabinwiring (100000 wires and 40300 connectors) was considereda major issue (see httpenwikipediaorgwikiAirbus_A380)The delays caused the departure of both the EADS and AirbusCEOs and of the program manager for the A380 and caused anoverall earning shortfall of 48 Billion Euros Boeing originallyplanned the first flight of the 787 for August 2007 (seehttpenwikipediaorgwikiBoeing_787) but after a streamof delay announcements the actual first flight occurred onDecember 15 2009 The delays were caused by a number ofunfortunate events and design errors and caused at least a 23Billion USD write-off not counting the claim of Air India of1 Billion USD damages for delayed delivery and the revenueshortfalls
These are examples of the devastating effects that designproblems may cause The specific root causes of these prob-lems are complex and relate to a number of issues rangingfrom design processes and relationships with different depart-ments of the same company and with suppliers to incompleterequirement specification and testing
B The Future CPS and SoS
Many products and services require to take into considera-tion the interactions of computational and physical processesSystems where this interaction is tight and needs special careare called Cyber-Physical Systems (CPS) [133] The broadmajority of these new applications can be classified as ldquodis-tributed sense and control systemsrdquo that go substantially be-yond the ldquocomputerdquo or ldquocommunicaterdquo functions traditionallyassociated with information technology These applicationshave the potential to radically influence how we deal with abroad range of crucial problems facing our society today forexample national security and safety including surveillanceenergy management and distribution environment control
efficient and reliable transportation and mobility and effectiveand affordable health care A recurring property of theseapplications is that they engage all the platform componentssimultaneouslymdashfrom data and computing services on thecloud of large-scale servers data gathering from the sensoryswarm and data access on mobile devicesmdashwith significantheterogeneity These large scale systems composed of subsys-tems that are themselves systems are now called Systems ofSystems (SoS) and are heavily investigated
As the complexity of these systems increases our inabilityto rigorously model the interactions between the physical andthe cyber sides creates serious vulnerabilities Systems becomeunsafe with disastrous inexplicable failures that could not havebeen predicted The challenges in the realization and operationof these CPS and SoS are manifold and cover a broad range oflargely unsolved design and run-time problems These includemodeling and abstraction verification validation and testreliability and resiliency multi-scale technology integrationand mapping power and energy security diagnostics andrun-time management Failure to address these challengesin a cohesive and comprehensive way will most certainlydelay if not prohibit the widespread adoption of these newtechnologies
C The Need for a Methodological Effort
We believe the most promising means to address the chal-lenges in systems engineering is to employ structured andformal design methodologies that seamlessly and coherentlycombine the various dimensions of the design space (be itbehavior space or time) that provide the appropriate abstrac-tions to manage the inherent complexity and that can pro-vide correct-by-construction implementations The followingtechnology issues must be addressed when developing newapproaches to the design of complex systems CPS and SoSbull The overall design flows for heterogeneous systemsmdash
meant here both in a technical and also an organiza-tional sensemdashand the associated use of models acrosstraditional boundaries are not well developed and un-derstood Relationships between different teams inside asame company or between different stake-holders in thesupplier chain are not well supported by solid technicaldescriptions for the mutual obligations
bull System requirement capture and analysis is in largepart a heuristic process where the informal text andnatural language-based techniques in use today are facingsignificant challenges Formal requirement engineeringis in its infancy mathematical models formal analysistechniques and links to system implementation must bedeveloped
bull Dealing with variability uncertainty and life-cycle issuessuch as extensibility of a product family are not well-addressed using available systems engineering methodol-ogy and tools
bull Design-space exploration is rarely performed adequatelyyielding suboptimal designs where the architecture se-lection phase does not consider extensibility re-usability
RR ndeg 8147
Contracts for System Design 7
and fault tolerance to the extent that is needed to reducecost failure rates and time-to-market
bull The verification and validation of ldquocomplex systemsrdquoparticularly at the system integration phase where anyinteractions are complicated and extremely costly toaddress is a common need in defense automotive andother industries
The challenge is to address the entire process and not toconsider only point solutions of methodology tools andmodels that ease part of the design
D Contract based design
It is our goal to offer a new approach to the system designproblem that is rigorous and effective in dealing with theproblems and challenges described before and that at thesame time does not require a radical change in the wayindustrial designers carry out their task as it cuts across designflows of different type contract-based design
Contracts in the layman use of the term are establishedwhen an OEM must agree with its suppliers on the subsystemor component to be delivered Contracts involve a legal partbinding the different parties and a technical annex that servesas a reference regarding the entity to be delivered by thesuppliermdashin this work we focus on the technical facet ofcontracts Contracts can also be used through their technicalannex in concurrent engineering when different teams developdifferent subsystems or different aspects of a system within asame company
In this paper we argue that contracts can be actually usedalmost everywhere and at nearly all stages of system designfrom early requirements capture to embedded computinginfrastructure and detailed design involving circuits and otherhardware Contracts explicitly handle pairs of properties re-spectively representing the assumptions on the environmentand the guarantees of the system under these assumptionsIntuitively a contract is a pair
C = (AG) of Assumptions Guarantees
characterizing in a formal way 1) under which context thedesign is assumed to operate and 2) what its obligations areAssumeGuarantee reasoning has been known for quite sometime but it has been used mostly as verification mean for thedesign of software Our purpose is more ambitious contractbased design with explicit assumptions is a philosophy thatshould be followed all along the design with all kinds ofmodels whenever necessary Here the models we mean arerichmdashnot only profiles types or taxonomy of data but alsomodels describing the functions performances of variouskinds (time and energy) and safety The consideration of richcontracts as above in the industry is still in its infancy Tomake contract-based design a technique of choice for systemengineers we must developbull Mathematical foundations for contract representation and
requirement engineering that enable the design of frame-works and tools
bull A system engineering framework and associated method-ologies and tool sets that focus on system requirementmodeling contract specification and verification at mul-tiple abstraction layers The framework should addresscross-boundary and cross-organizational design activities
This paper intends to provide a unified treatment of contractswhere they are precisely defined and characterized so that theycan be used in design with no ambiguity In addition the paperprovides an important link between interfaces and contractsto show similarities and correspondences Examples of the useof contracts in design will be provided as well as in depthanalysis of existing literature
E Readerrsquos guide
The organization of the paper is explained in Table IIn Section II a review of the challenges that are faced by the
system industry is proposed followed in Section III by ananalysis of the design methodologies that have been deployedto cope with them
Section IV develops a primer on contracts by using a verysimple example requiring only elementary mathematical back-ground to be followed Its purpose is to smoothly introducethe different concepts and operations we need for a contractframeworkmdashthe restricted case considered is by no meansrepresentative of the kind of system we can address usingcontracts We then introduce a motivating example repre-sentative of requirement engineering In a third sub-sectionldquorequirementsrdquo on a theory of contracts are identified fromanalyzing what is expected from contract-based design andin particular the support for 1) the development of differentaspects or viewpoints of a system such as its function safetytiming and resource use by different teams and how to fusethese different aspects and 2) the possibility for differentsuppliers to develop independently the different subsystemssubcontracted to them This section concludes with the relatedbibliography
Section V is the cornerstone of this paper and it is a newvista on contracts The so-called ldquometa-theoryrdquo of contractsis introduced and developed in detail By meta-theory wemean the collection of concepts operations and propertiesthat any formal contract framework should offer Conceptsoperations and properties are thus stated in a fairly genericway Every concrete framework compliant with this meta-theory will inherit these generic properties The meta-theoryfocuses on assumptions and guarantees its formalizes howdifferent aspects or viewpoints of a specification can beintegrated and on which basis independent development bydifferent suppliers can be safely performed
So far the meta-theory is non effective in that it is notsaid how component and contracts are effectively representedand manipulated The subsequent series of sections propose apanorama of major concrete contract frameworks Section VIIdevelops the AssumeGuarantee contracts This framework isthe most straightforward instance of the meta-theory It dealswith pairs (AG) of assumptions and guarantees explicitlyA and G being both expressed as properties This framework
RR ndeg 8147
Contracts for System Design 8
Section methodological tutorial fundamental technical applicationSection IIchallengesSection IIIaddressing the challengesSection IVwhy contracts where and how
Section Vcontract meta-theory
Section VIIAssumeGuarantee contractsSection VIIIInterface theoriesSection IXtimedSection Xprobabilistic
Section XIrequirements engineeringSection XIIAUTOSAR
Section IIdarr
Section III Section IV
Section V Section VII mdash Section VIIIdarr darr
Section XII Section XI
Section IX mdash Section Xdarr darr
Section Section
Section IIdarr
Section III Section IV
Section V Section XI Section XII
Table IREADERrsquoS GUIDE CATEGORIZATION OF THE DIFFERENT SECTIONS (TOP) AND
DEPENDENCIES (BOTTOM LEFT IN-DEPTH READING BOTTOM-RIGHT QUICK READING)
is flexible in that it allows for different styles of descriptionof such propertiesmdashcomputational efficiency depends on thestyle adopted Section VIII develops the Interface theoriesin which assumptions and guarantees are specified by meansof a single object the interface Interface theories turn outto include the most effective frameworks They can easily beadapted to encompass timing (Section IX) and probabilistic(Section X) characteristics of systems
In Section XI a toy example in requirements engineeringis developed This example is simple but rich enough to illus-trate the very difficulties in formalizing requirements It alsoillustrates well the added value of contract based requirementsengineering First the different responsibilities (assumptionsversus obligation or guarantees) that requirement implicit referto are made explicit and captured in our contract frameworkSecond contracts offer a formal meaning for documents ofrequirements structured into chapters or viewpoints Contractsoffer formal support for checking important properties suchas consistency compatibility completeness and more Finallycontracts offer significant assistance in the process of deduc-ing from the top specification an architecture of specificationsfor the different sub-systems for independent developmentWhile our application example is a toy one is it neverthelesstoo complex for dealing with it by hand We handle it by usinga proof-of-concept tool for contract management
Finally Section XII develops a case study in the contextof AUTOSAR AUTOSAR is a recently established standardin the automobile sector This standard was developed withthe objective of allowing for better flexibility in componentreuse and OEMsupplier relations This section illustrates howcontracts can be used to break into simple pieces of reasoningthe difficult task of correct system integration
II SYSTEM DESIGN CHALLENGES
Many challenges face the system community to deliverproducts that are reliable and effective We summarize someof them below
A Complexity of Systems
The ever-expanding use of electronic embedded systems tocontrol increasingly many aspects of the real world and thetrend to interconnect more and more such systems (often fromdifferent manufacturers) into a global network are creating achallenging scenario for system designers In this scenario thethree challenges that are taking center stage are as follows
The Hardware Platform Complexity Most system com-panies rely on Components off-the-shelf (COTS) and pro-grammability to implement their applications For companieswho build ldquophysically largerdquo systems such as avionics and au-tomotive companies the complexity of the hardware platform
RR ndeg 8147
Contracts for System Design 9
Design task Tasks Tasks Tasks Tasks Tasks Tasksdelayed delayed delayed causing delay causing delay causing delayautomotive automation medical automotive automation medical
System integration 630 565 667 423 190 375test and verificationSystem architecture 296 261 333 385 429 313design and specificationSoftware application 444 304 750 269 310 250andor middlewaredevelopment and testProject management 370 283 167 538 381 375and planning
Table IIDIFFICULTIES RELATED TO SYSTEM INTEGRATION
is reflected in the number of Electronic Control Units and intheir interconnections For a top-of-the-line automobile thenumber of processors to manage and interconnect is above50 The layout of the cables that connect these processingelements with sensors and actuators is a serious concern Initialproduction of the Airbus A380 was troubled by delays in partattributed to the 530 km (330 mi) of wiring in each aircraft
The Embedded Software Complexity Given the cost andrisks associated to developing hardware solutions system com-panies are selecting hardware platforms that can be customizedby reconfiguration andor by software programmability Inparticular software is taking the lionrsquos share of the implemen-tation budgets and cost In cell phones more than 1 millionlines of code is standard today while in automobiles theestimated number of lines by 2010 is in the order of hundredsof millions and in the Boeing 787 is in the order of 20 millionlines However as this happens the complexity explosion ofthe software component causes serious concerns for the finalquality of the products and the productivity of the engineeringteams
The Integration Complexity A standard technique to dealwith complexity consists in decomposing top-down the systeminto subsystems This approach which has been customar-ily adopted by the semiconductor industry for years has alimitation as a designer or a group of designers has to fullycomprehend the entire system and to partition appropriately itsvarious parts a difficult task given the enormous complexityof todayrsquos systems
Hence the future is one of developing systems by compos-ing pieces that all or in part have already been predesignedor designed independently by other design groups or evencompanies This has been done routinely in vertical designchains for example in the avionics and automotive sectorsalbeit in a heuristic and ad hoc way The resulting lack of anoverall understanding of the interplay of the subsystems and ofthe difficulties encountered in integrating very complex partscause system integration to become a nightmare in the systemindustry as demonstrated by Table II1
In addition heterogeneity comes into play Integration of
1VDC research Track 3 Embedded Systems Market Statistics Exhibit II-13from volumes on automotiveindustrial automationmedical 2008
electronic and mechanical design tools and frameworks will beessential in the near future Integration of chemical electronicand biology tools will be essential in the further future fornano-systems Data integration and information flow amongthe companies forming the chain have to be supported Inother words it is essential that the fundamental steps of systemdesign (functional partitioning allocation on computationalresources integration and verification) be supported acrossthe entire design development cycle and across different dis-ciplines
B Complexity of OEM-Supplier Chains
The source of the above problems is clearly the increase incomplexity It is however also the difficulty of the OEMs inmanaging the integration and maintenance process with sub-systems that come from different suppliers who use differentdesign methods different software architectures and differenthardware platforms
There are also multiple challenges in defining technicalannexes to commercial contracts between OEM and suppli-ers Specifications used for procurement should be preciseunambiguous and complete However a recurrent reason forfailures causing deep iterations across supply chain boundariesrests in incomplete characterizations of the environment ofthe system to be developed by the supplier such as missinginformation about failure modes and failure rates missing in-formation on possible sources for interferences through sharedresources and missing boundary conditions This highlightsthe need to explicate assumptions on the design context inOEM-supplier commercial contracts In light of an increasedsharing of hardware resources by applications developed bymultiple suppliers a contract-based approach seems indispens-able for resolving liability issues and allowing applicationswith different criticality levels to co-exist (such as ASILlevels[175] [13] in automotive)
C Managing Requirements
We argued that the design chains should connect seamlesslyto minimize design errors and time-to-market delays Yet theboundaries among companies and between different divisionsof the same company are often not as clean as needed anddesign specs move from one company (or one division) to the
RR ndeg 8147
Contracts for System Design 10
next in non-executable and often unstable and imprecise formsthus yielding misinterpretations and consequent design errorsIn addition errors are often caught only at the final integrationstep as the specifications were incomplete and imprecisefurther nonfunctional specifications (eg timing power con-sumption size) are difficult to trace Further it is commonpractice to structure system level requirements into severalldquochaptersrdquo ldquoaspectsrdquo or ldquoviewpointsrdquo Examples include thefunctions safety timing and energy viewpoints Quite oftenthese different viewpoints are developed by different teamsusing different skills frameworks and tools Yet they are notunrelated as we already mentioned Without a clean approachto handle multiple viewpoints the only sensible way is tocollect these viewpoints into a single requirements documentwhich is then seen as a flat collection of requirements forsubsequent design Since this is clearly impracticable thecommon practice instead is to discard some of the viewpointsin a first stage eg by considering only functions and safetyDesigns are then developed based on these only viewpointsOther viewpoints are subsequently taken into account (timingenergy) thus resulting in late and costly modifications andre-designs
Requirement engineering is a discipline that aims at improv-ing this situation by paying close attention to the managementof the requirement descriptions and traceability support (egusing commercial tools such as DOORS2 in combinationwith Reqtify3) and by inserting whenever possible preciseformulation and analysis methods and tools Research in thisarea is active but we believe more needs to be done to makethis essential step a first class citizen in system design Indeedif the specification quality is low then the entire design processis marred since the very beginning The overall system productspecification is somewhat of an art today since to verify itscompleteness and its correctness there is little that it can beused to compare with
D Managing Risks
System design processes are highly concurrent distributedand typically multi-domain often involving more than onehundred sub-processes The complexity of the entire designprocess and of the relationships between players in the supplychain creates the need to elaborate risk sharing and riskmanagement plans because of the potential enormity of theimpact that design errors and supplier solidity may have onthe economics of a company Risk management has thusbecome a requirement of most of public companies as fi-nancial social and political risks are analyzed and appropriatecountermeasures have to be prepared as a requirement fromthe regulatory bodies Risk mitigation measures typically coverall phases of design processes ranging from assuring highquality initial requirements to early assessments of risks inmeeting product requirements during the concept phase toenforcing complete traceability of such requirements with
2 httpwww-01ibmcomsoftwareawdtoolsdoorsproductline3httpetc
requirements management tools to managing consistency andsynchronization across concurrent sub-processes using PLMtools4 If we will be able to change the design processalong the lines of more formal approaches better complexityhandling better requirement engineering then risks will besubstantially lower than they are today
E System-wide Optimization
We believe that since the design process is fragmentedproduct optimization is rarely carried out across more thanone company boundary and even then it is limited due tobull The lack of appropriate models encompassing both func-
tional and non-functional (Quality of Service) aspectscovering both internal use and export outside the com-pany
bull The time pressure to meet the product deadlinesbull The functional description that is over-constrained by
architectural considerations which de facto eliminate po-tentially interesting implementation alternatives
If the design process were carried out as in a unique well-integrated virtual company including all the players shownabove the overall ecosystem would greatly benefit The issuehere is to allow a reasonably efficient design space explorationby providing a framework where different architectures couldbe quickly assembled and evaluated at each layer of abstractioncorresponding to the design task being considered in the chain
III HOW CHALLENGES HAVE BEEN ADDRESSED SO FAR
In this section we present a review and a critical analysisof the design methodologies that have been deployed to copewith the challenges exposed in the previous section
A Complexity of Systems and System-wide Optimization
Multiple lines of attack have been developed by researchinstitutions and industry to cope with the exponential growth insystems complexity starting from the iterative and incrementaldevelopment several decades ago [123] Among them ofparticular interest to the development of embedded controllersare Layered design Component-based design the V-modelprocess model-based development virtual integration andPlatform-Based Design (PBD) There are two basic princi-ples followed by these methods abstractionrefinement andcompositiondecomposition Abstraction and refinement areprocesses that relate to the flow of design between differentlayers of abstraction (vertical process) while compositionand decomposition operate at the same level of abstraction(horizontal process) Layered design the V-model processand model-based development focus on the vertical processwhile component-based design deals principally with the hor-izontal process PBD combines the two aspects in a unifiedframework and hence subsumes and can be used to integrated
4 PLM Product Lifecycle Management PLM centric design is used incombination with virtual modeling and digital mockups PLM acts as a database of virtual system components PLM centric design is for exampledeployed at Dassault-Aviation httpwwwdassault-aviationcomenaviationinnovationthe-digital-companydigital-designplm-toolshtmlL=1
RR ndeg 8147
Contracts for System Design 11
the other methodologies Contracts are ideal tools to solidifyboth vertical and horizontal processes providing the theoreticalbackground to support formal methods
1) Layered design Layered design copes with complexityby focusing on those aspects of the system pertinent to supportthe design activities at the corresponding level of abstractionThis approach is particularly powerful if the details of alower layer of abstraction are encapsulated when the designis carried out at the higher layer Layered approaches are wellunderstood and standard in many application domains Asan example consider the AUTOSAR standard5 This standarddefines several abstraction layers Moving from ldquobottomrdquoto ldquotoprdquo the micro-controller abstraction layer encapsulatescompletely the specifics of underlying micro-controllers thesecond layer abstracts from the concrete configuration of theElectronic Control Unit (ECU) the employed communicationservices and the underlying operating system whereas the(highest) application layer is not aware of any aspect ofpossible target architectures and relies on purely virtual com-munication concepts in specifying communication betweenapplication components Similar abstraction levels are definedby the ARINC standard in the avionic domains
The benefits of using layered design are manifold Using theAUTOSAR layer structure as example the complete separationof the logical architecture of an application (as represented bya set of components interconnected using the so-called virtualfunction bus) and target hardware is a key aspect of AUTOSARin that it supports decoupling of the number of automotivefunctions from the number of hardware components In par-ticular it is flexible enough to mix components from differentapplications on one and the same ECU This illustrates thedouble role of abstraction layers in allowing designers to focuscompletely on the logic of the application and abstracting fromthe underlying hardware while at the same time imposing aminimal (or even no) constraint on the design space of possiblehardware architectures In particular these abstractions allowthe application design to be re-used across multiple platformsvarying in number of bus-systems andor number and class ofECUs These design layers can in addition be used to matchthe boundaries of either organizational units within a companyor to define interfaces between different organizations in thesupply chain The challenge then rests in providing the properabstractions of lower-level design entities
2) Component-based design Whereas layered designs de-compose complexity of systems ldquoverticallyrdquo component-basedapproaches reduce complexity ldquohorizontallyrdquo whereby designsare obtained by assembling strongly encapsulated design enti-ties called ldquocomponentsrdquo equipped with concise and rigorousinterface specifications Re-use can be maximized by findingthe weakest assumptions on the environment sufficient to es-tablish the guarantees on a given component implementationWhile these interface specifications are key and relevant forany system the ldquoquality attributerdquo of perceiving a subsystemas a component is typically related to two orthogonal criteria
5See httpwwwautosarorg
that of ldquosmall interfacesrdquo and that of minimally constrainingthe deployment context so as to maximize the potential for re-use ldquoSmall interfacesrdquo ie interfaces which are both smallin terms of number of interface variables or ports as wellas ldquologically smallrdquo in that protocols governing the invoca-tion of component services have compact specifications notrequiring deep levels of synchronization constitute evidenceof the success of encapsulationmdashstill small interfaces mustencompass dynamic properties of the system The secondquality attribute is naturally expressible in terms of interfacespecifications where re-use can be maximized by finding theweakest assumptions on the environment sufficient to establishthe guarantees on a given component implementation
One challenge then for component-based design of em-bedded systems is to provide interface specifications that arerich enough to cover all phases of the design cycle Thiscalls for including non-functional characteristics as part ofthe component interface specifications which is best achievedby using multiple viewpoints Current component interfacemodels in contrast are typically restricted to purely functionalcharacterization of components and thus cannot capitalize onthe benefits of virtual integration testing as outlined above
The second challenge is related to product line designwhich allows for the joint design of a family of variants of aproduct The aim is to balance the contradicting goals of striv-ing for generality versus achieving efficient component im-plementations Methods for systematically deriving ldquoquotientrdquospecifications to compensate for ldquominorrdquo differences betweenrequired and offered component guarantees by composing acomponent with a wrapper component (compensating for suchdifferences as characterized by quotient specifications) existsfor restricted classes of component models [155]
3) The V-model process A widely accepted approach todeal with complexity of systems in the defense and trans-portation domain is to structure product development processesalong variations of the V diagram originally developed fordefense applications by the German DoD6
Its characteristic V-shape splits the product developmentprocess into a design and an integration phase Specificallyfollowing product level requirement analysis subsequent stepswould first evolve a functional architecture supporting productlevel requirements Sub-functions are then re-grouped takinginto account re-use and product line requirements into alogical architecture whose modules are typically developed bydifferent subsystem suppliers The realization of such modulesoften involves mechanical hydraulic electrical and electronicsystem design Subsequent phases would then unfold thedetailed design for each of these domains such as the designof the electronic subsystem involving among others the designof electronic control units These design phases are paralleledby integration phases along the right-hand part of the Vsuch as integrating basic- and application software on theECU hardware to actually construct the electronic control unitintegrating the complete electronic subsystems integrating the
6See eg httpwwwv-model-xtde
RR ndeg 8147
Contracts for System Design 12
mechatronic subsystem to build the module and integratingmultiple modules to build the complete product Not shownbut forming an integral part of V-based development processesare testing activities where at each integration level test-suites developed during the design phases are used to verifycompliance of the integrated entity to their specification
This presentation is overly simplistic in many ways Thedesign of electronic components in complex systems suchas aircrafts inherently involves multi-site multi-domain andcross-organizational design teams reflecting eg a partition-ing of the aircraft into different subsystems (such as primaryand secondary flight systems cabin fuel and wing) differentdomains such as the interface of the electronic subsystem tohydraulic andor mechanical subsystems control-law designtelecommunications software design hardware design diag-nostics and development-depth separated design activities car-ried out at the OEM and supplier companies This partitioningof the design space (along perspectives and abstraction layers)naturally lends itself to a parallelization of design activitiesa must in order to achieve timely delivery of the overallproduct leading often into the order of hundreds of concurrentdesign processes To summarize while being popular andwidely referenced the V-model process has become a ldquosloganrdquohiding the complexity of actual design processes In realitylarge system companies develop their own processes and thenstruggle for their application both in-house and across thesupplier chain
4) Model-Based Design Model-based design (MBD) is to-day generally accepted as a key enabler to cope with complexsystem design due to its capabilities to support early require-ment validation and virtual system integration MBD-inspireddesign languages and tools such as SysML7 [149] andorAADL [152] for system level modeling Catia and Model-ica [93] for physical system modeling Matlab-Simulink [118]for control-law design and UML8 [44] [147] Scade [32]and TargetLink for detailed software design depend on de-sign layer and application class The state-of-the-art in MBDincludes automatic code-generation simulation coupled withrequirement monitoring co-simulation of heterogeneous mod-els such as UML and Matlab-Simulink model-based analy-sis including verification of compliance of requirements andspecification models model-based test-generation rapid pro-totyping and virtual integration testing as further elaboratedbelow
In MBD today non-functional aspects such as performancetiming power or safety analysis are typically addressed indedicated specialized tools using tool-specific models withthe entailed risk of incoherency between the correspond-ing models which generally interact To counteract theserisks meta-models encompassing multiple views of designentities enabling co-modeling and co-analysis of typicallyheterogeneous viewpoint specific models have been developedExamples include the MARTE UML [148] profile for real-time
7httpwwwomgorgspecSysML8httpwwwomgorgspecUML
system analysis the SPEEDS HRC metamodel [156] and theMetropolis semantic meta-model [19] [67] [16] [170] InMetropolis multiple views are accommodated via the conceptof ldquoquantitiesrdquo that annotate the functional view of a designand can be composed along with subsystems using a suitablealgebra The SPEEDS meta-model building on and extendingSysML has been demonstrated to support co-simulation andco-analysis of system models for transportation applicationsallowing co-assessment of functional real-time and safety re-quirements It forms an integral part of the meta-model-basedinter-operability concepts of the CESAR reference technologyplatform9
Meta-modeling is also at the center of the model driven(software) development (MDD) methodology MDD is basedon the concept of the model-driven architecture (MDA) whichconsists of a Platform-Independent Model (PIM) of the ap-plication plus one or more Platform-Specific Models (PSMs)and sets of interface definitions MDA tools then supportthe mapping of the PIM to the PSMs as new technologiesbecome available or implementation decisions change [146]The Vanderbilt University group [119] has evolved an em-bedded software design methodology and a set of tools basedon MDD In their approach models explicitly represent theembedded software and the environment it operates in andcapture the requirements and the design of the applicationsimultaneously using domain-specific languages (DSL) Thegeneric modeling environment (GME) [119] provides a frame-work for model transformations enabling easy exchange ofmodels between tools and offers sophisticated ways to sup-port syntactic (but not semantic) heterogeneity The KerMetametamodeling workbench [91] is similar in scope
5) Virtual Integration Rather than ldquophysicallyrdquo integratinga system from subsystems at integration stages model-baseddesign allows systems to be virtually integrated based on themodels of their subsystem and the architecture specificationof the system Such virtual integration thus allows detectingpotential integration problems up front in the early designphases Virtual system integration is often a source of het-erogeneous system models such as when realizing an aircraftfunction through the combination of mechanical hydraulicand electronic systems Heterogeneous composition of modelswith different semantics was originally addressed in Ptolemy[88] Metropolis [20] [67] [16] [48] and in the SPEEDSmeta-model of heterogeneous rich components [65] [29] [31]albeit with different approaches Virtual integration involvesmodels of the functions the computer architecture with itsextra-functional characteristics (timing and other resources)and the physical system for control Some existing frameworksoffer significant support for virtual integration Ptolemy IIMetropolis and RT-Builder Developments around Catia andModelica as well as the new offer SimScape by Simulinkprovide support for virtual integration of the physical part atan advanced level
9wwwcesarprojecteu
RR ndeg 8147
Contracts for System Design 13
6) Platform Based Design Platform-based design was in-troduced in the late 1980s to capture a design process thatcould encompass horizontal (component-based design virtualintegration) and vertical (layered and model-based design)decompositions and multiple viewpoints and in doing sosupport the supply chain as well as multi-layer optimization
The idea was to introduce a general approach that couldbe shared across industrial domain boundaries that wouldsubsume the various definition and design concepts and thatwould extend it to provide a framework to reason aboutdesign Indeed the concepts have been applied to a variety ofvery different domains from automotive to System-on-Chipfrom analog circuit design to building automation to syntheticbiology
The basic tenets of platform-based design are as followsThe design progresses in precisely defined abstraction layersat each abstraction layer functionality (what the system issupposed to do) is strictly separated from architecture (howthe functionality could be implemented) This aspect is clearlyrelated to layered design and hence it subsumes it
Each abstraction layer is defined by a design platform Adesign platform consists ofbull A set of library components This library not only con-
tains computational blocks that carry out the appropriatecomputation but also communication components that areused to interconnect the computational components
bull Models of the components that represent a characteri-zation in terms of performance and other non-functionalparameters together with the functionality it can supportNot all elements in the library are pre-existing com-ponents Some may be ldquoplace holdersrdquo to indicate theflexibility of ldquocustomizingrdquo a part of the design that isoffered to the designer In this case the models representestimates of what can be done since the components arenot available and will have to be designed At times thecharacterization is indeed a constraint for the implementa-tion of the component and it is obtained top-down duringthe refinement process typical of layered designs Thislayering of abstractions based on mathematical models istypical of model-based methods and the introduction ofnon-functional aspects of the design relates to viewpoints
bull The rules that determine how the components can beassembled and how the the functional and non-functionalcharacteristics can be computed given the ones of thecomponents to form an architectureThen a platformrepresents a family of designs that satisfies a set ofplatform-specific constraints [15] This aspect is relatedto component-based design enriched with multiple view-points
This concept of platform encapsulates the notion of re-use asa family of solutions that share a set of common features (theelements of the platform) Since we associate the notion ofplatform to a set of potential solutions to a design problem weneed to capture the process of mapping a functionality (whatthe system is supposed to do) with the platform elements thatwill be used to build a platform instance or an ldquoarchitecturerdquo
(how the system does what it is supposed to do) The strictseparation between function and architecture as well as themapping process have been highly leveraged in AUTOSARThis process is the essential step for refinement and provides amechanism to proceed towards implementation in a structuredway Designs on each platform are represented by platform-specific design models A design is obtained by a designerrsquoscreating platform instances (architectures) via composing plat-form components (process that is typical of component-baseddesign) by mapping the functionality onto the components ofthe architecture and by propagating the mapped design in thedesign flow onto subsequent abstraction layers that are dealtwith in the same way thus presenting the design process asan iterative refinement This last point dictates how to moveacross abstraction layers it is an important part of design spaceexploration and offers a way of performing optimization acrosslayers In this respect PBD supports multiple viewpoints in ageneral way
B Complexity of OEM-Supplier Chains Standardization andHarmonization
So far the main answer to the complexity of OEM-supplierchains has been standardization Standardization concerns boththe design entities and the design processes particularlythrough the mechanism of certification
1) Standardization of design entities By agreeing on (do-main specific) standard representations of design entitiesdifferent industrial domains have created their own linguafranca thus enabling a domain wide shared use of designentities based on their standardized representation Exam-ples of these standards in the automotive sector include therecently approved requirement interchange format standardRIF10 the AUTOSAR11 de-facto standard the OSEK12 operat-ing system standard standardized bus-systems such as CAN13
and Flexray14 standards for ldquocar2Xrdquo communication andstandardized representations of test supported by ASAM15Examples in the aerospace domain include ARINC stan-dards16 such as the avionics applications standard interfaceIMA RTCA17 communication standards In the automationdomain standards for interconnection of automation devicessuch as Profibus18 are complemented by standardized designlanguages for application development such as Structured Text
As standardization moves from hardware to operating sys-tem to applications and thus crosses multiple design layersthe challenge increases to incorporate all facets of designentities required to optimize the overall product while atthe same time enabling distributed development in complex
10httpwwww3org2005ruleswikiRIF_Working_Group11httpwwwautosarorg12httpwwwosek-vdxorg13httpwwwisoorgisosearchhtmqt=Controller+Area+
NetworkampsearchSubmit=Searchampsort=relamptype=simpleamppublished=true14httpwwwflexraycom15httpwwwasamnet16httpwwwaeec-amc-fsemccomstandardsindexhtml17httpwwwrtcaorg18httpwwwprofibuscom
RR ndeg 8147
Contracts for System Design 14
supply chains As an example to address the different view-points required to optimize the overall product AUTOSARextended in transitioning from release 31 to 4 its capabilityto capture timing characteristics of design entities a keyprerequisite for assessing alternate deployments with respectto their impact on timing More generally the need for overallsystem optimization calls for the standardization of all non-functional viewpoints of design entities an objective yet tobe achieved in its full generality in order to allow crosslayer optimization Within the EDA domain such richnessof design interface specifications is industrial practice Withinthe systems domain the rich component model introduced inthe Integrated Projects SPEEDS tackles this key objective incovering multiple design layers (from product requirements todeployment on target architectures) and in providing means ofassociating multiple viewpoints with each design entity it isexpressive enough to allow for cross-supply chain optimizationof product developments This approach is further elaboratedand driven towards standardization in the Artemis flagshipproject CESAR
2) Harmonization of processes and certification Harmo-nizing or even standardizing key processes (such as devel-opment processes and safety processes) provides for a fur-ther level of optimization in interactions across the supplychain As an example Airbus Directives and Procedures(ADBs) provide requirements for design processes of equip-ment manufactures Often harmonized processes across thesupply chain build on agreed maturity gates with incrementalacceptance testing to monitor progress of supplier developmenttowards final acceptance often building on incremental proto-types Shared use of Product Lifcycle Management (PLM)19
databases across the supply chain offers further potentialsfor cross-supply chain optimization of development processesAlso in domains developing safety related systems domainspecific standards clearly define the responsibilities and dutiesof companies across the supply chain to demonstrate func-tional safety such as in the ISO 2626220 for the automotivedomain IEC 6150821 for automation its derivatives CenelecEN 50128 and 5012622 for rail and Do 178 B23 for civilavionics
Yet the challenge in defining standards rests in balancingthe need for stability with the need of not blocking processinnovations As an example means for compositional con-struction of safety cases are seen as mandatory to reducecertification costs in the aerospace and rail domains Similarlythe potential of using formal verification techniques to copewith increasing system complexity is considered in the movefrom DO 178 B to DO 178 C standards
19See [162] and also footnote 420httpwwwisoorgisocatalogue_detailhtmcsnumber=4346421httpwwwiecchfunctionalsafety22httpwwwceneleceuCenelecCENELEC+in+actionWeb+Store
Standardsdefaulthtm23httpwwwdo178sitecom
C Managing Requirements Traceability and Multiple View-points
Depending on application domains up to 50 of all er-rors result from imprecise incomplete or inconsistent andthus unfeasible requirements Requirements are inherently illstructured They must address all aspects of the system andthus cannot be constrained by the lingua franca of a partic-ular domain They are fragmented in the form of large andsometimes huge DOORS files24 structured into viewpointsTwo issues have thus been identified by systems industries asessential for requirement management powerful and flexibletraceability tools to relate requirements between them and tolink them to tests for validation purposes and the developmentof domain specific ontologies as part of the PLM suiteFurther based on an assessment by the system companiesprocesses in the CESAR project25 and the German EmbeddedSystems Innovation alliance26 and building on the finding ofthe Integrated Project SPEEDS27 multiple viewpoints havebeen categorized into perspectives and aspects to provide asolid requirement and property modeling scaffold Perspectivesare viewpoints relevant to architecture modeling as carriedout by different stake-holders during the development processAspects are viewpoints that are orthogonal to the systemstructure Aspects are used to demonstrate compliance of thearchitecture to end-user concerns Example of aspects aresafety cost maintainability performance and weight Themeta-model underlying the CESAR RTP is able to maintainlinks such as the satisfy derive verify refine and allocaterelationships between design artifacts of different perspectivesand across abstraction layers
In addition to cope with the inherently unstructured prob-lem of (in)completeness of requirements industry has setup domain- and application-class specific methodologies Asparticular examples we mention learning process such asemployed by Airbus to incorporate the knowledge base ofexternal hazards from flight incidents the Code of Practiceproposed by the Prevent Project28 using guiding questions toassess the completeness of requirements in the concept phaseof the development of advanced driver assistance systemsUse-case analysis methods as advocated for UML baseddevelopment process follow the same objective All togetherrequirement engineering misses the support of formal ap-proaches for its structuring and analysis
D Cross-company Shared Risk Management
The realization of complex systems calls for design pro-cesses that mitigate risks in highly concurrent distributedand typically multi-domain engineering processes often in-volving more than one hundred sub-processes Risk mitigation
24Typical sub-systems in aeronautics would have a few thousands top-levelrequirements An aircraft can have up to several hundred thousands of them
25wwwcesarprojecteu26httpspes2020informatiktu-muenchende27httpwwwspeedseucom28Albert http
RR ndeg 8147
Contracts for System Design 15
measures typically cover all phases of design processes rang-ing from ensuring high quality initial requirements to earlyassessments of risks in realizability of product requirementsduring the concept phase to enforcing complete traceabilityof such requirements with requirements management tools tomanaging consistency and synchronization across concurrentsub-processes using PLM tools A key challenge rests inbalancing risk reduction versus development time and effortcompletely eliminating the risks stemming from concurrentengineering essentially requires a complete synchronizationalong a fine-grained milestone structure which would kill anydevelopment project due to the induced delays Another keychallenge is the ldquonot my faultrdquo syndrome in the OEM-supplierchain when errors call for costly re-design and the issue ofpenalties arises Properly assigning responsibilities to risks isstill out of reach today
E The Need for Contracts
The way system design challenges have been addressed sofar leaves huge opportunities for improvements by relying oncontract-based design In this section we briefly summarizefor each existing approach to address the design challengeshow contracts could improve the current situation
Contribution 1 Addressing Complexity of Systems andSystem-wide OptimizationWhile layered design (Section III-A1) and component baseddesign (Section III-A2) have been critical steps in breakingsystems complexity they do not by themselves provide theultimate answer When design is being performed at a consid-ered layer implicit assumptions regarding other layers (egcomputing resources) are typically invoked by the designerwithout having these explicated Hence actual properties ofthese other layers cannot be confronted against these hiddenassumptions Similarly when components or sub-systems areabstracted via their interfaces in component based design itis generally not true that such interfaces provide sufficientinformation for other components to be safely implementedbased on this sole interface Contract-based design providesthe due discipline concepts and techniques to cope with thesedifficulties
Model-based development (Section III-A4) has reached sig-nificant maturity by covering nearly all aspects of the system(physics functions computing resources) albeit not yet in afully integrated way To offer a real added value any newlyproposed technology should be rich enough for encompassingall these aspects as well Contract-based design offers in largepart this desirable feature
Virtual integration and virtual modeling (Section III-A5) isa step beyond basic model-based development by offering anintegrated view of all the above different aspects eg physics+ functions + performances Contract-based design supportsthe fusion of different systems aspects
Contract-based design is compliant with the V-model pro-cess (Section III-A3) just because it does not impose anyparticular design process Using contracts only imposes a
small set of rules that any process should accommodate seeSection IV-D for a discussion of this
Finally Platform-Based Design (PBD Section III-A6)which is being deployed in some large systems industries suchas United Technologies Corporation (UTC) is a systematicand comprehensive methodology that unifies the various de-sign methodologies that have been described in this sectionContracts offer theory and methodological support for boththe successive refinement aspect the composition aspect andthe mapping process of PBD allowing formal analysis andsynthesis processes
Contribution 2 Addressing the Complexity of OEM-Supplier ChainsThe problems raised by the complexity of OEM-SupplierChains (Section II-B) are indeed the core target of contract-based design By making the explication of implicit assump-tions mandatory contracts help assigning responsibilities toa precise stake holder for each design entity By supportingindependent development of the different sub-systems whileguaranteing smooth system integration they orthogonalize thedevelopment of complex systems Contracts are thus adequatecandidates for a technical counterpart of the legal bindingsbetween partners involved in the distributed and concurrentdevelopment of a system
Contribution 3 Managing RequirementsSo far the task of getting requirements right and managingthem well (Section III-C) has only got support for sortingthe complexity out (traceability services and ontologies whichis undoubtely necessary) However requirements can only betested on implementations and it is not clear whether properdistinctions are made when performing tests regarding thefollowing fusing the results of tests associated to differentchapters or viewpoints of a requirement document versusfusing the results of tests associated to different sub-systemstesting a requirement under the responsibility of the designerof the considered sub-system versus testing a requirementcorresponding to an assumption regarding the context of useof this sub-systemmdashsuch distinctions should be made as weshall see Also requirements are barely executable and cannotin general be simulated Requirements engineering is the otherprimary target of contract-based design the above issues areproperly handled by contracts and contracts offer improvedsupport for evidencing the satisfaction of certification con-straints
Contribution 4 Managing RisksRisk metrics and risk mitigation measures are the essentialtools in managing risks (Section III-D) By offering improvedsupport for sub-contracting and distributing design to differentteams contracts are likely to significantly reduce the ldquonot myfaultrdquo syndrome
Contribution 5 Addressing CertificationAs explained in Section III-B2 the design of critical sys-tems is subject to a number of certification standards Whilecertification steps are mostly concerned with the processesnot the designs themselves the recent move from DO 178Bto DO 178C for level A critical systems in aeronautics has
RR ndeg 8147
Contracts for System Design 16
shown for the first time the consideration of formal proofsor validations as valid evidences We believe that the samewill eventually hold for contracts In particular by providingadequate formal support for completeness consistency com-patibility and more for sets of requirements contracts wouldprovide a valuable contribution to certification
IV CONTRACTS WHAT WHY WHERE AND HOWAs we argued in the previous section there are two basic
principles followed by design methods so far developed ab-stractionrefinement and compositiondecomposition Abstrac-tion and refinement are processes that relate to the flow of de-sign between different layers of abstraction (vertical process)while composition and decomposition operate at the same levelof abstraction (horizontal process) In this section we presentbriefly contracts and the basic operations they support andthen me make the point that contracts are ideal tools to solidifyboth vertical and horizontal processes providing the theoreticalbackground to support formal methods We conclude thesection by providing a (non exhaustive) bibliography on thegeneral concept of contract
A Contracts
Here we propose a ldquoprimerrdquo on contracts using a simpleexample as the reference for their use
1) Components and their Environment Contracts We startfrom a model that consists of a universal set M of com-ponents each denoted by the symbol M A component Mis typically an open system ie it contains some inputsthat are provided by other components in the system or theexternal world and it generates some outputs This collectionof other components and the exterior world is referred to as theenvironment of the component The environment is often notcompletely known when the component is being developedAlthough components cannot constrain their environment theyare designed to be used in a particular context
In the following example we define a component M1 thatcomputes the division between two real inputs x and y andreturns the result through the real output z The underlyingassumption is that M1 will be used within a design contextthat prevents the environment from giving the input y = 0Since M1 cannot constrain its input variables we handle theexceptional input y = 0 by generating an arbitrary output
M1
variables
inputs x y
outputs z
types x y z isin Rbehaviors (y 6= 0rarr z = xy) and (y = 0rarr z = 0)
A contract contract denoted by the symbol C is a de-scription of a component with the following characteristicproperties
1) Contracts are intentionally abstract2) Contracts distinguish responsibilities of a component
from that of its environmentProperty 1) of a contract highlights the goal of handlingcomplexity of the systems Thus contracts expose enough
information about the component but not more than necessaryfor the intended purpose We can see a contract as an under-specified description of a component that can be either veryclose to the actual component or specify only a singleproperty of a componentrsquos behavior Regarding Property 2)and in contrast to components a contract explicitly makes adistinction between assumptions made about the environmentand guarantees provided mirroring different roles and respon-sibilities in the design of systems
A contract can be implemented by a number of differentcomponents and can operate in a number of different envi-ronments Hence we define a contract C at its most abstractlevel as a pair C = (EC MC ) of subsets of components thatimplement the contract and of subsets of environments inwhich the contract can operate We say that a contract C isconsistent if MC 6= empty and compatible if EC 6= empty
This definition of contracts and the implementation relationis very general and as such it is not effective In concretecontract- based design theories a contract needs to have afinite description that does not directly refer to the actualcomponents and the implementation relation needs to beeffectively computable and establish the desired link betweena contract and the underlying components that implement it
For our present simple example of static systems wepropose the following way to specify contracts
C1
variables
inputs x y
outputs z
types x y z isin Rassumptions y 6= 0
guarantees z = xy
C1 defines the set of components having as variablesinputs x y output z of type real and whose behaviorssatisfy the implication
ldquoassumptionsrArr guaranteesrdquo
ie for the above example y 6= 0rArr z = xy Intuitivelycontract C1 specifies the intended behavior of components thatimplement division It explicitly makes the assumption that theenvironment will never provide the input y = 0 and leaves thebehavior for that input undefined
This contract describes an infinite number of environmentsin which it can operate namely the set EC1
of environmentsproviding values for x and y with the condition that y 6=0 Itdescribes an infinite number of components that implementthe above specification where the infinity comes from theunderspecified case on how an implementation of C1 shouldcope with the illegal input y = 0 In particular we have thatM1 implements C1 Thus contract C1 is consistent We nowshow a variant of contract C1 that is not consistent
Cprime1
variables
inputs x y
outputs z
types x y z isin Rassumptions T
guarantees z = xyRR ndeg 8147
Contracts for System Design 17
where symbol T denotes the boolean constant ldquotruerdquo Incontrast to C1 the contract Cprime1 makes no assumption on valuesof the input y Hence every component that implements Cprime1has to compute the quotient xy for all values of y includingy = 0 which makes no sense
B Contract Operators
There are three basic contract operators that are used insupport of the design methodologies we presented previouslycomposition refinement and conjunction
1) Contract Composition and System Integration Intu-itively the composition operator supports component-baseddesign and in general horizontal processes The compositionoperator that we denote by the symbol times is a partial functionon components The composition is defined with respect to acomposability criterion where two components M and M prime
are composable if their variable types match Composabilityis a syntactic property on pairs of components that definesconditions under which the two components can interactComposition times must be both associative and commutative inorder to guarantee that different composable components maybe assembled together in any order
Consider the component M2 defined as follows
M2
variables
inputs x
outputs y
types x y isin Rbehaviors y = ex
The component M2 computes the value of the output variabley as the exponential function of the input variable x M1 andM2 are they are composable since both common variables xand y have the same type x is an input variable to both M1
and M2 and the output variable y of M2 is fed as an input toM1 It follows that their composition M1 timesM2 has a singleinput variable x and computes the output z as a function ofx that is z = xex
Now consider component M prime2 that consists of an inputvariable x and an output variable z both of type real wherez = abs(x)
M prime2
variables
inputs x
outputs z
types x z isin Rbehaviors z = abs(x)
The component M prime2 is not composable with M1 becausethe two components share the same output variable z Theircomposition is illegal as it would result in conflicting rulesfor updating z
We now lift the above concepts to contracts The compo-sition operator between two contracts denoted by otimes shallbe a partial function on contracts involving a more subtlecompatibility criterion Two contracts C and Cprime are compatibleif their variable types match and if there exists an environmentin which the two contracts properly interact The resultingcomposition C otimes Cprime should specify through its assumptions
this set of environments By doing so the resulting contractwill expose how it should be used Unlike component com-posability contract compatibility is a combined syntactic andsemantic property
Let us formalize this For C a contract let AC and GC beits assumptions and guarantees and define
GC1otimesC2 = GC1andGC2
AC1otimesC2 = max
A∣∣∣∣∣∣AandGC2rArrAC1andAandGC1rArrAC2
(1)
where ldquomaxrdquo refers to the order of predicates by implica-tion thus AC1otimesC2 is the weakest assumption such that thetwo referred implications hold Thus this overall assumptionwill ensure that when put in the context of a componentimplementing the second contract then the assumption ofthe first contract will be met and vice-versa Since the twoassumptions were ensuring consistency for each contract theoverall assumption will ensure that the resulting compositionis consistent This definition of the contract compositiontherefore meets our previously stated requirements The twocontracts C1 and C2 are called compatible if the assumptioncomputed as in (1) differs from F the ldquo falserdquo predicate
Consider contracts C2 and Cprime2 that we define as follows
C2
variables
inputs u
outputs x
types u x isin Rassumptions T
guarantees x gt u
Cprime2
variables
inputs v
outputs y
types v y isin Rassumptions T
guarantees y = minusv
C2 specifies components that for any input value u generatesome output x such that x gt u and Cprime2 specifies componentsthat generate the value of the output variable y as functiony = minusv of the input v Observe that both C2 and Cprime2 areconsistent A simple inspection shows that C1 and C2 can becomposed and their composition yields
C1 otimes C2
variables
inputs u y
outputs x z
types x y u z isin Rassumptions y 6= 0
guarantees x gt u and z = xy
C1 and Cprime2 can also be composed and their composition yields
C1 otimes Cprime2
variables
inputs v x
outputs y z
types v x y z isin Rassumptions v 6= 0
guarantees y = minusv and z = xyRR ndeg 8147
Contracts for System Design 18
Both compositions possess a non-empty assumption (observealso that they are both free of exception) reflecting that thetwo pairs (C1 C2) and (C1 Cprime2) are compatible
In our example we require that compositions C1otimes(C2otimesC3)and (C1 otimes C2) otimes C3 result in equivalent contracts as well ascompositions C1otimesC2 and C2otimesC1 thus providing support forincremental system integration
A quotient operation can be defined that is dual to thecomposition operation Given a system-wide contract C anda contract C1 that specifies pre-existing components and theirinteractions the quotient operation CC1 defines the part ofthe system-wide contract that still needs to be implementedIt formalizes the practice of ldquopatchingrdquo a design to make itbehave according to another contract
2) Contract Refinement and Independent DevelopmentIn all vertical design processes the notions of abstractionand refinement play a central role The concept of contractrefinement must ensure the following if contract Cprime refinescontract C then any implementation of Cprime should 1) implementC and 2) be able to operate in any environment for C Hencethe following definition for refinement pre-order betweencontracts we say that the contract Cprime refines the contract C ifECprime supe EC andMCprime subeMC Since is a pre-order refinementis a transitive relation For our current series of examples andusing previous notations Cprime C amounts to requiring that 1AC implies ACprime and 2 ACprimerArrGCprime implies ACrArrGC
In Figure 4 we start with the contract C1 that representsthe general system-wide requirements We decompose theserequirements into requirements of three subsystems resultingin three contracts C11 C12 and C13 with the property thatC11otimesC12otimesC13 C1 Now these three contracts can be handedto different design teams and refined further independentlyIn particular C12 is further decomposed into contracts C121
and C122 such that C121 otimes C122 C12 and similarly C13 isfurther decomposed into contracts C131 and C132 such thatC131 otimes C132 C13
For all contracts C1 C2 Cprime1 and Cprime2 if C1 is compatible withC2 and Cprime1 C1 and Cprime2 C2 then Cprime1 is compatible with Cprime2and Cprime1 otimes Cprime2 C1 otimes C2
We now give a concrete example where we start withvery abstract requirements for a component that implementsa function z = xex Consider contracts Cprimeprime1 and Cprimeprime2 that wedefine as follows
Cprimeprime1
variables
inputs y
outputs z
types y z isin Rassumptions y 6= 0
guarantees z isin R
Cprimeprime2
variables
inputs x
outputs y
types x y isin Rassumptions T
guarantees y gt 0
The contract Cprimeprime1 formalizes the most crude and abstractrequirements for a divider It requires that the denominatorvalue (input variable y) is not equal to 0 and only ensuresthat the output value of z is any real Note that the contractCprimeprime1 does not declare the nominator input variable x Thecontract Cprimeprime2 specifies components that have an input variablex and an output variable of type y The only requirement onthe behavior of Cprimeprime2 is that y is strictly greater than 0 Thecomposition Cprimeprime1 otimes Cprimeprime2 is well defined The contract C1 refinesCprimeprime1 since it allows more inputs (the nominator input variable x)and restricts the behavior of the output variable z by definingits behavior as the division xy It follows that C1 is alsocompatible with Cprimeprime2 and that C1 otimes Cprimeprime2 Cprimeprime1 otimes Cprimeprime2 Finally wehave that M1 and M2 are implementations of their respectivecontracts It follows that M1 timesM2 implements C1 otimes Cprimeprime2
3) Contract Conjunction and Viewpoint Fusion We nowintroduce the conjunction operator between contracts denotedby the symbol and Conjunction is complementary to composi-tion
1) In the early stages of design the system-level speci-fication consists of a requirements document that is aconjunction of requirements
2) Full specification of a component can be a conjunctionof multiple viewpoints each covering a specific (func-tional timing safety etc) aspect of the intended designand specified by an individual contract see Figure 4 foran illustration
3) Conjunction supports reuse of a component in differentparts of a design see Figure 5 for an illustration
We state the desired properties of the conjunction operatoras follows Let C1 and C2 be two contracts If C1 and C2 areshared refinable then C1 andC2 C1 and C1 andC2 C2 and forall contracts C if C C1 and C C2 then C C1 and C2
To illustrate the conjunction operator we consider a contractCT1 that specifies the timing behavior associated with C1 Forthis contract we introduce additional ports that allow us tospecify the arrival time of each signal
CT1
variables
inputs tx ty
outputs tz
types tx ty tz isin R+
assumptions Tguarantees tzlemax(tx ty) + 1
The contract CT1 is shared refinable with C1 Their conjunctionC1 and CT1 yields a contract that guarantees in addition to C1itself a latency with bound 1 (say in ms) for it Becausethere are no assumptions this timing contract specifies thesame latency bound also for handling the illegal input y = 0In fact the contract says more because it does not mentionthe input y it assumes any value of y is acceptable Asa result the conjunction inherits the weakest T assumptionof the timing contract and cancels the assumption of C1This however is clearly not the intent since the timingcontract is not concerned with the values of the signals andis a manifestation of the weakness of this simple contract
RR ndeg 8147
Contracts for System Design 19
framework in dealing with contracts with different alphabetsof ports and variables We will further explain this aspect andshow how to address this problem in Section VII For themoment we can temporarily fix the problem by introducing yin the interface of the contract and use it in the assumptionsas in the following contract CT2
CT2
variables
inputs y tx ty
outputs tz
types y isin R tx ty tz isin R+
assumptions y 6=0guarantees tzlemax(tx ty) + 1
Note that this timing contract does not specify any bound forhandling the illegal input y = 0 since the promise is notenforced outside the assumptions
So far this example was extremely simple In particularit was stateless Extension of this kind of AssumeGuaranteecontracts to stateful contracts will be indeed fully developedin the coming sections and particularly in Section VII
C Contracts in requirement engineering
In this section we introduce a motivating example that isrepresentative of early requirements capturemdashthe specificationof a parking garage Its full development requires technicalmaterial that we introduce later and we thus defer it toSection XI This example illustrates the following features ofcontract based requirements capture namelybull Top-level system specification is by writing a require-
ments document Different formalisms may be used fordifferent kinds of requirements Here we illustrate thisby blending textual requirements written in constrainedEnglish (possibly obtained using boilerplates) with smallsized automata
bull The document itself is structured into chapters describingvarious aspects of the system such as how gates shouldbehave how payment should proceed plus some overallrules
bull Some requirements are under the responsibility of thesystem under development they contribute to specifyingthe guarantees that the system offers Other requirementsare not under the responsibility of the system underdevelopment they contribute to defining the assumptionsregarding the context in which the system should operateas specified
bull Requirements are written in constrained English languageor by using automata
We now begin with the top-level requirements The systemunder specification is a parking garage subject to paymentby the user At its most abstract level the requirementsdocument comprises the different chapters gate payment andsupervisor see Table III The gate chapter will collect thegeneric requirements regarding entry and exit gates Thesegeneric requirements will then be specialized for entry andexit gates respectively
Focus on the ldquogaterdquo chapter It consists of the three require-ments shown on Table III Requirement Rg1 is best described
gateRg1ldquovehicles shall not pass when gate is closedrdquo see Fig 7Rg2 after vehicle_pass vehicle_pass is forbiddenRg3 after gate_open gate_open is forbidden and
after gate_close gate_close is forbiddenpaymentsupervisor
Table IIITHE TOP-LEVEL SPECIFICATION WITH CHAPTER gate EXPANDED
REQUIREMENTS WRITTEN IN italics ARE ASSUMPTIONS UNDER WHICHgate SHOULD OPERATE
0
gate_close
1gate_opengate_close
vehicle_passgate_open
Figure 1 Requirement Rg1 specified as an io-automaton Prefix ldquordquoindicates an input and prefix ldquordquo indicates an output
by means of an io-automaton shown in Figure 1mdashwe providean informal textual explanation for it between quotes Supposethat some requirement says ldquogate_open never occursrdquo Thisis translated by having no mention of gate_open in thecorresponding io-automaton To express this ldquonegativerdquo factwe must keep track of the fact that gate_open belongs tothe alphabet of actions of the io-automaton Thus when per-forming the translation the explicit list of inputs and outputsshould be explicitly given To avoid such additional notationalburden we have cheated by omitting this unless necessaryThe other two requirements are written using constrainednatural language which can be seen as a boilerplate styleof specification Prefix ldquordquo indicates an input and prefix ldquordquoindicates an output
The first two requirements are not under the responsibilityof the system since they rather concern the car driver Thus itdoes not make sense to include them as part of the guaranteesoffered by the system Should we remove them This wouldbe problematic If drivers behave the wrong way unexpectedthings can occur for sure The conclusion is that 1) we shouldkeep requirements Rg1 and Rg2 and 2) we should handlethem differently than Rg3 which is a guarantee offered by thesystem Indeed Rg1 and Rg2 are assumptions under whichthe gate operates as guaranteed We take the convention thatassumptions are written in italics
So far we have specified gate as a list of requirementsRequirement Rg1 specified as an io-automaton can be con-sidered formal Requirements Rg2 and Rg3 are formulatedin constrained natural language and are ready for subsequentformalization eg as io-automata Are we done Not yetWe need to give a formal meaning to what it means to havea collection of requirements and what it means to distinguishassumptions from guarantees Similarly we must give a formalmeaning to what it means to combine different chapters of arequirements document Intuitively all requirements must be
RR ndeg 8147
Contracts for System Design 20
met for a chapter to be satisfied and similarly all chaptersmust be satisfied for the whole specification to be correctlyimplemented Thus we propose to write the top-level specifi-cation C as the following conjunction
C = Cgate and Cpayment and Csupervisor
As we said formally defining what conjunction and is requirestechnical material that is developed later in this paper Thefollowing issues arise regarding this top-level specificationFirst of all since a conjunction operator is involved in theconstruction of C there is a risk of formulating contradictingrequirementsmdashthis is referred to as the issue of consistencySecond are we sure that the top-level specification C iscomplete ie precise enough to rule out undesirable imple-mentations One good way of checking for completeness is tobe able to execute or simulate this top-level specification CWe provide answers to all these issues in Section XI wherethis example is fully developed
request enter
ticket issue
entry gate open
entry gate closeEntryGate
vehicle enter
vehicle exit
exit ticket insert ExitGateexit gate open
exit gate close
ticket insert payment
coin insert paymentPaymentMachine exit ticket issue
Figure 2 System architecture as specified by the designer
Having the top-level specification C at hand the designerthen specifies an architecture ldquoagrave la SysMLrdquo as shown onFigure 2 Some comments are in order regarding this archi-tecture The considered instance of a parking garage consistsof one entry gate one exit gate and one payment machineCompare with the top-level specification of Table III Thelatter comprises a generic gate a payment machine and asupervisor each one with its set of requirements In contrastthe architecture of Figure 2 involves no supervisor Thesupervisor is meant to be distributed among the two gatesThe architecture of Figure 2 seems to be very loosely coupledFirst the PaymentMachine seems to be totally independent Infact the ticket that is inserted in the exit gate must coincidewith the one issued by the PaymentMachine It turns out thatthis reflects a missing assumption regarding the environmentof the system (namely the user of the parking) Then thetwo gates seem to have the shared input ldquovehicle exitrdquo astheir only interaction But this shared input is involved in
requirement Rs3 which forbids the entry if the parking isfull
The next step in the design consists in subcontractingthe development of each of the three sub-systems of thearchitecture of Figure 2 This amounts to specifying threesubcontracts CEntryGate CExitGate and CPaymentMachinesuch that
CEntryGate otimes CExitGate otimes CPaymentMachine C (2)
The symbol in (2) means that any implementation of theleft hand side is also a valid implementation of the top-level C Then the contract composition operator otimes ensuresthat each supplier can develop its sub-system based on itsown sub-contract only and still integrating the so designedsub-systems yields a correct implementation of the top-levelspecification Once the three sub-contracts are found checkingthat they satisfy (2) requires formalizing the contract compo-sition operator otimes Furthermore guessing such sub-contractsis a difficult task In our development of this example inSection XI we propose adequate answers to these issues
D Contract Support for Design Methodologies
The three operators introduced above fit naturally in anydesign methodology developed so far In particular contractcomposition and conjunction supports horizontal processesand contract refinement supports vertical processes We showhow this is so by first analyzing the use of contract conjunc-tion for requirement management then of composition andrefinement for design chain management re-use and indepen-dent development to close with conjunction composition andrefinement for deployment and mapping
1) Supporting open systems When designing componentsfor reuse their context of use is not fully known in advanceWe thus need a specification of components exposing boththe guarantees offered by the component and the assumptionson its possible context of usemdashits ldquoenvironmentrdquo This stateswhat contracts should be
2) Managing Requirements and Fusing Viewpoints Re-ferring to Section III-C complex systems involve a numberof viewpoints (or aspects) that are generally developed bydifferent teams using different skills As a result there is aneed for fusing these viewpoints in a mathematically soundway Structuring requirements or specifications is a desirableobjective at each step of the design Finally we must formal-ize some key properties that must be evidenced as part ofcertification processes
This process is illustrated in Figure 3 In this figure weshow three viewpoints the behavioral viewpoint where thefunctions are specified the timing viewpoint where timingbudgets are allocated to the different activities and the safetyviewpoint where fault propagation effect and handling arespecified Typically different viewpoints are developed bydifferent teams using different frameworks and tools Devel-opment of each viewpoint is performed under assumptionsregarding its context of use including the other viewpoints To
RR ndeg 8147
Contracts for System Design 21
VIEWPOINT VIEWPOINT VIEWPOINTBEHAVIORAL TIMING SAFETY
is a conjunctionevery contract
C =and
i Ci
CB1 CB2 CT CS1 CS2
CB1 and CB2 and CT and CS1 and CS2
Figure 3 Conjunction of requirements and viewpoints in top-level design
get the full system specification the different viewpoints mustbe fused As the notations of Figure 3 suggest conjunctionis used for fusing viewpoints thus reflecting that the systemunder design must satisfy all viewpoints Similarly eachviewpoint is itself a conjunction of requirements seen as theldquoatomicrdquo contractsmdashall requirements must be met
3) Design Chain Management Re-using and IndependentDevelopment In Figure 4 we show three successive stages ofthe design At the top level sits the overall system specificationas developed by the OEM As an example it can be obtained asthe conjunction of several viewpoints as illustrated on Figure 3
is delegated forimplementation by a supplier
is delegated forimplementation by a supplier
C11 otimes (C121 otimes C122)otimes (C131 otimes C132)
C11
C12
C13
C11
C121 C122 C131 C132
C121 otimes C122 C131 otimes C132
C11 otimes C12 otimes C13
C1
is refined by the OEM
Figure 4 Stepwise refinement
As a first design step the OEM decomposes its system intoan architecture made of three sub-systems for independentdevelopment by (possibly different) suppliers For each ofthese sub-systems a contract C1j j = 1 2 3 is developedA contract composition denoted by the symbol ldquootimesrdquo
C11 otimes C12 otimes C13
mirrors the composition of sub-systems that defines the archi-tecture For our method to support independent development
this contract composition operator must satisfy the following
if designs are independently performed for eachsub-contract C1j j = 1 2 3 then integratingthese sub-systems yields an implementation thatsatisfies the composed contract C11 otimes C12 otimes C13
(3)
This contract composition must then be qualified against thetop-level contract C1 This qualification must ensure that anydevelopment compliant with C11 otimes C12 otimes C13 should alsocomply with C1 To ensure substitutability in any legal contextcompliance concerns both how the system behaves and whatits allowed contexts of use are any legal context for C1 shouldbe also legal for C11otimesC12otimesC13 and under any legal contextthe integrated system should behave as specified by C1 This isformalized as the refinement relation denoted by the symbol
C11 otimes C12 otimes C13 C1 (4)
Overall the satisfaction of (4) guarantees the correctness ofthis first design step performed by the OEM
Obtaining the three sub-contracts C11 C12 and C13 is the artof the designer based on architectural considerations Contracttheories however offer the following services to the designerbull The formalization of parallel composition and refinement
for contracts allows the designer to firmly assess whether(4) holds for the decomposition step or not
bull In passing the compatibility of the three sub-contractsC11 C12 and C13 can be formally checked
bull Using contracts as a mean to communicate specificationsto suppliers guarantees that the information provided tothe supplier is self-contained the supplier has all theneeded information to develop its sub-system in a waythat subsequent system integration will be correct
Each supplier can then proceed with the independent devel-opment of the sub-system it is responsible for For instance asupplier may reproduce the above procedure
Alternatively this supplier can develop some sub-systemsby reusing off-the-shelf components For example contractC121 would be checked against the interface specification of apre-defined component M121 available from a library and thefollowing would have to be verified does component M121
satisfy C121 In this context shared implementations are ofinterest This is illustrated on Figure 5 where the same off-the-shelf component implements the two referred contracts
To conclude on this analysis the two notions of refinementdenoted by the symbol ldquordquo and composition of contractsdenoted by the symbol ldquootimesrdquo are key Condition (3) ensuresindependent development holds
4) Deployment and Mapping Here we address a specificbut important point related to Contribution 1 At some pointin the design of the system specifications must be realized byusing resources Resources can be pre-defined sub-systems orcomponents or they can consist of computing resources com-prising computing units and communication media (networksbusses and protocols) This methodology was advocated and
RR ndeg 8147
Contracts for System Design 22
C11
C121 C122 C131 C132
C11 otimes (C121 otimes C122)otimes (C131 otimes C132)
C121 otimes C122 C131 otimes C132
C122 and C132
Figure 5 Conjunction for component reuse
systematically exploited in Platform Based Design [171] orPLM-centric design see footnote 4 in Section II How sucha step can be captured in contract based design is explainednext
When deploying an application over a computing plat-form in addition to the functional viewpoint non-functionalviewpoints (safety timing energy and possibly other) areof importance as well The safety viewpoint is concernedwith the risk of primary faults and failures how they couldpropagate throughout the system and what the consequencesfor the resilience of the overall system would be in termsof failure probability The timing viewpoint collects timingrequirements regarding the application (requirements on la-tencies throughput jitter and schedulability) The effectivesatisfaction of safety or timing viewpoints by a considereddeployment depends on 1) the supporting execution platformand 2) the mapping of the application to this executionplatform We thus need to formalize what ldquomappingrdquo meansThe reader is referred to Figure 6 for the following discussion
M4M3
M5M6
M1
M2
M3
M1
M4
M2
M5
M6x34
xd63 xo
63
x34
C2 C1
C3
P
C
xo63
xd63
Figure 6 Mapping the application to the execution platform as C and P
Suppose one has a virtual model of the execution platform
as an architecture composed of several components Suchcomponents would in the context of Figure 6 consist of adescription of the available computing units a descriptionof the bus protocol and frame structure andor a library ofRTOS (Real-Time Operating System) services The resultingcomponents are enhanced with timing information (for thetiming viewpoint) and fault propagation information (for thesafety viewpoint) Application contracts are attached to thedifferent sub-systems or components as described on the toppart of the figure Similarly platform contracts are attachedto the different sub-systems or components of the executionplatform as described on the bottom part of the figureAccordingly we assume
C =andk
(otimesiisinIk Cik
)P =
otimesjisinJ
(and`isinLj
Pj`)
where
bull The overall platform contract P decomposes asotimes
jisinJ Pj(eg the bus and the different computing units inFigure 6) where each Pj is the conjunction of its differentviewpoints (the function what can be computed and theassociated performance how much time it takes and howmuch energy it consumes)
bull The overall application contract is the conjunction ofits different viewpoints Ci with their own architecturaldecomposition
In Figure 6 we only show a single viewpoint29 and we assumethat distant communication between C2 and C3 has alreadybeen refined to a communication medium compliant with thecommunication resources offered by the execution platform
The mapping of the application over the architecture ismodeled by the conjunction CandP defined by the following setof synchronization tuples30 depicted in red in the Figure 6
bull The wire x34 linking M3 to M4 in the application issynchronized in the deployment P with the variablex34 of the left computing unit where x34 represents theoutput of the module implementing M3 and the input ofthe module implementing M4 And similarly for the wirelinking M5 to M6
bull In the deployment the wire x63 linking M6 to M3
must traverse the bus To capture this we first refinethe application architecture by distinguishing the originxo63 of this wire from its destination xd63 In the refinedapplication architecture we assume that xo63 and xd63 arerelated by some buffer of bounded size The deploymentis then captured by synchronizing xo63 with the output xo63
of the module implementing M6 in the right computingunit and by synchronizing xd63 with the input xd63 of themodule implementing M3 in the left computing unit
29Here we assume that the different application viewpoints are developedfor the whole application and then combined by conjunctionmdashthis is just amethodological proposal we could proceed differently
30In in a synchronization tuple both occurrences and values of the differentelements are unified
RR ndeg 8147
Contracts for System Design 23
This formalizes the deployment as the conjunction
C and P =[and
k
(otimesiisinIk Cik
) ]and [otimesjisinJ(and
`isinLjPj`) ]
ensuring that C and P refines C by construction There ishowever no free lunch The formula C and P expressing de-ployment involves a conjunction and is as such a possiblesource of inconsistencies If this happens then C and P cannotbe implemented Finding an execution platform P causingno inconsistency in C and P requires a good understanding ofthe application and its needs The more advanced techniquesdeveloped in Section XI provide assistance for this
Since C and P relates application and computing platformmdashwhich sit at different layers of the designmdashwe call suchcontracts vertical contracts Contracts that are not vertical aresometimes called horizontal in that they are meant to relatecomponents sitting at a same level of the design hierarchymdashapplication level or computing platform level or ECU (Elec-tronic Computing Unit) level
Techniques of mapping application to its execution platformthat are similar to the above one are used in the RT-Buildertool 31 and in the Metropolis platform [20] [80]
E Bibliographical note
Having collected the ldquorequirementsrdquo on contract theories itis now timely to confront these to the previous work referringto or related to the term ldquocontractrdquo
It is difficult to write a comprehensive bibliography onthe general aspects of contract based design The topic ismulti faceted and has been addressed by several communitiessoftware engineering language design system engineeringand formal methods in a broad sense We report here a partialand limited overview of how this paradigm has been tackledin these different communities While we do not claim beingexhaustive we hope that the reader will find her way to thedifferent literatures
Contracts in SW engineering This part of the biblio-graphical note was inspired by the report [168] Design byContract is a software engineering technique popularized byBertrand Meyer [139] [140] following earlier ideas fromFloyd-Hoare logic [169] [113] Floyd-Hoare logic assignsmeaning to sequential imperative programs in the form oftriples of assertions PCQ consisting of a preconditionon program states and inputs a command and a postcondi-tion on program states and outputs Meyerrsquos contracts weredeveloped for Object-Oriented programming They exposethe relationships between systems in terms of preconditionsand postconditions on operations and invariants on states Acontract on an operation asserts that given a state and inputswhich satisfy the precondition the operation will terminatein a state and will return a result that satisfy the postcondi-tion and respects any required invariant properties Contractscontribute to system substitutability Systems may be replacedby alternative systems or assemblies that offer the same or
31httpwwwgeensoftcomenarticlertbuilder
substitutable functionality with weaker or equivalent precon-ditions and strongerequivalent postconditions With the aimof addressing service oriented architectures Meyerrsquos contractswere proposed a multiple layering by Beugnard et al [37]The basic layer specifies operations their inputs outputs andpossible exceptions The behavior layer describes the abstractbehavior of operations in terms of their preconditions andpostconditions The third layer synchronisation correspondsto real-time scheduling of component interaction and messagepassing The fourth quality of service (QoS) level detailsnon-functional aspects of operations The contracts proposedby Beugnard et al are subscribed to prior to service invo-cation and may also be altered at runtime thus extendingthe use of contracts to Systems of Systems [141] So farcontracts consisting of prepostconditions naturally fit imper-ative sequential programming In situations where programsmay operate concurrently interference on shared variablescan occur RelyGuarantee rules [115] were thus added tointerface contracts Rely conditions state assumptions aboutany interference on shared variables during the execution ofoperations by the systemrsquos environment Guarantee conditionsstate obligations of the operation regarding shared variables
The concepts of interface and contract were subse-quently further developed in the Model Driven Engineering(MDE) [120] [172] [131] In this context interfaces aredescribed as part of the system architecture and comprisetyped ports parameters and attributes Contracts on interfacesare typically formulated in terms of constraints on the en-tities of components using the Object Constraint Language(OCL) [150] [180] Roughly speaking an OCL statementrefers to a context for the considered statement and expressesproperties to be satisfied by this context (eg if the context isa class a property might be an attribute) Arithmetic or set-theoretic operations can be used in expressing these propertiesThis method however does not account for functional andextra-functional properties of interfaces ie for behavior andperformance To account for behavior the classical approachin MDE consists in enriching components with methods thatcan be invoked from outside andor state machines Likewiseattributes on port methods have been used to represent non-functional requirements or provisions of a component [51]The effect of a method is made precise by the actual codethat is executed when calling this method The state machinedescription and the methods together provide directly animplementation for the component mdash actually several MDErelated tools such as GME and Rational Rose automaticallygenerate executable code from this specification [21] [132][161] The notion of refinement is replaced by the concept ofclass inheritance From a contract theory point of view thisapproach has several limitations Inheritance for instance isunable to cover aspects related to behavior refinement Noris it made precise what it means to take the conjunctionof interfaces which can only be approximated by multipleinheritance or to compose them
In a continuing effort since his joint work with W Dammon Life Sequence Charts (LSC) in 2000 [64] with its Play-
RR ndeg 8147
Contracts for System Design 24
Engine implementation [107] David Harel has developed theconcept of behavioral programming [108] [106] [109] whichputs in the forefront scenarios as a program developmentparadigmmdashnot just a specification formalism In behavioralprogramming b-threads generate a flow of events via anenhanced publishsubscribe protocol Each b-thread is a pro-cedure that runs in parallel to the other b-threads When ab-thread reaches a point that requires synchronization it waitsuntil all other b-threads reach synchronization points in theirown flow At synchronization points each b-thread specifiesthree sets of events requested events the thread proposes thatthese be considered for triggering and asks to be notifiedwhen any of them occurs waited-for events the thread doesnot request these but asks to be notified when any of themis triggered and blocked events the thread currently forbidstriggering any of these events When all b-threads are at asynchronization point an event is chosen (according to somepolicy) that is requested by at least one b-thread and is notblocked by any b-thread The selected event is then triggeredby resuming all the b-threads that either requested it or arewaiting for it This mechanism was implemented on top ofJava and LSCs The execution engine uses planning and modelchecking techniques to prevent the system from falling intodeadlock where all requested events are blocked Behavioralprogramming is incremental in that new threads can be addedto an existing program without the need for making any changeto this original program new deadlocks that are created bydoing so are pruned away by the execution engine Whilebehavioral programming cannot be seen as a paradigm ofcontracts it shares with contracts the objectives of incrementaldesign and declarative style of specification
Our focusmdashcontracts for systems and CPS The frame-works of contracts developed in the area of Software En-gineering have established as useful paradigms for compo-nent based software system development In this paper wetarget the wider area of computer controlled systems morerecently referred to as Cyber-Physical systems where reactivesystems [104] [110] [100] [136] are encountered that issystems that continuously interact with some environmentas opposed to transformational systems [100] considered inObject-Oriented programming For reactive systems model-based development (MBD) is generally accepted as a keyenabler due to its capabilities to support early validationand virtual system integration MBD-inspired design lan-guages and tools include SysML [149] or AADL [152] forsystem level modeling Modelica [93] for physical systemmodeling Matlab-Simulink [118] for control-law design andScade [144] [32] and TargetLink for detailed software designUML-related standardisation efforts in this area also includethe MARTE UML32 profile for real-time systems Contracttheories for model based development were considered inthe community of formal verification They were initiallydeveloped as specification formalisms able to refuse certaininputs from the environment Dill proposed asynchronous
32 wwwomgmarteorg
trace structures with failure behaviors [81] A trace structureis a representation of a component or interface with two setsof behaviors The set of successes are those behaviors whichare acceptable and guaranteed by the component Converselythe set of failures are behaviors which drive the componentinto unacceptable states and are therefore refused This workfocuses primarily on the problem of checking refinement anddoes not explore further the potentials of the formalism froma methodological point of view The work by Dill was laterextended by Wolf in the direction of synchronous systemsNegulescu later generalizes the algebra to Process Spaceswhich abstract away the specifics of the behaviors and derivesnew composition operators [143] This particular abstractiontechnique was earlier introduced by Burch with Trace Algebrasto construct conservative approximations [47] and later gen-eralized by Passerone and Burch [154] to study generic tracestructures with failure behaviors and to formalize the problemof computing the quotient (there called mirror) [153] Thispaper aims at proposing for model based design of systemsand CPS a new vista on contracts In the next section wepropose an all encompassing meta theory of contracts
V A MATHEMATICAL META-THEORY OF CONTRACTS
In software engineering meta-models are ldquomodels of mod-elsrdquo ie formal ways of specifying a certain family ofmodels Similarly we call here meta-theory a way to specifya particular family of theories In this section we proposea meta-theory of contracts This meta-theory is summarizedin Table IV It comes as a few primitive concepts on topof which derived concepts can be built A number of keyproperties can be proved about the resulting frameworkThese properties demonstrate that contracts are a convenientparadigm to support incremental development and independentimplementability in system design The meta-theory will serveas a benchmark for our subsequent review of concrete contracttheories
The meta-theory we develop here is novel There are veryfew attempts of that kind In fact the only ones we are awareof are the recent works by Bauer et al [22] and Chen et al [59]which follow a different (and complementary) approach Thediscussion of this work is deferred to the bibliographicalsection V-H
A Components and their composition
To introduce our meta-theory we start from a universe Mof possible components each denoted by the symbol M orE and a universe of their abstractions or contracts eachdenoted by the symbol C Our meta-theory does not presumeany particular modeling style neither for components nor forcontractsmdashwe have seen in Section IV an example of a (verysimple) framework for static systems More generally someframeworks may represent components and contracts with setsof discrete time or even continuous time traces other theoriesuse logics or state-based models of various kinds and so on
We assume a composition M1 timesM2 acting on pairs ofcomponents Component composition times is partially not to-
RR ndeg 8147
Contracts for System Design 25
Concept Definition and generic properties What depends on the particulartheory of contracts
Primitive
Component Components are denoted by M they can be open or closed How components are specified
Composabilityof components A type property on pairs of components (M1M2) How this type property is defined
Compositionof components
M1timesM2 is well defined if and only if M1 and M2 are composableIt is required that times is associative and commutative The definition of the composition
Environment An environment for component M is a componentE such that EtimesM is defined and closed
Derived
Contract A contract is a pair C = (EC MC ) where MC is a subsetof components and EC a subset of legal environments
Which family C of contractscan be expressed andhow they are expressedunless otherwise specifiedquantifying is implicitly over C isin C
Consistency C is consistent iff it has at least one component MC 6= empty How consistency is checked
Compatibility C is compatible iff it has at least one environment EC 6= empty How compatibility is checked
Implementation M |=M C if and only if M isinMCE |=E C if and only if E isinEC
How implementation is checked
Refinement Cprime C iff ECprime supe EC and MCprime subeMC Property 1 holds How refinement is checked
GLB andLUBof contracts
C1andC2 = Greatest Lower Bound (GLB) for we assume GLB existC1orC2 = Least Upper Bound (LUB) for we assume LUB exist
Property 2 holds
Whether and howGLB and LUB can beexpressed and computed
Compositionof contracts
C1otimesC2 is defined if M1 |=M C1M2 |=M C2
rArr (M1M2) composable
C1otimesC2 =andC
∣∣∣∣∣∣M1 |=M C1 and M2 |=M C2 and E |=E C
dArrM1 timesM2 |=M C and EtimesM2 |=E C1 and EtimesM1 |=E C2
Assumption 1 is in force Properties 3 4 and 5 holdSay that C1 and C2 are compatible if so is C1otimesC2
How composition isexpressed and computed
Quotient C1C2 =or C | C otimes C2 C1 Property 6 holds How quotient is
expressed and computed
Table IVSummary of the meta-theory of contracts We first list primitive concepts and then derived concepts introduced by the meta-theory
tally defined Two components that can be composed arecalled composable Composability of components is meantto be a typing property In order to guarantee that differentcomposable components may be assembled together in anyorder it is required that component composition times is asso-ciative and commutative Components that exhibit no meansfor interacting with the outside world are called closed othercomponents are open An environment for a component Mis another component E composable with M and such thatM times E is closed
B Contracts
In our primer of Section IV we have highlighted the im-portance of the legal environments associated with contractsfor which an implementation will operate satisfactorily At theabstract level of the meta-theory we make this explicit next
Definition 1 A contract is a pair C = (EC MC ) where
bull MC subeM is the set of implementations of C andbull EC subeM is the set of environments of C
For any pair (EM) isin EC times MC E is an environmentfor M Hence MtimesE must be well defined and closed Acontract possessing no implementation is called inconsistentA contract possessing no environment is called incompatibleWrite
M |=M C and E |=E C
to express that M isinMC and E isin EC respectivelyIn concrete theories of contracts both components and con-tracts are described in some finite (preferably concise) wayIn turn it is not true that every set Mprime subeM of componentscan be represented as Mprime = MC for some contract C andsimilarly for sets of environments To highlight this
we assume a family C of expressible contracts (5)
Only contracts belonging to this family can be consideredThis is made explicit in Table IV
C Refinement and conjunctionTo support independent implementability the concept of
contract refinement must ensure the following if contract Cprime
RR ndeg 8147
Contracts for System Design 26
refines contract C then any implementation of Cprime should 1)implement C and 2) be able to operate in any environment forC Hence the following definition for refinement preorder between contracts Cprime refines C written Cprime C if and onlyif MCprime sube MC and ECprime supe EC As a direct consequence thefollowing property holds which justifies the use of the termldquorefinementrdquo for this relation
Property 1 (refinement)1) Any implementation of Cprime is an implementation of C
M |=M Cprime rArrM |=M C and2) Any environment of C is an environment of Cprime
E |=E C rArr E |=E CprimeThe conjunction of contracts C1 and C2 written C1 and C2 isthe greatest lower bound (GLB) of these two contracts withrespect to refinement ordermdashwe assume such a GLB existsThe intent is to define this conjunction as the intersection ofsets of implementations and the union of sets of environmentsHowever due to (5) not every set of components is thecharacteristic set of a contract The best approximation consistsin taking the greatest lower bound for the refinement relationThe following immediate properties hold
Property 2 (shared refinement)1) Any contract that refines C1 and C2 also refines C1 and C2
Any implementation of C1 and C2 is a shared implementa-tion of C1 and C2 Any environment of C1 or C2 is anenvironment of C1 and C2
2) For C sube C a subset of contractsandC is compatible if
and only if there exists a compatible C isin C
The conjunction operation formalizes the intuitive notion of aldquoset of contractsrdquo or a ldquoset of requirementsrdquo
D Contract composition
The objective of contract composition is to ensure that1) composing respective implementations of each contract
yields an implementation for the composition and2) composing an environment for the resulting composition
with an implementation for C2 yields an environment forC1 and vice-versa
These two properties are essential in supporting top-downdesign by successive decompositions and refinements of con-tracts Contract composition C1 otimes C2 is thus defined on topof component composition as indicated in Table IV with thefollowing assumption in force throughout this meta-theory
Assumption 1 The following condition holds
C1 otimes C2 isin CC1otimesC2
(Note that this assumption is non trivial since it is not true foran arbitrary set C sube C that
andCisinC C isin C) The condition
for C1 otimes C2 to be defined is that every pair (M1M2) ofrespective implementations is composable so that M1 timesM2
is well definedmdashrecall that component composability is atyping property Consequently if E is an environment forM1timesM2 E is composable with both M1 and M2 and EtimesM1
is an environment for M2 and vice-versa Referring to the
formula defining C1 otimes C2 denote by CC1otimesC2 sube C the set ofcontracts specified in the brackets The following lemma willbe instrumental
Lemma 1 Let four contracts be such that Cprime1 C1Cprime2 C2 and C1 otimes C2 is well defined Then so is Cprime1 otimes Cprime2and CCprime1otimesCprime2 supe CC1otimesC2
Proof Since C1otimesC2 is well defined it follows that every pair(M1M2) of respective implementations of these contracts is acomposable pair of components Hence Cprime1otimesCprime2 is well definedaccording to the formula of Table IV Next since Cprime1 C1 andCprime2 C2 and using Assumption 1 M1 |=M Cprime1 and M2 |=M Cprime2implies M1 |=M C1 and M2 |=M C2 similarly E timesM2 |=E C1and EtimesM1 |=E C2 implies EtimesM2 |=E Cprime1 and EtimesM1 |=E Cprime2Therefore replacing in the big brackets defining the contractcomposition C1 by Cprime1 and C2 by Cprime2 can only increase the setCC1otimesC2 2
To conform to the usage we say that C1 and C2 arecompatible contracts if their composition C1 otimes C2 is definedand compatible in the sense of Table IV The followingproperties are a direct corollary of Lemma 1
Property 3 (independent implementability) For all con-tracts C1 C2 Cprime1 and Cprime2 if
1) C1 is compatible with C22) Cprime1 C1 and Cprime2 C2 hold
then Cprime1 is compatible with Cprime2 and Cprime1 otimes Cprime2 C1 otimes C2
Thus compatible contracts can be independently refined Thisproperty holds in particular if Cprime1 and Cprime2 are singletons
Corollary 1 Compatible contracts can be independentlyimplemented
Property 3 is fundamental particularly in top-down designTop-down incremental design consists in iteratively decom-posing a system-level contract C into sub-system contractsCi i isin I for further independent development To ensure thatindependent development will not lead to integration problemsit is enough to verify that
otimesiisinI Ci C We insist that since
contracts are purposely abstract and subsystems are not manythe composition of contracts Ci will not typically result in stateexplosion33
The following property is essential as it states that contractcomposition can be performed in any order and changesin architecture (captured by changes in parenthesizing) areallowed
Property 4 (associativity and commutativity) For all con-tracts C1 C2 C3 and C4 if C1 and C2 are compatible C3 andC4 are compatible and C1otimesC2 is compatible with C3otimesC4 thenC1 is compatible with C3 C2 is compatible with C4 C1 otimes C3is compatible with C2 otimes C4 and
(C1 otimes C2)otimes (C3 otimes C4) = (C1 otimes C3)otimes (C2 otimes C4) (6)
33 This is unlike in compositional verification where timesiisinIMi |=M Pis to be checked where Mi are detailed implementations and P is aproperty In this case the composition timesiisinIMi typically gives raise to stateexplosion Techniques have thus been proposed to verify such properties inan incremental way [176] [62] [98] [1] [121]
RR ndeg 8147
Contracts for System Design 27
Proof To shorten notations write C12 instead of C1 otimesC2 andsimilarly for any subset of 1 2 3 4 By Assumption 1 andthe associativity and commutativity of component composi-tion C1234 is characterized by the following two propertieswhere index i ranges over the set 1 4
Mi |=M Ci rArr M1times timesM4 |=M C1234
E |=E C1234 rArr Etimes (timesj 6=iMj) |=E Ci(7)
Observe that (7) is fully symmetric which proves (6) Nextusing the assumptions regarding compatibility we derive theexistence of at least one environment E satisfying the premiseof the second implication of (7) Since (7) is fully symmetricthis proves the conclusions of Property 4 regarding compati-bility 2
Property 5 (distributivity) If the following contract compo-sitions are all well defined then the following holds
[(C11 and C21)otimes (C12 and C22)] [(C11 otimes C12) and (C21 otimes C22)] (8)
Proof By Lemma 1 C(C11andC21)otimes(C12andC22) supe CC11otimesC12 Taking the GLB of these two sets thus yields[(C11 and C21)otimes (C12 and C22)] (C11 otimes C12) and similarlyfor (C21 otimes C22) Thus (8) follows 2
The use of distributivity is best illustrated in the followingcontext Suppose the system under design decomposes intotwo sub-systems labeled 1 and 2 and each subsystem hastwo viewpoints associated with it labeled by another indexwith values 1 or 2 Contract (C11 and C21) is then the contractassociated with sub-system 1 and similarly for sub-system 2Thus the left hand side of (8) specifies the set of imple-mentations obtained by first implementing each sub-systemindependently and then composing these implementationsProperty 5 states that by doing so we obtain an implemen-tation of the overall contract obtained by first getting thetwo global viewpoints (C11 otimes C12) and (C21 otimes C22) andthen taking their conjunction This property supports inde-pendent implementation for specifications involving multipleviewpoints Observe that only refinement not equality holdsin (8)
E Quotient
The quotient of two contracts is defined in Table IV It isthe adjoint of the product operation otimes in that C1C2 is themost general context C in which C2 refines C1 It formalizesthe practice of ldquopatchingrdquo a component to make it behavingaccording to another specification From its definition inTable IV we deduce the following property
Property 6 (quotient) The following holds
C C1C2 hArr C otimes C2 C1
Proof Immediate from the definition 2
F Discussion
By inspecting Table IV the different notions can be classi-fied into the following two categories
bull Primitive notions that are assumed by the meta-theoryThis category comprises components component com-posability and composition
bull Derived notions comprise contract refinement conjunc-tion composition and quotient consistency and com-patibility for contracts The derived notions follow fromthe primitive ones through set theoretic non effectivedefinitions
The meta-theory offers by itself a number of fundamentalproperties that underpin incremental development and inde-pendent implementability Concrete theories will offer defini-tions for the primitive notions as well as effective means toimplement (or sometimes approximate) the derived notionsObservers and then abstract interpretation we develop nextprovide generic approaches to recover effectiveness
G Observers
Notion Observer
C = (EC MC )(bEC b
MC)
C = C1andC2 bEC = bE
C1 or bEC2 b
MC = bM
C1 and bMC2
C = C1orC2 bEC = bE
C1 and bEC2 b
MC = bM
C1 or bMC2
C = C1otimesC2bEC(E) =
bMC1 (M1) and bM
C2 (M2)
dArrbEC2 (EtimesM1) and bE
C1 (EtimesM2)
bMC(M1 timesM2) = bM
C1 (M1) and bMC2 (M2)
Table VMirroring the algebra of contracts with observers
A typical obstacle in getting finite (or more generallyeffective) representations of contracts is the occurrence ofinfinite data types and functions having infinite domains Thesecan be dealt with by using observers which originate from thebasic notion of test for programs
Definition 2 Let C be a contract An observer for Cis a pair (bE
C bMC) of non-deterministic boolean functions
M 7rarr F T called verdicts such that
bEC(M) outputs F =rArr M 6isin ECbMC(M) outputs F =rArr M 6isin MC
(9)
The functions M 7rarr bEC(M) and M 7rarr bM
C(M) being bothnon-deterministic accounts for the fact that the outcome of atest depends on the stimuli from the environment and possiblyresults from internal non-determinism of the tested componentitself Note the single-sided implication in (9) which reflectsthat tests only provide semi-decisions
Relations and operations of the meta-theory can be mirroredby relations and operations on observers as explained inTable Vmdashwe omit the formulas for the quotient as semi-effectiveness of testing makes it useless Despite GLB andLUB can be mirrored using the formulas of the table nothingcan be said about the relationship of observers for contractsbased on the fact that they are in a refinement ordering Dually
RR ndeg 8147
Contracts for System Design 28
nothing can be inferred in terms of their refinement fromsuch a relationship between the observers Still the followingweaker result holds which justifies how GLB and LUB arerepresented using observers in Table V
Lemma 2 Let (bEC b
MC) be an observer for C and let Cprime C
Then any pair (bE bM) satisfying bE ge bEC and bM le bM
C is anobserver for CprimeThe following immediate results hold regarding consistencyand compatibility
Lemma 31) If bE
C(E) outputs F for all tested environment E then Cis incompatible
2) If bMC(M) outputs F for all tested component M then C
is inconsistent
To summarize Definition 2 provides semi-decision proceduresto check whether a component or an environment are validfor a contract Lemma 3 provides semi-decision proceduresfor checking consistency and compatibility Finally Table Vindicates how operations from the contract algebra can bereflected into operations on observers
Due to the need for exercising all components or environ-ments using observers for checking consistency or compat-ibility is still non-effective For concrete theories exhibitingsome notion of ldquostrongestrdquo environment or component for theconsidered contract a reinforcement of Lemma 3 will ensureeffectiveness
In Section VI where concrete theories are reviewed weindicate for each theory how observers can be constructedand how Lemma 3 specializes
H Bibliographical note
Abstract contract theories and features of our presen-tation Our presentation here is new There is only a smallliterature providing an abstract formalization of the notion ofcontracts The only attempts we are aware of are the recentworks by Bauer et al [22] and Chen et al [59] albeit withdeeply different and complementary approaches
The publication [22] develops an axiomatization of thenotion of specification from which contracts can be derivedin a second step More precisely specifications are abstractentities that obey the following list of axioms it possesses arefinement relation that is a preorder which induces a notionof equivalence of specifications and a parallel compositionthat is associative commutative (modulo equivalence) andmonotonic with respect to refinement It is assumed thatif two specifications possess a common lower bound thenthey possess a greatest lower bound A quotient is alsoassumed which is the residuation of the parallel composi-tion From specifications contracts are introduced as pairs ofspecifications very much like AssumeGuarantee contracts wedevelop in Section VII are pairs of assertions Sets of legalenvironments and sets of implementations are associated tocontracts Finally modal contracts are defined by borrowingideas from modal specifications we discuss in Section VIIIThis abstract theory nicely complements the one we develop
here in that it shows that both specifications and contracts canbe defined as primitive entities and be used to build moreconcrete theories
The work [59] develops the concept of declarative speci-fication which consists of a tuple P = (ΣinΣout TΣ FΣ)where Σin and Σout are input and output alphabets of actionsΣ = Σin ] Σout and TΣ FΣ sube Σlowast such that FΣ sube TΣ
are sets of permissible and inconsistent traces respectivelymdashthis approach find its origins in earlier work by Dill [81]and Negulescu [143] Outputs are under the control of thecomponent whereas inputs are issued by the environmentThus after any successful interaction between the componentand the environment the environment can issue any input αeven if it will be refused by the component If α is refusedby the component after the trace t isin TΣ tα isin FΣ is aninconsistent trace capturing that a communication mismatchhas occurred An environment is called safe if it can preventa component from performing an inconsistent trace For Qto be used in place of P it is required that Q must existsafely in any environment that P can exist in safely this isthe basis on which refinement is defined Alphabet extensionis used by which input actions outside the considered alphabetare followed by an arbitrary behavior for the declarativespecification A conjunction is proposed that is the GLB forrefinement order A parallel composition is proposed whichis monotonic with respect to refinement A quotient is alsoproposed which is the residuation of parallel composition
Observers Observers being related to the wide areaof software and system testing have been widely studiedA number of existing technologies support the design ofobservers and we review some of them now
Synchronous languages [28] [100] [30] are a formalism ofchoice in dealing with observers The family of SynchronousLanguages comprises mainly the imperative language Es-terel [92] [84] and the dataflow languages Lustre [144] andSignal [157] The family has grown with several childrenoffering statecharts-like interfaces and blending dataflow andstatechart-based styles of programming such as in Scade V634Synchronous languages support only systems governed bydiscrete time not systems with continuous time dynamics(ODEs) They benefit from a solid mathematical semantics Asa consequence executing a given program always yields thesame results (results do not depend on the type of simulator)The simulated or analysed program is identical to the codefor embedding Thanks to these unique features specificationscan easily be enhanced with timing andor safety viewpointsThe RT-Builder35 tool on top of Signal is an example offramework supporting the combination of functional and tim-ing viewpoints while analyzing an application deployed overa virtual architecture (see Section IV-D4) The widely usedSimulinkStateflow36 tool by The Mathworks offers similarfeatures One slight drawback is that its mathematical seman-
34httpwwwesterel-technologiescomproductsscade-suite35httpwwwgeensoftcomenarticlertbuilder36httpwwwmathworkscomproductssimulink
RR ndeg 8147
Contracts for System Design 29
tics is less firmly defined (indeed results of executions maydiffer depending on the code executed simulation or generatedC code) On the other hand Simulink supports continuoustime dynamics in the form of systems of interconnectedODEs (Ordinary Differential Equations) thus supporting themodeling of the physical part of the system Using Simulinkpossibly enhanced with SimScape37 allows for includingphysical system models in observers eg as part of the systemenvironment The same comment holds regarding Modelica38
Actually observers have been proposed and advocated in thecontext of Lustre and Scade [101] [102] [103] Esterel [45]and Signal [137] [138] More precisely Scade advocatesexpressing tests using Scade itself Tests can then easily beevaluated at run time while executing a Scade program Toconclude observe that synchronous languages and formalismsdiscussed in this section are commercially available and widelyused
Another good candidate for expressing observers is theProperty Specification Language (PSL) PSL is an industrialstandard [151] [86] [85] for expressing functional (or behav-ioral) properties targeted mainly to digital hardware designWe believe that PSL is indeed very close to several lessestablished but more versatile formalisms based on restrictedEnglish language that are used in industrial sectors otherthan digital hardware eg in aeronautics automobile orautomation Consider the following property
ldquo For every sequence that starts with an a imme-diately followed by three occurrences of b and endswith a single occurrence of c d holds continuouslyfrom the next step after the end of the sequence untilthe subsequent occurrence of e rdquo
This property is translated into its PSL version
[]ab[3]c |=gt (d until e)
PSL is a well-suited specification language for expressingfunctional requirements involving sequential causality of ac-tions and events Although we are not aware of the usageof PSL in the particular context of contract-based design wemention the tool FoCS [2] that translates PSL into checkersthat are attached to designs The resulting checker takes theform of an observer if the PSL specification is properlypartitioned into assumption and guarantee properties More re-cently PSL was also used for the generation of transactors thatmay adapt high-level requirements expressed as transaction-level modules to the corresponding register-transfer implemen-tation [18] [17] It follows that the existing tool support forPSL makes this specification language suitable in the contract-based design using observers We note that the availabilityof formal analysis tools allows the design to be checkedexhaustivelymdashthis is of course at the price of restrictionson data types Another benefit in using PSL as an observer-based interface formalism is an existing methodology for user-guided automated property exploration built around this lan-
37httpwwwmathworkscomproductssimscape38httpswwwmodelicaorg
guage [158] [42] that is supported by the tool RATSY [43]As previously stated PSL is built on top of LTL and regularexpressions One can thus express liveness properties in PSLwhich are not suitable for online monitoring There are twoorthogonal ways to avoid this potential issue (1) restrictingthe PSL syntax to its safety fragment or (2) adapting the PSLsemantics to be interpreted over finite traces [87] A survey ofusing PSL in runtime verification can be found in [85]
Another relevant formalism for building observers consistsof the Live Sequence Charts (LSC) [64] [107] [105] LSCare a graphical specification language based on scenarios thatis an extension of Message Sequence Charts (MSC)39 Atypical LSC consists of a prechart and a main chart Thesemantics is that whenever the prechart is satisfied in a run ofthe system eventually the main chart must also be satisfiedPrecharts should not be confused with assumptions howeverthey are rather sort of ldquoprerequisitesrdquo LSCs are multi-modalin that any construct in the language can be either cold orhot with a semantics of ldquomay happenrdquo or ldquomust happenrdquorespectively If a cold element is violated (say a conditionthat is not true when reached) this is considered a legalbehavior and some appropriate action is taken Violation ofa hot element however is considered a violation of thespecification and is not allowed to happen in an executionLSC are executable The execution of a set of LSCs is calledplay out by the authors [107] Play out is useful for checkingan LSC specification against a property [66] LSC can beused as (expressive) tests to monitor the execution of a designover non-terminating runs While doing so the same rules asabove are applied except that the design controls the emissionof events and the LSC specification is used to react in caseof violation of the specification This is manifested by theabsence of rules explaining the occurrence of some event atrun-time This procedure is called play in by the authors Toconclude LSCs are well suited to express observers
VI PANORAMA OF CONCRETE THEORIES
For the coming series of sections where concrete contracttheories are reviewed the reader is referred to Table IV ofSection V where the meta-theory of contracts is developedWe will illustrate how various concrete contract theories canbe developed by specializing the meta-theory
VII PANORAMA ASSUMEGUARANTEE CONTRACTS
Our static example of Section IV provided an exampleof contract specified using Assumptions and Guarantees As-sumeGuarantee contracts (AG-contracts) Assumptions char-acterize the valid environments for the considered compo-nent whereas the Guarantees specify the commitments ofthe component itself when put in interaction with a validenvironment Various kinds of AG-contract theories can beobtained by specializing the meta-theory in different waysVariations concern how the composition of components isdefined We will review some of these specialization and relatethem to the existing literature
39httpwwwsdl-forumorgMSCindexhtm
RR ndeg 8147
Contracts for System Design 30
In general AG contract theories build on top of componentmodels that are assertions ie sets of behaviors or tracesassigning successive values to variables As we shall seedifferent kinds of frameworks for assertions can be consid-ered including asynchronous frameworks of Kahn ProcessNetworks (KPN) [117] and synchronous frameworks in whichbehaviors are sequences of successive reactions assigningvalues to the set of variables of the considered system We firstdevelop the theory for the simplest case of a fixed alphabetThen we develop the other cases
A Dataflow AG contracts
For this simplest variant all components and contractsinvolve a same alphabet Σ of variables possessing identical40
domain DWith this simplification a component M identifies with an
assertion
P sube Σ 7rarr Dlowast cupDω (10)
ie a subset of the set of all finite or infinite behaviors overalphabet Σ such a behavior associates to each symbol x isin Σa finite or infinite flow of values The flows are not mutuallysynchronized and there is no global clock or logical step Wediscuss in Section VII-D variants of this framework with moresynchronous models of behaviors For convenience we feelfree to use both set theoretic and boolean notations for therelations and operations on assertions
Two components are always composable and we definecomponent composition by the intersection of their respectiveassertions
P1timesP2 = P1andP2 (11)
Formulas (10) and (11) define a framework of asynchronouscomponents with no global clock and no notion of reac-tion Instead a component specifies a relation between thehistories of its different flows When input and output portsare considered as in Section VII-B and components are in-putoutput functions we obtain the model of Kahn ProcessNetworks [117] widely used for the mapping of synchronousprograms over distributed architectures [159] [160]
Definition 3 A contract is a pair C = (AG) of assertionscalled the assumptions and the guarantees The set EC of thelegal environments for C collects all components E such thatE sube A The set MC of all components implementing C isdefined by AtimesM sube GThus any component M such that M le G or notA is animplementation of C and MC = G or notA is the maximalimplementation Observe that two contracts C and Cprime withidentical input and output alphabets identical assumptionsand such that Gprime or notAprime = G or notA possess identical sets ofimplementations MC =MCprime According to our meta-theorysuch two contracts are equivalent Any contract C = (AG)is equivalent to a contract in saturated form (AGprime) such that
40This is only an assumption intended to simplify the notations It is by nomeans essential
Gprime supe notA or equivalently G or A = T the true assertionto exhibit Gprime just take Gprime = G or notA A saturated contractC = (AG) is consistent if and only if G 6= empty and compatibleif and only if A 6= empty
Next for C and Cprime two saturated contracts with identicalinput and output alphabets
refinement Cprime C holds iffAprimegeAGprimeleG (12)
Conjunction follows from the refinement relation for C1 andC2 two saturated contracts with identical input and outputalphabets C1 and C2 = (A1orA2 G1andG2)
Focus now on contract composition C = C1 otimes C2 for twosaturated contractsmdashthis is no loss of generality as we haveseen Contract composition instantiates through the followingformulas cf (1) in Section IV
G = G1andG2
A = max
A∣∣∣∣∣∣AandG2rArrA1
andAandG1rArrA2
(13)
which satisfies Assumption 1 of the meta-theory If further-more contracts are saturated then (13) reformulates as theformulas originally proposed in [29]
G = G1 andG2
A = (A1 andA2) or not(G1 andG2)(14)
Observe that the so obtained contract (AG) is saturatedG orA = (G1 andG2) or (A1 andA2) or not(G1 andG2) = T
No quotient operation is known for AssumeGuaranteecontracts
We finish this section by observing that the two contractsC1 and Cprime1 of Section IV-A1 satisfy Cprime1 C1 according to thetheory of this section guarantees are identical but assumptionsare relaxed
B Capturing exceptions
Referring to the primer of Section IV-A1 and its staticsystem example dividing by zero may raise an exception Forinstance a careless designer may consider instead of M1 aslight variation M prime1 of it where the behaviors are only partiallydefined
M prime1 behaviors (y 6= 0rarr z = xy)
leaving what happens if a value 0 is submitted for y unspeci-fied In practice y = 0 would raise an exception leading to anunpredictable outcome and possibly a crash unless exceptionhandling is offered as a rescue by the execution platform
In this section we show how a mild adjustment of ourtheory of AG contracts can capture exceptions and theirhandling To simplify we develop this again for the case ofa fixed alphabet Σ We only present the add-ons with respectto the previous theories the parts that remain unchanged arenot repeated
Since exceptions are undesirable events caused by the com-ponent itself and not by its inputsmdashfor our simple example the
RR ndeg 8147
Contracts for System Design 31
exception is the improper handling of the division by zeromdashweneed to include inputs and outputs as part of our frameworkfor components
A component is thus a tuple M = (ΣinΣout P ) whereΣ = Σin cup Σout is the decomposition of alphabet Σ intoits inputs and outputs and P sube (Σ 7rarr (Dlowast cupDω)) is anassertion Whenever convenient we shall denote by Σin
M QM PM etc the items defining component M Components M1
and M2 are composable if Σout1 cap Σout
2 = empty If so thenM1timesM2 = (ΣinΣout P ) is well defined with Σout =Σout
1 cup Σout2 Σin = Σminus Σout and P = P1 cap P2
Let us now focus on exceptions To capture improper re-sponse (leading to a ldquocrashrdquo) we distinguish a special elementfail isin D We assume that crash is not revertible ie inany behavior of the component any variable remains at failwhen it reaches that value Referring to the static example ofSection IV we would then set x0 = fail for any x We arenow ready to formalize what it means for a component to befree of exception
Definition 4 A component M is free of exception if1) It accepts all inputs
prΣinM
(PM ) = ΣinM 7rarr (DlowastcupDω)
2) It does not cause by itself the occurrence of fail in itsbehaviors for any behavior σ isin PM if the projectionprΣin
M(σ) of σ to the input alphabet Σin
M does not involvefail then neither does σ
Exception freeness defined in this way is such that if M1 andM2 are both composable and free of exception then M1timesM2
is also free of exception Hence we are free to restrict ouruniverse of components to exception free componentsmdashthusDefinition 4 defines our family of components AG contractsare re-defined accordingly
Definition 5 A contract is a tuple C = (ΣinΣout AG)where Σin and Σout are the input and output alphabets andA and G are assertions over Σ called the assumptions andthe guarantees The set EC of the legal environments for C areall free of exception components E such that Σin
E = ΣoutC
ΣoutE = Σin
C and PE sube A The set MC of all componentsimplementing C is defined by M is free of exception Σin
M =ΣinC and Σout
M = ΣoutC and PEtimesM sube G for every environment
E of CFocus now on the issue of consistency and compatibility forcontracts The following holds
Property 7 Let C = (ΣinΣout AG) be a contract satis-fying the following conditions
prΣinC
(G) = ΣinM 7rarr (DlowastcupDω) (15)
prΣoutC
(A) = ΣoutM 7rarr (DlowastcupDω) (16)
fail does not occur in G andA (17)
Then C is consistent and compatibleProof By condition (15) the component M = (ΣinΣout G)satisfies condition 4 of Definition 4 It may not satisfy condi-tion 2 however To achieve this we must modify in M the
behaviors not belonging to A to avoid fail to occur PreservingM on A will ensure that implementation of C is preservedTo get M prime replace any behavior σ isin G and notA by a behaviorσprime such that prΣin
C(σprime) = prΣin
C(σ) and prΣout
C(σprime) 63 fail
Component M prime obtained in this way is free of exception andimplements C showing that C is consistent Consider next thecomponent E = (ΣoutΣin A) If E is free of exception thenit is an environment for C If this is not the case then we canmodify E on AandnotG as we did for obtaining M prime This yieldsan environment Eprime for C showing that C is compatible 2
Conditions (15) and (16) express that assumptions andguarantees are both input enabled Condition (17) is the keyone Observe that now contract Cprime1 of Section IV-A1 isinconsistent since it has no implementationmdashimplementationsmust be free of exception In turn contract C1 is consistentThis is in contrast to the theory of Section VII-A whereboth contracts were considered consistent (crashes were notruled out) Indeed contract C1 of Section IV-A1 satisfies theconditions of Property 7 whereas Cprime1 does not Addressingexceptions matters
C Dealing with variable alphabets
Since contracts aim at capturing incomplete designs wecannot restrict ourselves to a fixed alphabetmdashit is not known inadvance what the actual alphabet of the complete design willbe Thus the simple variants of Sections VII-A and VII-B haveno practical relevance and we must extend them to dealingwith variable alphabets In particular components will now bepairs M = (ΣM PM ) where ΣM is the alphabet of M andPM is an assertion over ΣM Similarly contracts are triplesC = (ΣC AC GC) where assumptions AC and guarantees GCare assertions over alphabet ΣC
Key to dealing with variable alphabet this is the operationof alphabet equalization that we introduce next For P an as-sertion over alphabet Σ and Σprime sube Σ we consider its projectionprΣprime(P ) over Σprime which is simply the set of all restrictionsto Σprime of all behaviors belonging to P We will also need theinverse projection prminus1
Σprimeprime (P ) for Σprimeprime supe Σ which is the set ofall behaviors over Σprimeprime projecting to Σ as behaviors of P For(Σi Pi) i = 1 2 we call alphabet equalization of (Σ1 P1)and (Σ2 P2) the two assertions (Σprminus1
Σ (Pi)) i = 1 2 whereΣ = Σ1 cup Σ2
We also need to define alphabet equalization when thealphabet Σ decomposes as Σ = Σin ] Σout Equalizing theabove decomposition to a larger alphabet Σprimeprime supe Σ yieldsΣprimeprimeout = Σout whence Σprimeprimein = Σprimeprime Σprimeprimeout follows
Alphabet equalization serves as a preparation step to reusethe framework of Section VII-A when alphabets are variable
This being defined all operations and relations introducedin Section VII-A are extended to the case of variable alphabetsby 1) applying alphabet equalization to the involved assertionsand 2) reusing the operation or relation as introduced inSection VII-A
As pointed out in [29] this generalization yields a contracttheory that is a valid instantiation of the meta-theory (up tothe missing quotient) It is not satisfactory from the practical
RR ndeg 8147
Contracts for System Design 32
standpoint however The reason is that the conjunction oftwo contracts with disjoint alphabets yields a trivial assump-tion T which is very demandingmdashany environment must beaccommodatedmdashand does not reflect the intuition (more onthis will be discussed in Section VIII-D
To summarize Sections VII-A VII-B and VII-C togetherdefine a framework for asynchronous AssumeGuarantee con-tracts where components are of Kahn Process Network type
D Synchronous AG contracts
We obtain variants of this framework of AssumeGuaranteecontracts by changing the concrete definition of what anassertion is and possibly revisiting what the component com-position is We can redefine assertions as
P sube (Σ 7rarr D)lowast cup (Σ 7rarr D)ω (18)
Compare (18) with (10) In both cases assertions are sets ofbehaviors With reference to (10) behaviors were tuples offinite or infinite flows one for each symbol of the alphabetIn contrast in (18) behaviors are finite or infinite sequencesof reactions which are the assignment of a value to eachsymbol of the alphabet By having a distinguished symbolperp isin D to model the absence of an actual data we getthe multiple-clocked synchronous model used by synchronouslanguages [30] Definition (18) for assertions correspond to thesynchronous model of computation whereas (10) correspondsto the Kahn Process Network type of model [117] [142] Thematerial of Sections VII-A VII-B and VII-C can be adaptedto this new model of component composition thus yielding aframework of synchronous AssumeGuarantee contracts
E Observers
The construction of observers for this case is immediate Wedevelop it for the most interesting case in which exceptions arehandled see Sections VII-A and VII-B Let P be an assertionaccording to (10) P defines a verdict bP by setting
bP (σ) = T if and only if σ isin P (19)
Observers must return their verdict in some finite amount oftime Hence on-line interpretation based on Definition 3 isappropriate With this interpretation for C = (ΣinΣout AG)a contract its associated observer is obtained as follows withreference to Definition 2
bull bEC(E) is performed by drawing non-deterministically a
behavior σ of E and then evaluating bA(σ)bull bMC(M) is performed by drawing non-deterministically a
behavior σ of M and then evaluating bA(σ)rArr bM (σ)
Lemma 3 for generic observers specializes to the followingeffective semi-decision procedure
Lemma 4
1) If bA outputs F then C is incompatible2) If bA rArr bG outputs F then C is inconsistent
F Discussion
AssumeGuarantee contracts are a family of instantiationsof our meta-theory This family is flexible in that it canaccommodate different models of communication and differentmodels of exceptions AssumeGuarantee contracts are anadequate framework for use in requirements capture Indeedrequirements are naturally seen as assertions When categoriz-ing requirements into assumptions (specifying the context ofuse of the system under development) and guarantees (that thesystem offers) formalizing the resulting set of requirements asan AG contract seems very natural
Regarding exceptions the special value fail that we intro-duced to capture exceptions is not something that is given inpractice Value fail may subsume various run time errors Al-ternatively for the synchronous AssumeGuarantee contractsfail can capture the failure of a component to be input enabled(able in each reaction to accept any tuple of inputs)
In its present form the framework of AssumeGuaranteecontracts (synchronous or asynchronous) suffers from theneed to manipulate negations of assertions an operation thatis generally not effective except if the framework is restrictedto finite state automata and finite alphabets of actions Forgeneral frameworks using observers or abstract interpretationcan mitigate this in part
G Bibliographical note
By explicitly relying on the notions of Assumptions andGuarantees AG-contracts are intuitive which makes themappealing for the engineer In AG-contracts Assumptions andGuarantees are just properties The typical case is when theseproperties are languages or sets of traces which includes theclass of safety properties [122] [58] [136] [14] [61] AG-contracts were advocated by the SPEEDS project [29] Theywere further experimented in the framework of the CESARproject [63] with the additional consideration of weak andstrong assumptions The theory developed in [29] turns outto be closest to this presentation still exceptions were nothandled in [29] The presentation developed in this paperclarifies the design choices in AG-contract theories
Inspired by [126] another form for AG-contract was pro-posed by [97] [99] when designs are expressed using theBIP programming language [41] [174] To achieve separatedevelopment of components and to overcome the problemsthat certain models have with the effective computation ofthe operators the authors avoid using parallel compositionotimes of contracts Instead they replace it with the concept ofcircular reasoning which states as follows in its simplestform if design M satisfies property G under assumptionA and if design N satisfies assumption A then M times Nsatisfies G When circular reasoning is sound it is possibleto check relations between composite contracts based ontheir components only without taking expensive compositionsIn order for circular reasoning to hold the authors deviserestricted notions of refinement under context and show howto implement the relations in the contract theory for the BIP
RR ndeg 8147
Contracts for System Design 33
framework Compatibility is not addressed and this proposaldoes not consider conjunction
Regarding extensions a notion of contract for real-timeinterfaces is proposed in [40] Sets of tasks are associated tocomponents which are individually schedulable on a processorAn interface for a component is an ω-language containing alllegal schedules Schedulability of a set of components on asingle processor then corresponds to checking the emptinessof their intersection The interface language considered isexpressive enough to specify a variety of requirements likeperiodicity the absence or the presence of a jitter etc An as-sumeguarantee contract theory for interfaces is then developedwhere both assumptions and guarantees talk about boundson the frequency of task arrivals and time to completionsDependencies between tasks can also be captured Refinementand parallel product of contracts are then defined exactly asin the SPEEDS generic approach
In [145] a platform-based design methodology that usesAG analog contracts is proposed to develop reliable ab-stractions and design-independent interfaces for analog andmixed-signal integrated circuit design Horizontal and verti-cal contracts are formulated to produce implementations bycomposition and refinement that are correct by constructionThe effectiveness of the methodology is demonstrated on thedesign of an ultra-wide band receiver used in an intelligenttire system an on-vehicle wireless sensor network for activesafety applications
AG-contracts have been extended to a stochastic setting byDelahaye et al [75] [76] [77] In this work the implementa-tion relation becomes quantitative More precisely implemen-tation is measured in two ways reliability and availabilityAvailability is a measure of the time during which a systemsatisfies a given property for all possible runs of the system Incontrast reliability is a measure of the set of runs of a systemthat satisfy a given property Following the lines of the contracttheories presented earlier satisfaction is assumption-dependentin the sense that runs that do not satisfy the assumptions areconsidered to be ldquocorrectrdquo the theory supports refinementstructural composition and logical conjunction of contractsand compositional reasoning methods have been proposedwhere the stochastic or non-stochastic satisfaction levels canbe budgeted across the architecture For instance assume thatimplementation Mi satisfies contract Ci with probability αifor i = 1 2 then the composition of the two implementationsM1timesM2 satisfies the composition of the two contracts C1otimesC2
with probability at least α1 + α2 minus 1Features of our presentation This presentation of AG-
contracts is new in may respects For the first time it iscast into the meta-theory of contracts with the advantage ofclarifying the definition of refinement and parallel compositionof contractsmdashthis involved some hand waving in the originalwork [29] Also this allowed us to handle exceptions properly
VIII PANORAMA INTERFACE THEORIES
Interface theories are an interesting alternative to As-sumeGuarantee contracts They aim at providing a merged
specification of the implementations and environments associ-ated to a contract via the description of a single entity calledan interface We review some typical instances of interfacetheories with emphasis on interface automata and modalinterfaces Interface theories generally use (a mild variation of)Lynch InputOutput Automata [135] [134] as their frameworkfor components and environments As a prerequisite we thusrecall the background on InputOutput Automata io-automatafor short
A Components as io-automataAn io-automaton is a tuple M = (ΣinΣout Q q0rarr)
wherebull Σin and Σout are disjoint finite input and output alpha-
bets set Σ = Σin cup Σoutbull Q is a finite set of states and q0isinQ is the initial statebull rarr sube QtimesΣtimesQ is the transition relation as usual we
write q αminusrarr qprime to mean (q α qprime) isin rarr and qαminusrarr to
indicate the existence of a qprime such that q αminusrarr qprimeBy concatenation transition relation rarr extends to a relationrarrlowast on Q times Σlowast times Q where Σlowast is the set of all finite wordsover Σ Say that a state qprime is reachable from q if there existssome word m such that q mminusrarrlowast qprime To considerably simplifythe development of the theory we restrict ourselves to
deterministic io-automata ie such thatq
αminusrarr q1 and q αminusrarr q2 implies q2 = q1(20)
Two io-automata M1 and M2 having identical alphabet Σare composable if the usual inputoutput matching conditionholds Σout
1 capΣout2 = empty and their composition M = M1timesM2
is given by
Σin = Σin1 cap Σin
2
Σout = Σout1 cup Σout
2
Q = Q1 timesQ2 and q0 = (q10 q20)
and the transition relation rarr is given by
(q1 q2)αminusrarr (qprime1 q
prime2) iff qi
αminusrarri qprimei i = 1 2
An io-automaton is said closed whenever Σin = empty and openotherwise For Mi i = 1 2 two io-automata and two statesqi isin Qi say that q1 simulates q2 written q2leq1 if
forallα qprime2 such that q2αminusrarr2 qprime2 rArr
q1
αminusrarr1 qprime1
and qprime2leqprime1(21)
Say that
M1 simulates M2 written M2leM1 if q20leq10 (22)
Observe that simulation relation (2122) does not distinguishinputs from outputs neither it distinguishes the componentfrom its environment It is the classical simulation relationmeant for closed systems Due to condition (20) of determin-ism simulation coincides with language inclusion
Variable alphabet is again dealt with using the mechanismof alphabet equalization For M = (ΣinΣout Q q0rarr) anio-automaton and Σprime sup Σ we define
MuarrΣprime
=(Σin cup (Σprime Σ)Σout Q q0rarrprime
)RR ndeg 8147
Contracts for System Design 34
whererarrprime is obtained by adding torarr for each state and eachadded action a self-loop at this state labeled with this action
Componentsmdashand consequently environmentsmdashfor use ininterface theories will be receptive io-automata (also termedinput enabled) ie they should react by proper response toany input stimulus in any state41
M is receptive iff forallq isin Qforallα isin Σin qαminusrarr (23)
Receptiveness is stable under parallel composition
B Interface Automata with fixed alphabet
For reasons that will become clear later we restrict thepresentation of interface automata to the case of a fixedalphabet Σ We begin with the definition of Interface Automatawhich are possibly non-receptive io-automata Moreover wegive their interpretation as contracts according to the meta-theory
Definition 6 An Interface Automaton is a tuple C =(ΣinΣout Q q0rarr) where ΣinΣout Qrarr are as inio-automata
The initial state q0 however may not satisfy q0isinQ If q0isinQholds Interface Automaton C defines a contract by fixing apair (EC MC ) as followsbull The set EC of the legal environments for C collects all
components E such that1) Σin
E = Σout and ΣoutE = Σin Thus E and C seen as
io-automata are composable and E timesC is closed2) For any output action α isin Σin of environment E
such that qEαminusrarrE and any reachable state (qE q)
of E times C then (qE q)αminusrarrEtimesC holds
There exists a unique maximal environment EC isin EC inthat EC timesC simulates EtimesC in the sense of (22) for anyE isin EC EC = (ΣoutΣin Q cup gt q0rarrEC ) where(a) the restriction to Qtimes ΣtimesQ of transition relationrarrEC coincides with rarr
(b) forallq isin Q q αminusrarrEC gt holds if and only if not[qαminusrarr ]
and α isin Σout(c) gt αminusrarrEC gt holds for any α isin Σ
bull The setMC of the implementations of C collects all com-ponents M such that io-automaton C simulates ECtimesMin the sense of (22)
Condition 2) means that environment E is only willing toemit an output if it is accepted as an input by C in thecomposition E times C Regarding the existence and uniquenessof EC observe first that conditions (a) and (b) together implythat EC is receptive Also by (a) and (b) EC times C is strictlyidentical with (emptyΣ Q q0rarr) ie it is obtained from Cseen as an io-automaton by simply turning inputs to outputsConsequently Condition 2) holds and thus EC isin EC By (b)and (c) EC is maximal
The above definition of Interface Automata is heterodoxcompare with the original references [72] [5] Definition 6
41In fact receptiveness is assumed in the original notion of io-automatonby Nancy Lynch [135] [134] We use here a relaxed version of io-automatonfor reasons that will become clear later
introduces the two sets EC and MC whereas no notionof implementation or environment is formally associated toan Interface Automaton in the original definition Also thehandling of the initial state is unusual Failure of q0isinQ tohold typically arises when the set of states Q is emptyOur Definition 6 allows to cast Interface Automata in theframework of the meta-theory of Table IV
Corresponding relations and operations must be instantiatedand we do this next As a first immediate result
Lemma 5 q0 isin Q is the necessary and sufficient conditionfor C to be both consistent and compatible in the sense of themeta-theory ie EC 6= empty and MC 6= empty
Refinement and conjunction Contract refinement as de-fined in Table IV is equivalent to alternate simulation [10]defined as follows for Ci i = 1 2 two contracts say that tworespective states qi i = 1 2 are in alternate simulation writtenq2q1 if
forallα isin Σout2 qprime2 st q2
αminusrarr2 qprime2 rArr
α isin Σout
1
q1αminusrarr1 qprime1
qprime2qprime1
forallα isin Σin1 q
prime1 st q1
αminusrarr1 qprime1 rArr
α isin Σin
2
q2αminusrarr2 qprime2
qprime2qprime1
(24)
Say that C2 refines C1 written C2C1 if q20q10 The firstcondition of (24) reflects the inclusionMC2
subeMC1 whereas
the second condition of (24) reflects the opposite inclusionEC2supe EC1
Alternate simulation can be effectively checkedsee [70] for issues of computational complexity Unfortunatelyno simple formula for the conjunction of contracts is knownSee [83] for the best results in this direction
Parallel composition and quotient Contract compositionC2otimesC1 as defined in the meta-theory is effectively computedas follows for Ci two Interface Automata satisfying the con-ditions of Lemma 5 Consider as a first candidate for contractcomposition the composition C2timesC1 where Ci i = 1 2 areseen as io-automata This first guess does not work becauseof the condition involving environments in the contract compo-sition of the meta-theory More precisely by the meta-theorywe should have
E |=E C rArr [EtimesM2 |=E C1 and EtimesM1 |=E C2]
which requires forallα isin Σouti qi
αminusrarri rArr (q1 q2)αminusrarrC2timesC1
Pairs (q1 q2) not satisfying this are called illegal In words apair of states (q1 q2) is illegal when one Interface Automatonwants to submit an output whereas the other one refuses toaccept itmdashreferring to AssumeGuarantee contracts one couldinterpret this as a mismatch of assumptions and guaranteesin this pair of interfaces Illegal pairs must then be prunedaway Pruning away illegal pairs from C2timesC1 together withcorresponding incoming transitions may cause other illegalpairs to occur The latter must also be pruned away untilfixpoint occurs The result is the contract composition C2otimesC1
RR ndeg 8147
Contracts for System Design 35
As a result of this pruning it may be the case that theresulting contract has empty set of states which by Lemma 5expresses that the resulting composition of the two interfacesis inconsistent and incompatiblemdashin the original literature onInterface Automata [72] [5] it is said that the two interfacesC1 and C2 are incompatible
In [39] incremental design of deterministic Interface Au-tomata is studied Let Cdarr be the interface C with input andoutput actions interchanged Given two Interface Automata C1and C2 the greatest interface compatible with C2 such that theircomposition refines C1 is given by (C2 C1darr)darr Hence the partregarding quotient in the meta-theory is correctly addressed fordeterministic Interface Automata
Dealing with variable alphabets So far we have pre-sented the framework of interface automata for the case of afixed alphabet The clever reader may expect that dealing withvariable alphabets can be achieved by using the mechanismof alphabet equalization via inverse projections42 This is acorrect guess for contract composition It is however not clearif it is also adapted for conjunction for which no satisfactoryconstruction exists as previously indicated
In contrast alphabet equalization and conjunction are el-egantly addressed by the alternative framework of ModalInterfaces we develop now
C Modal Interfaces with fixed alphabet
Modal Interfaces inherit from both the Interface Au-tomata and the originally unrelated notion of Modal Automa-ton (or Modal Transition System) see the bibliographicalnote VIII-G As Interface Automata Modal Interfaces usereceptive io-automata as their components and environmentsThe presentation of Modal Interfaces we develop here isaligned with our meta-theory and thus differs from classicalpresentations Again we begin with the case of a fixedalphabet Σ
Definition 7 We call Modal Interface a tuple of the formC = (ΣinΣout Q q0rarr 99K) where ΣinΣout Q q0 are asin Interface Automata and rarr 99Ksube Q times Σ times Q are twotransition relations called must and may respectively
A Modal Interface C such that q0isinQ induces two (possiblynon receptive) io-automata
and Cmust = (ΣinΣout Q q0rarr)and Cmay = (ΣinΣout Q q0 99K)
A Modal Interface is deterministic if Cmay is deterministic inthe sense of 20 C defines a contract by fixing a pair (EC MC )as follows
The set EC of the legal environments for C collects allcomponents E such that
1) ΣinE = Σout and Σout
E = Σin consequently E andCmust seen as io-automata are composable and E timesCmust is closed the same holds with Cmay in lieu ofCmust
42The inverse projection of an io-automaton is simply achieved by addingin each state a self-loop for each missing symbol
2) For any α isin Σin such that qEαminusrarrE and any reachable
state (qE q) of E times Cmay (qE q)αminusrarrEtimesCmust
There exists a unique maximal environment EC isin EC in thatEC times Cmay simulates E times Cmay in the sense of (22) for anyE isin EC EC = (ΣoutΣin Q cup gt q0rarrEC ) where(a) the restriction to QtimesΣintimesQ of transition relationrarrEC
coincides with rarr the restriction to Q times Σout times Q oftransition relation rarrEC coincides with 99K
(b) for any q isin Q q αminusrarrEC gt holds if and only if not[qα99K ]
and α isin Σout(c) gt αminusrarrEC gt holds for any α isin Σ
The set MC of the implementations of C collects all compo-nents M such that
3) ECtimesCmay simulates ECtimesM in the sense of (22)[only may transitions are allowed for ECtimesM ]
4) for any reachable state (qE qM ) of ECtimesM and (qE q)of ECtimesCmay such that (qE qM )le(qE q) and any ac-tion α isin Σout
M such that q αrarr then (qE qM )αminusrarrECtimesM
[must transitions are mandatory in ECtimesM ]
The first paragraph is a verbatim of the original definition ofModal Interfaces [166] Definition 7 introduces the two setsEC and MC whereas the classical theory of Modal Interfacesconsiders and develops a different notion of model (oftenalso called ldquoimplementationrdquo which is unfortunate) As forInterface Automata in Section VIII-B the handling of initialstate q0 is heterodox Our Definition 7 allows to cast ModalInterfaces in the framework of the meta-theory
To justify the existence and uniqueness of EC observe firstthat conditions (a) and (b) together imply that EC is receptiveCondition (2) follows from (a) Maximality in the sense of(22) follows from (b) and (c)
Consistency and Compatibility We begin with consis-tency Say that state q isin Q of C is consistent if q αrarr impliesq
α99K otherwise we say that it is inconsistent Assume thatC has some inconsistent state q isin Q meaning that for someaction α q αrarr holds but q
α99K does not hold By conditions 3)
and 4) of Definition 7 for any environment E and anyimplementation M of C no state (qE qM ) of EtimesM satisfies(qE qM )leq Hence all may transitions leading to q can bedeleted from C without changing MC Performing this makesstate q unreachable in Cmay thus Condition 2 of Definition 7is relaxed and the set of environments is possibly augmentedSince we have removed may transitions some more stateshave possibly become inconsistent So we must repeat thesame procedure Since the number of states is finite thisprocedure eventually reaches a fixpoint At fixpoint the setQ of states partition as Q = Qcon ]Qincon where Qincon
collects all states that were or became inconsistent as a resultof this procedure and Qcon only collects consistent statesIn addition since the fixpoint has been reached Qincon isunreachable from Qcon As a final step we delete Qincon andcall [C] the so obtained contract The following result holds
Lemma 6
RR ndeg 8147
Contracts for System Design 36
1) Modal Interface [C] satisfies
M[C]
=MC and E[C]supe EC (25)
where the inclusion is strict unless C possesses noinconsistent state
2) [C] offers the smallest set of environments among theModal Interfaces satisfying (25)
3) C is consistent and compatible if and only if Qcon 3 q0In the sequel unless otherwise specified we will only considerModal Interfaces that are consistent and compatible
Refinement and conjunction Conjunction and refinementare instantiated in a very elegant way in the theory of ModalInterfaces Contract refinement in the sense of the meta-theoryis instantiated by the effective notion of Modal refinement weintroduce now Roughly speaking modal refinement consistsin enlarging the must relation (thus enlarging the set of legalenvironments) and restricting the may relation (thus restrictingthe set of implementations) The formalization requires the useof simulation relations
For C a Modal Interface and qisinQ a state of it introducethe following may and must sets
may(q) = α isin Σ | q α99K
must(q) = α isin Σ | q αrarr
Definition 8 (modal refinement) Let Ci i = 1 2 be twoModal Interfaces and let qi be a state of Ci for i = 1 2Say that q2 refines q1 written q2 q1 if
may2(q2) sube may1(q1)must2(q2) supe must1(q1)
and forallα isin Σ
q1
α99K1 qprime1
q2α99K2 qprime2
=rArr qprime2 qprime1
Say that C2 C1 if q20 q10
The following result relates modal refinement with contractrefinement as defined in the meta-theory It justifies the con-sideration of modal refinement Its proof follows by direct useof Definition 7 and Lemma 6
Lemma 7 For C1 and C2 two Modal Interfaces the follow-ing two properties are equivalent(i) MC2
sube MC1and EC2
supe EC1 meaning that contract C2
refines contract C1 following the meta-theory(ii) [C2] [C1] ie [C2] refines contract [C1] in the sense of
modal refinementThe conjunction of two Modal Interfaces is thus the GreatestLower Bound (GLB) with respect to refinement order Itscomputation proceeds in two steps In a first step we wildlyenforce the GLB and compute a pre-conjunction by takingunion of must sets and intersection of may sets
Definition 9 The pre-conjunction43 C1andC2 of two ModalInterfaces is only defined if Σin
1 = Σin2 and Σout
1 = Σout2
43Pre-conjunction was originally denoted by the symbol amp in [164] [167][166]
and is given by Σin = Σin1 Σout = Σout
1 Q = Q1timesQ2q0 = (q10 q20) and its two transition relations are given by
must(q1 q2) = must1(q1) cupmust2(q2)may(q1 q2) = may1(q1) capmay2(q2)
(26)
Due to (26) C1andC2 may involve inconsistent states and thusin a second step the pruning introduced in Lemma 6 must beapplied
C1 and C2 = [C1andC2] (27)
Say that the two Modal Interfaces C1 and C2 are consistent44
if C1 and C2 is consistent in the sense of Lemma 6Parallel composition and quotient For Modal Interfaces
we are able to define both parallel composition and quotient inthe sense of the meta-theory As it was the case for InterfaceAutomata parallel composition for Modal Interfaces raisescompatibility issues and thus a two-step procedure is againfollowed for its computation
Definition 10 The pre-composition C1otimesC2 of two ModalInterfaces is only defined if Σout
1 capΣout2 = empty and is given by
Σout = Σout1 cup Σout
2 Q = Q1timesQ2 q0 = (q10 q20) and itstwo transition relations are given by
must(q1 q2) = must1(q1) capmust2(q2)may(q1 q2) = may1(q1) capmay2(q2)
(28)
Say that a state (q1 q2) of C1otimesC2 is illegal if
may1(q1) cap Σin2 6sube must2(q2)
or may2(q2) cap Σin1 6sube must1(q1)
Illegal states are pruned away from C1otimesC2 as follows Removefrom Cmay
1 times Cmay2 all transitions leading to (q1 q2) As
performing this may create new illegal states the same isrepeated until fixpoint is reached As a final step we delete thestates that are not may-reachable This finally yields C1otimesC2which no more possesses illegal states
The above construction is justified by the following resultLemma 8 C1otimesC2 as defined in Definition 10 instantiates
the contract composition from the meta-theory
Proof (sketch) E is an environment for C iff for any reachablestate (qE q1 q2) of E times Cmay
1 times Cmay2 we have
rs(qE ) sube must1(q1) capmust2(q2) (29)
where rs(q) the ready set of state q is the subset of actionsα such that q αminusrarr holds Let M1 be any implementation ofC1 and consider EtimesM1 We need to prove that EtimesM1 is anenvironment for C2 ie satisfies Condition 2 of Definition 7(we must also prove the symmetric property) Let (qE q1 q2)be a reachable state of EtimesM1timesCmay
2 We must prove
rs(qE ) cap rsM1 (q1 ) cap Σ in2 sube must2(q2)
By (29) it suffices that the following property holds
rsM1(q1 ) cap Σ in
2 sube must2(q2) (30)
44This is the usual wording in the literature
RR ndeg 8147
Contracts for System Design 37
However we only know that rsM1(q1 ) sube may1 (q1 ) Hence
to guarantee (30) we must prune away illegal pairs of statesTo this end we use the same procedure as before we makestate (q1 q2) unreachable in Cmay
1 timesCmay2 by removing all may
transitions leading to that state We complete the reasoning aswe did for the study of consistency 2
Definition 11 The quotient C1C2 of two modal interfacesC1 and C2 is only defined if Σin
1 cap Σout2 = empty and is defined
according to the following two steps procedure First defineC as follows Σout = Σout
1 Σout2 Q = Q1 times Q2 q0 =
(q10 q20) and its two transition relations are given by
must(q1 q2) = must1(q1)
may(q1 q2) = not [may1(q1) cap notmust1(q1)] cupnot [must1(q1) capmust2(q2)] cupnot [may1(q1) cupmay2(q2)]
These formulas may give raise to inconsistent states and thusin a second step we set C1C2 = [C]This definition is justified by the following result [166]showing that Definition 11 instantiates the meta-theory
Lemma 9 C1 otimes C2 C if and only if C2 CC1
Now it may be that (C1C2)otimesC2 possess illegal pairs of states(Definition 10) whence the following improvement whereΣout and Σin are as in Definition 11 and may and mustrefer to the quotient C1C2
Definition 12 Let Cprime be the interface defined on the samestate structure as C1C2 with however the following modali-ties
may prime(q1 q2) = may(q1 q2) cap(may2(q2) cup Σin
)must prime(q1 q2) = must(q1 q2) cup (Σout
1 cap Σout2 capmay2(q2))
define the compatible quotient written C1C2 to be thereduction of Cprime C1C2 = [Cprime]
This construction is justified by the following result
Lemma 10 The compatible quotient C1C2 solves thefollowing problem
max
C∣∣∣∣∣∣C has no inconsistent stateC otimes C2 has no illegal pair of statesC otimes C2 C1
Proof Denote C = C1C2 the compatible quotient definedabove The proof is threefold (i) C is proved to be a solutionof the inequality CotimesC2 C1 (ii) C is proved to be compatiblewith C2 and (iii) every Cprime satisfying the two conditions aboveis proved to be a refinement of C
Remark that reachable states in (C1C2)otimesC2 are of the form(q1 q2 q2) and that for every reachable state pair (q1 q2) inC1C2 state (q1 q2 q2) is reachable in (C1C2)otimes C2
(i) Remark that may prime sube may and must prime supe must HenceC1C2 C1C2 Since the parallel composition is monotonic(C1C2)otimes C2 (C1C2)otimes C2 C1
(ii) For every state (q1 q2 q2) reachable in (C1C2)otimes C2one among the following three cases occurs
bull Assume e isin Σin1 meaning that e is an input for both C2
and C1C2 Hence state (q1 q2 q2) is not illegal becauseof e
bull Assume e isin Σout1 cap Σout
2 Therefore e is an input of thecompatible quotient Remark must prime(q1 q2) sube may2(q2)Hence state (q1 q2 q2) is not illegal because of e
bull Assume e isin Σout1 capΣin
2 meaning that e is an output of thecompatible quotient Remark may prime(q1 q2) sube must2(q2)Therefore state (q1 q2 q2) is not illegal because of e
(iii) Let Cprimeprime be a modal interface such that C1C2 Cprimeprime C1C2 We shall prove that either Cprimeprime C1C2 or that Cprimeprime is notcompatible with C2 Remark that every reachable state (q1 q2)of C1C2 is related to exactly one state qprimeprime of Cprimeprime by the twomodal refinement relations Assume that Cprimeprime is not a refinementof C1C2 meaning that there exists related states (q1 q2)and qprimeprime such that may prime(q1 q2) sube may primeprime(qprimeprime) sube may(q1 q2)and must prime(q1 q2) supe must primeprime(qprimeprime) supe must(q1 q2) and eithermay prime(q1 q2) ( may primeprime(qprimeprime) or must prime(q1 q2) ) must primeprime(qprimeprime)Remark e isin Σin
1 implies that e isin may prime(q1 q2) iff e isinmay(q1 q2) and that e isin must prime(q1 q2) iff e isin must(q1 q2)Therefore the case e isin Σin
1 does not have to be considered
1) Assume there exists e such that e isin may primeprime(qprimeprime) may prime(q1 q2) Remark this implies e isin Σout
1 cap Σin2
meaning that e is an output of the compatible quo-tient Remark also that e 6isin must2(q2) Therefore state(qprimeprime q2) is illegal in Cprimeprime otimes C2
2) Assume there exists e such that e isin must prime(q1 q2) must primeprime(qprimeprime) Remark this implies e isin Σout
1 cap Σout2
meaning that e is an input of the compatible quotientRemark also that e isin may2(q2) Therefore state (qprimeprime q2)is illegal in Cprimeprime otimes C2
2
D Modal Interfaces with variable alphabet
As a general principle every relation or operator introducedin Section VIII-C (for Modal Interfaces with a fixed alphabetΣ) is extended to the case of variable alphabets by 1) extendingand equalizing alphabets and then 2) applying the relations oroperators of Section VIII-C to the resulting Modal InterfacesFor all frameworks we studied so far alphabet extension wasperformed using inverse projections see Section VII-C Forinstance this is the procedure used in defining the compositionof io-automata extending alphabets in io-automata is byadding at each state and for each added action a self-loop labeled with this action The very reason for using thismechanism is that it is neutral for the composition in thefollowing sense it leaves the companion io-automaton freeto perform any wanted local action
So for Modal Interfaces what would be a neutral procedurefor extending alphabets Indeed considering (26) or (28)
RR ndeg 8147
Contracts for System Design 38
yields two different answers namely
for (26)
α isin may1(q1) and α isin whatever2(q2)dArr
α isin whatever(q1 q2)
for (28)
α isin must1(q1) and α isin whatever2(q2)dArr
α isin whatever(q1 q2)
where ldquowhateverrdquo denotes either may or must Consequentlyneutral alphabet extension is by adding
bull may self-loops for the conjunction andbull must self-loops for the composition
The bottom line is that we need different extension proceduresThese observations explain why alphabet extension is properlyhandled neither by Interface Automata (see the last paragraphof Section VIII-B) nor by AG-contracts (see the end ofSection VII-C) These theories do not offer enough flexibilityfor ensuring neutral extension for all relations or operators
We now list how alphabet extension must be performed foreach relation or operator for two Modal Interfaces C1 and C2(the reader is referred to [166] for justifications) Alphabetsare extended as follows where Σprime supe Σ Define the strongextension of C to Σprime written CuarrΣprime
as follows
CuarrΣprime
(Σin)uarrΣprime
= Σin cup (Σprime Σ)
(Σout)uarrΣprime
= Σout
QuarrΣprime
= Q
quarrΣprime
0 = q0
mayuarrΣprime
= may cup (Σprime Σ)
mustuarrΣprime
= must cup (Σprime Σ)
(31)
In (31) the added may and must transitions are all self-loopsThe weak extension of C written CuArrΣprime
is defined using thesame formulas with the only following modification
CuArrΣprime
=
mustuArrΣprime= must
(32)
Observe that the strong extension uses the classical inverseprojection everywhere The weak extension however proceedsdifferently with the must transitions in that it forbids the legalenvironments to submit additional actions as its outputs
Using weak and strong alphabet equalization the relationsand operations introduced in Section VIII-C extend to variablealphabets as indicated now In the following formulas (ΣΣprime)is a pair such that Σ sube Σprime and (Σ1Σ2Σ) denotes a triplesuch that Σ = Σ1 cup Σ2 and satisfying the typing constraints
Σini = Σin cap Σi and Σout
i = Σout cap Σi for i = 1 2
It is understood that contract C has alphabet Σ and so on
Theorem 1 The following relations and operators
M prime |=M C = M prime |=M CuArrΣprime
Eprime |=E C = Eprime |=E CuarrΣprime
C1 C2 = C1 CuArrΣ2
C1 and C2 = CuArrΣ1 and CuArrΣ
2
C1 otimes C2 = CuarrΣ1 otimes CuarrΣ2
C1C2 = CuArrΣ1 CuarrΣ2
(33)
instantiate the meta-theory
Proof The first two formulas just provide definitions so noproof is needed for them Their purpose is to characterizethe weakly and strongly extended Modal Interfaces in termsof their sets of environments and implementations For bothextensions allowed output actions of the implementations areaugmented whereas mandatory actions are not For the weakextension legal environments are not modified in that noadditional output action is allowed for them In contrast for thestrong extension legal environments are allowed to submit anyadditional output action These observations justify the otherformulas 2
E Projecting and Restricting
A difficult step in the management of contracts was illus-trated in Figure 4 of Section IV-D It consists in decomposinga contract C into a composition of sub-contractsotimes
iisinI Ci C (34)
where sub-contract Ci has alphabet Σi = Σini ] Σout
i As aprerequisite to (34) the designer has to guess some topologicalarchitecture by decomposing the alphabet of actions of C as
Σ =⋃iisinI Σi Σi = Σin
i ] Σouti (35)
such that composability conditions regarding inputs and out-puts hold Guessing architectural decomposition (35) relies onthe designerrsquos understanding of the system and how it shouldnaturally decomposemdashthis typically is the world of SysMLFinding decomposition (34) is however technically difficultin that it involves behaviors It is particularly difficult if Cis itself a conjunction of viewpoints or requirements whichtypically occurs in requirements engineering see Section XI
C =andkisinK Ck (36)
The algorithmic means we develop in the remaining part ofthis section will be instrumental in solving (34) They will beused in the Parking Garage example of Section XI
Projecting over a subalphabet Projecting a contract overa sub-alphabet is the first natural tool for consideration Itis the dual operation with respect to alphabet extension thatwas developed in Section VIII-D Two projections can bedefined which can be seen as under- and over-approximationsrespectively by referring to the refinement order
RR ndeg 8147
Contracts for System Design 39
Let C be a Modal Interface with alphabet Σ = Σin cup Σout
and let Σprime sub Σ be a sub-alphabet Define respectively theabstracted projection and refined projection
CdarrΣprime= min Cprime | ΣCprime = Σprime and Cprime C
CdArrΣprime= max Cprime | ΣCprime = Σprime and Cprime C
(37)
where ldquominrdquo and ldquomaxrdquo refer to refinement order for ModalInterfaces with different alphabets see (33) The projectionCdArrΣprime
(respectively CdarrΣprime) is computed via the following on-
the-fly algorithm 1) Perform ε-closure on the set of states byconsidering unobservable the actions not belonging to Σprime andthen 2) Perform determinization by giving priority to mustover may (respectively to may over must) see Table VI fordetails Step 2) of the procedure for computing CdArrΣprime
is apossible source of inconsistencies
The abstracted projection CdarrΣprimeprovides a projected view
of a system-level contract over a small subset of actionsThe abstracted projection is thus a useful tool for contractexploration and debug It is not a synthesis tool however
This is in contrast to the refined projection CdArrΣprime which
satisfies the following result For any finite set Ci | i isin Iof Modal Interfaces with respective alphabets Σi we haveassuming that the left and right hand sides are properlydefinedmdasha typing property on input and output alphabetsotimes
iisinI
[Ci and
(andkisinK C
dArrΣi
k
)]
andkisinK Ck (38)
To show this by symmetry it is enough to show (38) withthe conjunction on the right hand side replaced by any singleCk for k selected from finite set K For any i isin I we haveCdArrΣi
k Ck and thus
Cprimei =def
[Ci and
(andkisinK C
dArrΣi
k
)] Ck (39)
holds for every i from which (38) follows Unfortunately therefined projection quite often gives raise to inconsistenciesIn addition the contract composition arising in left hand sideof (38) is subject to incompatibilities Informally said thistechnique works if the sub-systems are only ldquoloosely coupledrdquoso that neither inconsistencies nor incompatibilities occur Tomitigate this problem we propose an alternative technique forturning a conjunction into a composition
Restricting to a sub-alphabet Let C be a Modal Interfacewith alphabet Σ = Σin cup Σout and let (ΣprimeinΣprimeout) be twoinput and output sub-alphabets such that Σprimeout sube Σout SetΣprime = Σprimein]Σprimeout and define the restriction of C to Σprime denotedby CdarrΣprime via the procedure shown in see Table VII comparewith Table VI Observe that the states of the restriction cor-respond to sets of states of the original Modal Interface Therestriction aims at avoiding incompatibilities when consideringthe composition as the following lemma shows
Lemma 11 If C and CdarrΣprime are both consistent then so istheir compatible quotient CCdarrΣprime see Definition 12Proof Consider two alphabets Σ supe Σprime and a consistent C onalphabet Σ such that CdarrΣprime is also consistent The only casewhere quotient produces inconsistent states is whenever there
input CΣΣprime output Cprime
let proj(OpX) =if X has not been visitedthen
1 mark X visited2 for every α isin Σprime do
21 let Y = ε-closure(Σminus Σprime next(αX))22 let m = OpmC(q α) | q isin X23 add to Cprime a transition (Xα Y ) with modality m24 proj(Op Y )
done
let project(Op C) =1 let X0 = ε-closure(Σminus Σprime q0)2 set initial state of Cprime to X0
3 proj(OpX0)4 reduce Cprime5 return Cprime
let order (cannot maymustle) =
must le may
cannot le may
in CdarrΣprime= project(or C)
CdArrΣprime= project(and C)
Table VIALGORITHM FOR COMPUTING THE PROJECTIONS (37)
input CΣinΣoutΣprimeinΣprimeout output Cprime
let order(cannot maymustlein) = cannot lein may lein must
order(cannot maymustleout) =
must le may
cannot le mayin let rest(X) =
if X has not been visitedthen
1 mark X visited2 for every α isin Σprime do
21 let Y = ε-closure(Σminus Σprime next(αX))22 let m = OpmC(q α) | q isin X
where Op = if α isin Σprimein then orin else andout
23 add to Cprime a transition (Xα Y ) with modality m24 rest(Op Y )
done
let restrict(C) =1 let X0 = ε-closure(Σminus Σprime q0)2 set initial state of Cprime to X0
3 rest(OpX0)4 reduce Cprime5 return Cprime
Table VIIALGORITHM FOR COMPUTING THE RESTRICTION CdarrΣprime
exists an action e and a state pair (qR) in CCdarrΣprime such thate has modality must in q and does not have modality mustin R We prove by contradiction that no such reachable statepair (qR) and action e exist Remark that by definition of therestriction q isin R The restriction is assumed to be in reducedform meaning that it does not contain inconsistent states Twocases have to be considered
1) Action e has modality cannot in R Several sub-caseshave to be considered depending on the IO status ofe and on the fact that the reduction of the restrictionhas turned a may modality for e into a cannot In allcases action e has modality cannot or may in q which
RR ndeg 8147
Contracts for System Design 40
contradicts the assumption2) Action e has modality may in R This implies that e also
has modality may in q which contradicts the assumptionThis finishes the proof of the lemma 2
The following holds by Lemma 10
CdarrΣprime otimes (CCdarrΣprime ) CCCdarrΣprime has no inconsistent state
(CdarrΣprime CCdarrΣprime ) has no incompatible pair of states(40)
By Lemma 11 the only property for checking is the consis-tency of CdarrΣprime This is a significant improvement comparedto the issues raised by the refined projection as explained inthe paragraph following (39) Decomposition (40) can be usedwhile sub-contracting through the following algorithm
Algorithm 1 We are given some system-level contract CThe top-level designer guesses some topological architectureaccording to (35) Then she recursively decomposes
C = C0 C0darrΣ1otimes C1
C0darrΣ1otimes C1darrΣ2
otimes C2 C0darrΣ1
otimes otimes Cnminus1darrΣn
=def C(Σ1) otimes otimes C(Σn)
(41)
which ultimately yields a refinement of C by a compatiblecomposition of local sub-contracts 2
Discussion The operations of projection and restrictionthat we introduced here can probably be made be genericat the level of the meta-theory Observe however that suchoperations explicitly refer to the notion of sub-alphabet whichdoes not exist at the level of the meta-theory In additionModal Interfaces are the only concrete theory in which variablealphabets are properly supported For these two reasons wepreferred to develop these operations for Modal Interfacesonly
F Observers
Here we develop observers for a Modal InterfaceC = (ΣinΣout Q q0rarr 99K) having no inconsistent statemeaning that rarrsube99K With this consistency assumption inforce observers are then obtained as follows with referenceto Definition 2bull Condition 2 of Definition 7 boils down to requiring thatE times Cmust simulates E Simulation testing can thus beused to check this call bE
C(E) the corresponding verdictbull To test for implementations we first construct the max-
imal environment EC and apply testing to check sim-ulation of EC times M by Cmay call bM
C1 the corre-sponding verdict Performing this requires maintainingpairs of states ((qE qM ) (qE q)) in simulation relation(qE qM )le(qE q) For any such pair of states let bM
C2 de-note the verdict answering whether (qE qM )
αminusrarrECtimesMholds each time q αminusrarr holds for any α isin Σout Theoverall verdict for implementation testing is then
bMC1(EC timesM) and bM
C2(EC timesM)
Lemma 3 for generic observers specializes to the followingeffective semi-decision procedure
Lemma 121) If bE
C outputs F then C is incompatible2) If bM
C1 and bMC2 outputs F then C is inconsistent
G Bibliographical note
As explained in [72] [56] [127] [83] [165] [166] Inter-face Theories make no explicit distinction between assump-tions and guarantees
Interface Automata variants and extensions InterfaceAutomata were proposed by de Alfaro and Henzinger [72][70] [5] [54] as a candidate theory of interfaces In thesereferences Interface Automata focused primarily on parallelcomposition and compatibility Quoting [72]
ldquoTwo interfaces can be composed and are compatibleif there is at least one environment where they canwork togetherrdquo
The idea is that the resulting composition exposes as aninterface the needed information to ensure that incompatiblepairs of states cannot be reached This can be achieved byusing the possibility for a component to refuse selectedinputs from the environment at a given state [72] [56] Incontrast to our development in Section VIII-B no sets ofenvironments and implementations are formally associated toan Interface Automaton in the original developments of theconcept A refinement relation for Interface Automata wasdefined in [72]mdashwith the same definition as oursmdashit couldnot however be expressed in terms of sets of implementationsProperties of interfaces are described in game-based logicseg ATL [9] with a theoretical high-cost complexity Theoriginal semantics of an Interface Automaton was given by atwo-player game between an input player that represents theenvironment (the moves are the input actions) and an outputplayer that represents the component itself (the moves are theoutput actions) Despite the availability of partial results [83]the framework of Interface Automata lacks support for theconjunction of interfaces in a general setting and does notoffer the flexibility of modalities Sociable Interfaces [71]combine the approach presented in the previous paragraphwith interface automata [72] [73] by enabling communicationvia shared variables and actions45 First the same actioncan appear as a label of both input and output transitionsSecondly global variables do not belong to any specificinterface and can thus be updated by multiple interfaces Con-sequently communication and synchronization can be one-to-one one-to-many many-to-one and many-to-many Symbolicalgorithms for checking the compatibility and refinement ofsociable interfaces have been implemented in TICC [3]Software Interfaces were proposed in [55] as a pushdownextension of interface automata (which are finite state) Push-down interfaces are needed to model call-return stacks ofpossibly recursive software components This paper contains
45This formalism is thus not purely synchronous and is mentioned in thissection with a slight abuse
RR ndeg 8147
Contracts for System Design 41
also a comprehensive interface description of Tiny OS46 anoperating system for sensor networks Moore machines andrelated reactive synchronous formalisms are very well suitedto embedded systems modeling Extending interface theoriesto a reactive synchronous semantics is therefore meaningfulSeveral contributions have been made in this direction startingwith Moore and Bidirectional Interfaces [56] In Moore Inter-faces each variable is either an input or an output and thisstatus does not change in time Bidirectional Interfaces offeradded flexibility by allowing variables to change IO statusdepending on the local state of the interface Communicationby shared variable is thus supported and for instance allowsdistributed protocols or shared buses to be modeled In bothformalisms two interfaces are deemed compatible wheneverno variable is an output of both interfaces at the same timeand every legal valuation of the output variables of oneinterface satisfies the input predicate of the other The mainresult of the paper is that parallel composition of compatibleinterfaces is monotonic with respect to refinement Note thatMoore and Bidirectional Interfaces force a delay of at leastone transition between causally dependent input and outputvariables exactly like Moore machines In [83] the frame-work of Synchronous Interfaces is enriched with a notion ofconjunction (called shared refinement) This development wasfurther elaborated in [78] In Moore interfaces legal values ofthe input variables and consequent legal values of the outputvariables are not causally related Synchronous Relational In-terfaces [177] [178] have been proposed to capture functionalrelations between the inputs and the outputs associated toa component More precisely inputoutput relations betweenvariables are expressed as first-order logic formulas over theinput and output variables Two types of composition are thenconsidered connection and feedback Given two relationalinterfaces C1 and C2 the first one consists in connecting someof the output variables of C1 to some of the input variablesof C2 whereas feedback composition allows one to connectan output variable of an interface to one of its own inputsThe developed theory supports refinement compatibility andalso conjunction The recent work [112] studies conditions thatneed to be imposed on interface models in order to enforceindependent implementability with respect to conjunctionFinally [53] develops the concept of simulation distancesfor interfaces thereby taking robustness issues into accountby tolerating errors Finally Web services Interfaces wereproposed in [38]
The discussion of variants and extensions related to timeresources and probability is deferred to corresponding sec-tions
Modal Interfaces variants and extensions Propertiesexpressed as sets of traces can only specify what is forbiddenUnless time is explicitly invoked in such properties it isnot possible to express mandatory behaviors for designsModalities were proposed by Kim Larsen [130] [11] [46] asa simple and elegant framework to express both allowed and
46httpwwwtinyosnet
mandatory properties Modal Specifications basically consist inassigning a modality may or must to each possible transition ofa system They have been first studied in a process-algebraiccontext [130] [125] in order to allow for loose specificationsof systems Since then they have been considered for automata[128] and formal languages [163] [164] and applied to a widerange of application domains (see [11] for a complete survey)Informally a must transition is available in every componentthat realizes the modal specification while a may transitionneeds not be A modal specification thus represents a set ofmodelsmdashunfortunately models of modal transition systems areoften call ldquoimplementationsrdquo in the literature which is unfor-tunate in our context We prefer keeping the term ldquomodelrdquoand reserve the term ldquoimplementationrdquo for the entities intro-duced in Sections VIII-B and VIII-C Modal Specificationsoffer built-in conjunction of specifications [129] [167] Theexpressiveness of Modal Specifications has been characterizedas a strict fragment of the Hennessy-Milner logic in [46]and also as a strict fragment of the mu-calculus in [89] Theformalism is rich enough to specify safety properties as well asrestricted forms of liveness properties Modal Interfaces withthe right notion of compatibility were introduced in [165][166] and the problem of alphabet equalization with weakand strong alphabet extensions was first correctly addressed inthe same references In [23] compatibility notions for ModalInterfaces with the passing of internal actions are definedContrary to the approach reviewed before a pessimistic viewof compatibility is followed in [23] ie two Modal Interfacesare only compatible if incompatibility between two interfacescan occur in any environment A verification tool called MIOWorkbench is available The quotient of Modal Specificationswas studied in [124] [164] Determinism plays a role in themodal theory Non-deterministic Modal Interfaces have pos-sibly non-deterministic io-automata as class of componentsThey are much more difficult to study than deterministic onesand corresponding computational procedures are of highercomplexity A Modal Interface is said to be deterministic if itsmay-transition relation is deterministic For nondeterministicModal Interfaces modal refinement is incomplete [128] thereare nondeterministic Modal Interfaces C1 and C2 for whichthe set of implementations of C1 is included in that of C2without C1 being a modal refinement of C2 Hence refinementaccording to the meta-theory is not exactly instantiated butonly approximated in a sound way A decision procedure forimplementation inclusion of nondeterministic Modal Interfacesdoes exist but turns out to be EXPTIME-complete [12] [25]whereas the problem is PTIME-complete if determinism isassumed [167] [26] The benefits of the determinism assump-tion in terms of complexity for various decision problemson modal specifications is underlined in [26] The ldquomergerdquoof non-deterministic Modal Specifications regarded as partialmodels has been considered in [179] This operation consistsin looking for common refinements of initial specifications andis thus similar to the conjunction operation presented hereIn [179] [90] algorithms to compute the maximal commonrefinements (which are not unique when non-determinism is
RR ndeg 8147
Contracts for System Design 42
allowed) are proposed They are implemented in the toolMTSA [82] Assumeguarantee contracts viewed as pairs ofModal Specifications were proposed in [96] It thus com-bines the flexibility offered by the clean separation betweenassumptions and guarantees and the benefits of a modalframework Several operations are then studied refinementparallel composition conjunction and priority of aspects Thislast operation composes aspects in a hierarchical order suchthat in case of inconsistency an aspects of higher priorityoverrides a lower-priority contract The synthesis of ModalInterfaces from higher-level specifications has been studiedfor the case of scenarios In [173] Existential Live SequenceCharts are translated into Modal Specifications hence provid-ing a mean to specify modal contracts Regarding extensionsAcceptance Interfaces were proposed by J-B Raclet [163][164] Informally an Acceptance Interface consists of a set ofstates with for each state a set of ready sets where a readyset is a set of possible outgoing transitions from that stateIn intuitive terms an Acceptance Interface explicitly specifiesits set of possible models Acceptance Interfaces are moreexpressive than Modal Interfaces but at the price of a pro-hibitive complexity for the various relations and operators ofthe theory Modal Interfaces have been enhanced with markedstates by Caillaud and Raclet [27] Having marked statessignificantly improves expressiveness It is possible to specifythat some state must be reachable in any implementation whileleaving the particular path for reaching it unspecified As anexample of use Modal Interfaces with marked states have beenapplied in [4] to the separate compilation of multiple clockedsynchronous programs
The discussion of variants and extensions related to timeresources and probability is deferred to corresponding sec-tions
Features of our presentation The presentation of in-terface theories in this paper is new in many aspects Forthe first time all interface theories are clearly cast in theabstract framework of contracts following our meta-theory Inparticular the association to an interface C of the two sets ECandMC is new It clarifies a number of concepts In particularthe interface theories inherit from the properties of the meta-theory without the need for specific proofs The projectionand restriction operators for Modal Interfaces are new Castinginterface theories into the meta-theory was developed for thebasic interface theories only It would be useful to extend thisto the different variants and see what the benefit would beBenoicirct Caillaud has developed the MICA tool [49] whichimplements Modal Interfaces with all the operations andservices discussed in this section
IX PANORAMA TIMED INTERFACE THEORIES
In this section we develop an instance of an interface theoryfor timed systems This section is meant to be illustrative ofour approach to concrete instances of contract theories It doesnot claim to expose the good instance Our presentation buildson top of [35] To simplify the exposure we restrict ourselves
to the case of a fixed alphabet Σ As usual now we begin withthe component model
A Components as Event-Clock Automata
Timed Automata [6] constitute the basic model for systemsdealing with time and built on top of automata In wordstimed automata are automata enhanced with clocks Predicateson clocks guard both the states (also called ldquolocationsrdquo) andthe transitions Actions are attached to transitions that resultin the resetting of some of the clocks
Event-Clock Automata [7] [8] [35] form a subclass oftimed automata where clock resets are not arbitrary eachaction α comes with a clock hα which is reset exactlywhen action α occurs The interest of this subclass is thatevent-clock automata are determinizable which facilitates thedevelopment of a (modal) theory of contracts The definitionof event-clock automata requires some prerequisites
We are given an underlying finite set H of clocks A clockvaluation is a map ν H 7rarr R+ where R+ denotes the set ofnonnegative reals The set of all clock valuations is denotedby V We denote by 0 the clock valuation assigning 0 to allclocks and by ν + t the clock obtained by augmenting ν withthe constant t For ν a valuation the valuation ν[0hα] assigns0 to hα and keeps the valuation of other clocks unchanged
Clocks can be used to define guards The class of guardsconsidered by [35] consists of finite conjunctions of expres-sions of the form h sim n where h is a clock n is an integerand sim is one of the following relations ltle=ge gt Forg a guard write ν |= g to mean that valuation ν satisfiesguard g For N an integer G(H N) denotes the set of allguards over H involving only integers n lt N + 1 and wewrite G(H) = G(Hinfin)
Definition 13 An event-clock automaton over alphabet Σis a tuple M = (ΣinΣout Q q0 Nrarr) wherebull ΣinΣout Q q0 are as for io-automata elements of Q
are called locationsbull HΣ = hα | α isin Σ is the set of clocksbull N is a finite integer and rarrsube Q times G(HΣ N) times Σ times Q
is the transition relation write qgαminusrarr qprime to mean that
(q g α qprime) isinrarr
The semantics of M is a timed transition system with infinitestate space QtimesV defined as follows transition q
gαminusrarr qprime canfire from state (q ν) isin Q times V iff ν |= g as a result of thisfiring the clock hα is reset to zero thus resulting in the newstate (qprime ν[0hα]) isin Q times V In our Timed Interface theorycomponents are event-clock automata that are
1) deterministic in the following sense
forall(q α ν) isin Qtimes Σtimes V there is at mostone transition q
gαminusrarr qprime such that ν |= g(42)
2) receptive meaning that
forallq isin Qforallα isin Σin qTαminusrarr
holds where T denotes the trivial guard ldquotruerdquo
RR ndeg 8147
Contracts for System Design 43
Instead of further developing our theory we will show how totake advantage of previously developed theories by showingthat event-clock automata are finitely encoded by means of re-gion automata that we introduce next Fix bound N A regionis an equivalence class ϑ of clock valuations ν satisfying thesame set of guards from G(H N) Denote by Θ the set of allsuch regions (bound N is understood) For ϑ isin Θ consider
τ(ϑ) = ϑprimeprime | existνprimeprime isin ϑprimeprimeexistν isin ϑexistt ge 0 st νprimeprime = ν + t
which is the set of all regions that can be obtained from ϑ byletting time elapse Finally for ϑ a region and α an actionϑdarrα is the region obtained from ϑ by resetting clock hα Usingthese notations we associate to each event-clock automatonM = (ΣinΣout Q q0 Nrarr) a Region Automaton which isthe following finite state automaton
R [M ] =(Σin timesΘΣout timesΘ QtimesΘ (q00)rArr
)(43)
where the transition relation rArr is given by
(q ϑ)ϑrdquoα
===rArr (qprime ϑprime) iff
q gαrarr qprime withϑrdquo sube τ(ϑ) cap g andϑprime = ϑrdquodarrα
(44)
Vice-versa any Region Automaton R defines a uniqueevent-clock automaton M [R] by deducing from (44) theminimal guards associated to its transitions Starting from anevent-clock automaton M M [R [M ]] is related to M by astrengthening of its guards However it holds that47
R [M [R [M ]]] = R [M ] (45)
Under the above correspondence components in theevent-clock automaton domain are mapped to components inthe io-automaton domain
B Modal Event-Clock Specifications
In this section we develop the framework of con-tracts on top of our component model of deterministicevent-clock automata To simplify we only develop the caseof a fixed alphabet Σ
Definition 14 A Modal Event-Clock Specification (MECS)is a tuple C = (ΣinΣout Q q0rarr 99K) where ΣinΣoutQ q0 are as in Interface Automata and
rarr sube 99K sube Qtimes G(HΣ)times ΣtimesQ
Using the same construction as above MECS C induces aRegion Modal Event-Clock Specification (RMECS) denoted byR [C] which is a Modal Interface according to Definition 7Accordingly R [C] defines a pair (ER[C]
MR[C]) of sets of
io-automata and we finally define
(EC MC ) =def
(M[ER[C]
]M[MR[C]
])The map C 7rarr R [C] satisfies48
R [M [R [C]]] = R [C] (46)
47It is shown in [35] that M 7rarr R [M ] forms a Galois connection48Again it is a Galois connection [35]
This allows us to lift the contract theory of RMECS (whichare Modal Interfaces) to a contract theory of MECS Whilethis is conceptually elegant it is not efficient since movingfrom MECS to RMECS (from timed models to region models)is ExpTime which is costly To cope with this difficulty theauthors of [35] have provided direct cheap formulas expressedin the MECS domain These formulas provide a partial answerto the issue of complexity In particular the following lemmaholds that was stated and proved in [35]
Lemma 13 For C1 and C2 two MECS having identical inputand output alphabets define C1andC2 symbolically with rules ofthe following form
Glbmay q1
g1α99K qprime1 and q2
g2α99K qprime2
(q1 q2)g1andg2α99K (qprime1 q
prime2)
Glbmustleft q1
g1αrarr qprime1 and q2g2α qprime2
(q1 q2)g1andg2αrarr (qprime1 q
prime2)
where denotes ad libitumrarr or 99K and with Glbmustright
defined symmetrically (see [35] for the complete set of rules)Then we have
R [C1andC2] = R [C1]andR [C2] (47)
Inconsistent states for both sides of (47) correspond A similarlemma holds for contract quotient C1C2 Unfortunately thepruning of inconsistent states cannot be performed directlyin the MECS domain and mapping to regions is mandatoryNevertheless dedicated rules to handle directly inconsistentstates exist in the symbolic versions of the different relationsand operations on MECS As a result the computation ofthe regions is only mandatory when the designer aims atcleaning its contract by pruning the inconsistencies A similarlemma holds for contract composition C1otimesC2 Again pruningincompatible pairs of states cannot be performed directly inthe MECS domain and mapping to regions is mandatory49
C Bibliographical note
This note focuses on interface types of framework Thereader is referrect to the bibliographical note of Section VII-Gfor extensions of AG-contracts addressing time
A first interface theory able to capture the timing aspectsof components is Timed Interfaces [74] Timed Interfacesallows specifying both the timing of the inputs a componentexpects from its environment and the timing of the outputsit can produce Compatibility of two timed interfaces is thendefined and refers to the existence of an environment such thattiming expectations can be met The Timed Interface theoryproposed in [68] fills a gap in the work introduced in [74]by defining a refinement operation In particular it is shownthat compatibility is preserved by refinement This theoryalso proposes a conjunction and a quotient operation and is
49Authors of [35] do not mention this fact for the following reason Theydo not consider the issue of receptiveness for components and therefore theissue of compatibility does not arise
RR ndeg 8147
Contracts for System Design 44
implemented in the tool ECDAR [69] Timed SpecificationTheories are revisited from a linear-time perspective in [60]
The first timed extension of modal transition systems waspublished in [52] It is essentially a timed (and modal) versionof the Calculus of Communicating Systems (by Milner) Basedon regions tool support for refinement checking were imple-mented and made available in the tool EPSILON [95] Anothertimed extension of Modal Specifications was proposed in [36]In this formalism transitions are equipped with a modality anda guard on the component clocks very much like in timedautomata For the subclass of modal event-clock automataan entire algebra with refinement conjunction product andquotient has been developed in [33] [34]
Resources other than time were also consideredmdashwithenergy as the main target Resource Interfaces [57] can beused to enrich a variety of interface formalisms (InterfaceAutomata [72] AssumeGuarantee Interfaces [73] etc) witha resource consumption aspect Based on a two player game-theoretic presentation of interfaces Resource Interfaces allowfor the quantitative specification of resource consumptionWith this formalism it is possible to decide whether compo-sitions of interfaces exceed a given resource usage thresholdwhile providing a service expressed either with Buumlchi condi-tions or thanks to quantitative rewards Because resource usageand rewards are explicit rather then being defined implicitlyas solutions of numerical constraints this formalism doesnot allow one to reason about the variability of resourceconsumption across a set of logically correct models
X PANORAMA PROBABILISTIC INTERFACE THEORIES
Probabilistic systems are non-deterministic systems inwhich choice is controlled by random trial Such systems areuseful for many purposes ranging from physical or biologicalsystems to security protocols intrusion detection and up tosafety and reliability analyses in system design In this sectionas another illustration of our meta-theory we develop a simpleinstance of a probabilistic interface theory Again to simplifythe exposure we restrict ourselves to the case of a fixedalphabet Σ
A Components as Probabilistic Automata
We first introduce Probabilistic Automata with inputs andoutputs also called InputOutput Markov Decision Processesand then we motivate their use in safety analysis
Definition 15 A Probabilistic Automaton with inputs andoutputs (io-PA) is a tuple M = (ΣinΣout Q q0Πrarr)wherebull Σin and Σout are disjoint finite input and output alpha-
bets such that Σin cup Σout = Σbull Q is a finite set of states and q0isinQ is the initial state
we denote by Π(Q) the finite set of all probabilities overQ also called the probabilistic states
bull rarr sube Qtimes ΣtimesΠ(Q) is the transition relation we writeq
αminusrarr π to mean (q α π) isinrarr and q αminusrarr if q αminusrarr πholds for some π
bull In addition we require M to be deterministic in thefollowing sense for any pair (q α) isin Q times Σ q αminusrarr πand q αminusrarr πprime implies π = πprime
A run σ of M starts from initial state q0 and then progressesby a sequence of steps of the form q
αminusrarr π 7rarr qprime wheresupplementary transitions π 7rarr qprime are drawn at random byselecting a successor state qprime isin Q according to probabilityπ A strategy consists in fixing a function ϕ Q rarr Σand using it to select the next action Once a strategy hasbeen fixed jumping from a probabilistic state to the next onegives raise to a time-invariant Markov Chain whose invariantprobability can be computed or statistically estimated Whenall probabilistic states are Dirac measures δqprime selecting qprime asa next state with probability one io-PA M boils down to anio-automaton Thus io-PA subsume io-automata
Two io-PA M1 and M2 are composable if Σout1 capΣout
2 = emptyTwo composable io-PA M1 and M2 compose into M = M1timesM2 as follows
(q1 q2)αminusrarrM π1 otimes π2 iff
q1
αminusrarrM1π1 and
q2αminusrarrM2
π2(48)
where otimes denotes the product of two probabilities thus makingthe two components independent Parallel composition definedin this way has all the desired properties
Similarly the concept of simulation relation is easily de-rived from that of io-automata by preserving probabilitiesfor Mi i = 1 2 two io-PA and two states qi isin Qi say that q1
simulates q2 written q2le q1 if there exists a surjective mapf Q1 7rarr Q2 such that
forallα st q2αminusrarr2 π2 existπ1 isin Π(Q1)
dArr (49) q1αminusrarr1 π1
π2(qprime2) =sumf(qprime1)=qprime2
π1(qprime1)
π1(qprime1) gt 0rArr f(qprime1) le qprime1
Observe that since we consider only deterministic io-PAthere exists at most one π2 such that q2
αminusrarr2 π2 hence thereis no need to quantify over π2 in the precondition of (49) Inprobability theory relation π2(qprime2) =
sumf(qprime1)=qprime2
π1(qprime1) writesπ2 = f(π1) Say that M1 simulates M2 written M2leM1 ifq20leq10 Simulation relation is preserved by composition IfM2leM1 then every strategy ϕ2 Q2 7rarr Σ2 defined over M2
has its counterpart into a matching strategy ϕ1 Q1 7rarr Σ1
over M1 by setting ϕ1(q1) = ϕ2(f(q1)) For i = 1 2 letΩi = QN
i be the set of all sequences of states of Qi and let(ΩiPi) i = 1 2 be the two resulting probability spaces whenmatching strategies are used for M1 and M2 Then the mapf induces a measurable map ψ = (f f ) Ω1 7rarr Ω2 suchthat
intZ(ω2)dP2(ω2) =
intZ(ψ(ω1))dP1(ω1) In particular
the probability distributions with respect to P1 and P2 of anymeasurable function depending only on the successive actionsperformed are identical
The natural use of io-PAs for safetyreliability analysis isto capture faulty situations through states Component states
RR ndeg 8147
Contracts for System Design 45
are partitioned into safe states and faulty states that can beequipped with different fault labels (names of states can dothis no semantic adaptation is needed) The probabilistic partof io-PAs naturally captures the spontaneous occurrence offaults When in a faulty state a component outputs actionsthat can either be used to model fault propagation or maybe alarms for use in system supervision Input actions in afaulty state can be used to either model denial of servicefrom other components (thus resulting in a risk of movingto a faulty state) or may be reconfiguration actions Thusspontaneous occurrence of failures with fault propagation iscaptured by this framework To summarize io-PAs offer anatural framework in which to combine functional and safetyviewpoints
B Simple Modal Probabilistic Interfaces
By following the same steps as for Modal Interfacessee Definition 7 we can define Simple Modal ProbabilisticInterfaces as pairs C = (Cmay Cmust) of io-PAs There is nonew difficulty in doing this Expressiveness of this frameworkhowever is modest whence the attribute ldquosimplerdquo When usedin the context of safetyreliability analysis Simple ModalProbabilistic Interfaces support the specification of fault ac-commodation in systems For example one can specify abouta componentbull that it does not accommodate denial of service inputs
representing fault propagation are disallowed (ldquomust notoccurrdquo)
bull that it must be prepared to possible denial of serviceinputs representing fault propagation are allowed (ldquomustbe acceptedrdquo)
bull that it never generates spontaneous failures actions lead-ing to a probabilistic state from which a faulty state can beimmediately reached are disallowed (ldquomust not occurrdquo)
bull that spontaneous failures are unavoidable actions leadingto a probabilistic state from which a faulty state can beimmediately reached are allowed (ldquomust be acceptedrdquo)
One could argue that io-PA by themselves offer a similarexpressiveness by playing with probabilities Simple ModalProbabilistic Interfaces however offer the full algebra ofcontracts which io-PA donrsquot
C Bibliographical note
This note focuses on interface types of framework Thereader is referred to the bibliographical note of Section VII-Gfor extensions of AG-contracts addressing probability
Exactly like the Interval Markov Chain (IMC) for-malism [116] they generalize Constraint Markov Chains(CMC) [50] are abstractions of a (possibly infinite) sets ofDiscrete Time Markov Chains Instead of assigning a fixedprobability to each transition transition probabilities are keptsymbolic and defined as solutions of a set of first orderformulas Variability across implementations is made possiblenot only with symbolic transition probabilities but also thanksto the labelling of each state by a set of valuations or setsof atomic propositions This allows CMCs to be composed
thanks to a conjunction and a product operators While theexistence of a residuation operator remains an open problemCMCs form an interface theory in which satisfaction andrefinement are decidable and compositions can be computedusing quantifier elimination algorithms In particular CMCswith polynomial constraints form the least class of CMCsclosed under all composition operators Abstract ProbabilisticAutomata (APA) [79] is another specification algebra withsatisfaction and refinement relations product and conjunctioncomposition operators Despite the fact that APAs generalizeCMCs by introducing a labeled modal transition relationdeterministic APAs and CMCs coincide under the mild as-sumption that states are labeled by a single valuation Forboth formalisms parallel composition is restricted to non-interacting components since alphabets of actions must bedisjoint
Our formalism of Simple Modal Probabilistic Interfaces ex-hibits the whole contract algebra Regarding limitations unlikeIMC CMC and APA this model does not allow for specifyingfamilies of transition probabilities and hence it cannot helpfor quantitative reasoning about reliability analysis
XI THE PARKING GARAGE AN EXAMPLE INREQUIREMENTS ENGINEERING
In this section we develop the parking garage exampleintroduced in Section IV-C Some of the material is repeatedfor better readability Despite being simple and small this ex-ample quickly becomes complex for reasons that are intrinsicto the formal management of requirements The MICA tooldeveloped by Benoicirct Caillaud was used to develop it [49]
Requirements are written in constrained English languageand then translated into Modal Interfacesmdashwhile the pre-sented translation is manual automatic translation can beenvisioned50 Once this is completed contracts are formallydefined and the apparatus of contracts can be used In par-ticular important properties regarding certification can beformally defined and checked eg consistency compatibilitycorrectness and completeness In addition support is providedfor turning top-level requirements into an architecture of sub-systems each one equipped with its own requirements Thelatter can then be submitted to independent suppliers forfurther development
A The contract framework
We shall use Modal Interfaces (with variable alphabet) asdeveloped in Sections VIII-C and subsequent ones There arethree main reasons for this choice
1) By offering the may and must modalities Modal Inter-faces are well suited to express mandatory and optionalbehaviors in the specification which we consider impor-tant for requirements engineering
50In fact the contract specification languages proposed in the projectsSPEEDS [29] and CESAR (httpwwwcesarprojecteu) are examples oftranslations from a constrained English language to a formal models ofcontracts similar to Modal Interfaces
RR ndeg 8147
Contracts for System Design 46
2) Being large sets of requirements structured into chaptersrequirements documents are a very fragmented style ofspecification Only Modal Interfaces offer the neededsupport for an accurate translation of concepts such asldquoset of requirementsrdquo ldquoset of chaptersrdquo together with aqualification of who is responsible for each requirement(the considered component or sub-system versus itsenvironment)
3) As we shall see at the top-level conjunction prevailsHowever as soon as the designer refines the top-levelrequirements into an architecture of sub-systems com-position enters the game Turning a conjunction of top-level requirements into a composition of sub-systemsspecifications thus becomes a central task Only ModalInterfaces provide significant assistance for this
Overall the problem considered in claim 3) can be stated asfollows The designer begins with some system-level contractC which is typically specified as a conjunction of viewpointsandor requirements The designer guesses some topologicalarchitecture by decomposing the alphabet of actions of C as
Σ =⋃iisinI Σi Σi = Σin
i ] Σouti (50)
such that composability conditions regarding inputs and out-puts hold Once this is done we expect our contract frameworkto provide help in generating a decomposition of C asotimes
iisinI Ci C (51)
where sub-contract Ci has alphabet Σi = Σini ] Σout
i Guess-ing architectural decomposition (50) relies on the designerrsquosunderstanding of the system and how it should naturallydecomposemdashthis typically is the world of SysML Findingdecomposition (51) is however technically difficult in that itinvolves behaviors The algorithmic means that were presentedin Section VIII-E provide the due answer In this ParkingGarage example we will use both the abstracted projectionand the restriction that were developed in that section
B Top level requirements
In this section we begin with the top-level requirementsThe system under specification is a parking garage subjectto payment by the user At its most abstract level the re-quirements document comprises the different chapters gatepayment and supervisor see Table VIII The gate chapterwill collect the generic requirements regarding entry and exitgates These generic requirements will then be specialized forentry and exit gates respectively
0
gate_close
1gate_opengate_close
vehicle_passgate_open
Figure 7 Requirement Rg1 specified as an io-automaton Prefix ldquordquoindicates an input and prefix ldquordquo indicates an output
gateRg1ldquovehicles shall not pass when gate is closedrdquo see Fig 7Rg2 after vehicle_pass vehicle_pass is forbiddenRg3 after gate_open gate_open is forbidden and
after gate_close gate_close is forbiddenpaymentsupervisor
Table VIIITHE TOP-LEVEL SPECIFICATION WITH CHAPTER gate EXPANDED
REQUIREMENTS WRITTEN IN italics ARE ASSUMPTIONS UNDER WHICHgate SHOULD OPERATE
Focus on the ldquogaterdquo chapter It consists of the three re-quirements shown on Table VIII Requirement Rg1 is bestdescribed by means of an io-automaton shown in Figure 7mdashwe provide an informal textual explanation for it betweenquotes51 The other two requirements are written using con-strained natural language which can be seen as a boilerplatestyle of specification Prefix ldquordquo indicates an input and prefixldquordquo indicates an output
The first two requirements are not under the responsibilityof the system since they rather concern the car driver Thus itdoes not make sense to include them as part of the guaranteesoffered by the system Should we remove them This wouldbe problematic If drivers behave the wrong way unexpectedthings can occur for sure The conclusion is that 1) we shouldkeep requirements Rg1 and Rg2 and 2) we should handlethem differently than Rg3 which is a guarantee offered by thesystem Indeed Rg1 and Rg2 are assumptions under whichthe gate operates as guaranteed In the sequel assumptions arewritten in italics
So far we have specified gate as a list of requirementsRequirement Rg1 specified as an io-automaton can be con-sidered formal Requirements Rg2 and Rg3 are formulatedin constrained natural language and are ready for subsequentformalization eg as io-automata Are we done Not yetWe need to give a formal meaning to what it means to havea collection of requirements and what it means to distinguishassumptions from guarantees The contract framework wedevelop next will provide support for this
C Formalizing requirements as contracts
We shall use Modal Interfaces (with variable alphabet) asdeveloped in Sections VIII-C and subsequent ones Thuswe first need to explain how the specification of ldquogaterdquo inTable VIII translates into Modal Interfaces
We first observe that each requirement Rgj of Table VIIIis a sentence that can be formalized as an io-automaton see
51 We take the convention that the variables of the resulting io-automatonare those mentioned in the text of the requirement Some adjustment is neededto this convention however as exemplified by Figure 7 Suppose that somerequirement says ldquogate_open never occursrdquo This is translated by havingno mention of gate_open in the corresponding io-automaton To expressthis ldquonegativerdquo fact we must keep track of the fact that gate_open belongsto the alphabet of actions of the io-automaton Thus when performing thetranslation the explicit list of inputs and outputs should be explicitly givenTo avoid such additional notational burden we have cheated by omitting thisunless necessary
RR ndeg 8147
Contracts for System Design 47
Figure 7 for such a formalization of requirement Rg1 Ac-cordingly each chapter D = gatepaymentsupervisorof Table VIII is structured as a pair
D = ((A1 Am) (G1 Gn)) (52)
where the Ais (the assumptions) and the Gjs (the guarantees)are io-automata in which all involved actions possess thesame status (input or output) throughout all Ais and Gjs Thetranslation of a specification of the form (52) into a ModalInterface is performed by applying the following two series ofrules
Rules 1 We adopt the following rules for the translation ofguarantees (in the form of io-automata) into Modal InterfacesRG
1 Unless otherwise explicitly stated transitions labeledby an output action of the considered system are givena may modality the rationale for doing this is that thedefault semantics for guarantees is ldquobest effortrdquo A mustmodality is assigned if the requirement specifies itmdashegby having a ldquomustrdquo in the sentence
RG2 Transitions labeled by an input action of the considered
system are given a must modality the rationale for doingthis is that as part of its guarantees the component mustnot refuse an input that is ldquolegallyrdquo submitted by theenvironment
RG3 Guarantees in a same requirements chapter D combine
by conjunctionApplying Rules 1 to the set of guarantees of D yields thecontract encoding these guarantees denoted by GD 2
Performing this for the single guarantee Rg3 of gate yieldsthe Modal Interface shown in Figure 8
0 1gate_opengate_close
0 1gate_opengate_close
Figure 8 Translating the guarantee Rg3 of gate as an io-automaton (top)and then as a Modal Interface Ggate (bottom) using Rules 1
Rules 2 We adopt the following rules for the translationof assumptions (in the form of io-automata) into ModalInterfacesRA
1 We exchange the status inputoutput in every assump-tion thus taking the point of view of the environment
RA2 Having done this we apply Rules 1 to the assumptions
So far this yields a draft Modal Interface A that must besatisfied by every environment
RA3 This is not enough however as we really want envi-
ronments that submit all legal stimuli To ensure this wesimply turn in A all may transitions to must transitionswhich yields A
Applying Rules 2 to the set of assumptions of D yields theModal Interface AD encoding these assumptions 2
Performing this for the assumptions Rg1 and Rg2 of gateyields the Modal Interface shown in Figure 9
1 0
gate_close
1gate_opengate_close
gate_openvehicle_pass
2 0
gate_open
1vehicle_passgate_open
3 (11)
gate_close
(10)
gate_opengate_closevehicle_pass
gate_open
4 0
gate_close
1gate_openvehicle_passgate_close
gate_open
Figure 9 Translating the assumptions of gate as a Modal Interface Agate
using Rules 2 1 translation of Rg1 2 translation of Rg2 3 the resultingconjunction 4 the final result after applying rule RA
3 and renaming the states
So far we have represented any chapter D of the require-ments document as a pair of Modal Interfaces (AD GD) withmirroring inputoutput statuses for their actionsmdashevery inputof AD is an output of GD and vice-versa It is the merit ofModal Interfaces to allow for a direct representation of thispair of assumption and guarantee in the form of a single ModalInterface by using the following formula for A and G twoModal Interfaces with mirroring inputoutput statuses for theiractions
(AG) is represented by the quotient (AotimesG)A (53)
which is the contract characterizing the components thatimplement G in the context of A see Section V-E Performingthis for the whole chapter gate yields the Modal Interfaceshown in Figure 10 Some comments are in order regardingthis Modal Interfacebull Regarding the guarantees offered by the component
Allowed outputs possess a may modality which reflectsthat Guarantees specify what the component may deliverOther actions are forbidden
bull Regarding the context of operation Legal inputs to thegate (eg vehicle_through when exiting state ldquo1rdquo) havea must modality This complies with the intuition that
RR ndeg 8147
Contracts for System Design 48
gate(x) where x isinentry exitRg1(x) ldquovehicles shall not pass when x_gate is closedrdquo see Fig 7Rg2(x) after vehicle_pass vehicle_pass is forbiddenRg3 after x_gate_open x_gate_open is forbidden and after x_gate_close x_gate_close is forbidden
paymentRp1 ldquouser inserts a coin every time a ticket is inserted and only thenrdquo Fig omittedRp2 ldquouser may insert a ticket only initially or after an exit ticket has been issuedrdquo Fig omittedRp3 ldquoexit ticket is issued after ticket is inserted and payment is made and only thenrdquo Fig omitted
supervisorRg1(entry)Rg1(exit)Rg2(entry)Rg2(exit)Rs1 initially and after entry_gate close entry_gate open is forbiddenRs2 after ticket_issued entry_gate open must be enabledRs3 ldquoat most one ticket is issued per vehicle entering the parking and tickets can be issued only if requested
and ticket is issued only if the parking is not fullrdquo see Fig 12Rs4 ldquowhen the entry gate is closed the entry gate may not open unless a ticket has been issuedrdquo Fig omittedRs5 ldquothe entry gate must open when a ticket is issuedrdquo Fig omittedRs6 ldquoexit gate must open after an exit ticket is inserted and only thenrdquo Fig omittedRs7 ldquoexit gate closes only after vehicle has exited parkingrdquo Fig omitted
Table IXREQUIREMENTS FOR THE TOP-LEVEL
0
1vehicle_pass
2gate_open
vehicle_passgate_closegate_open
gate_close3vehicle_pass
gate_close
vehicle_pass
Figure 10 Chapter gate of the top-level requirements document translatedinto a Modal Interface Cgate
the component should not refuse legal stimuli from itsenvironment Violation of the contract by its environmentoccurs when an illegal input is submitted by the environ-ment (vehicle_through when exiting state 0 or state 3) Asa consequence the whole contract gets relaxed which isreflected by the move to the special state ldquo2rdquo from whichany action is allowedmdashsuch a state is often called a ldquotoprdquostate Note that this top state resulted from computing thequotient
The same procedure applies to all chapters gate paymentand supervisor of the top-level textual specification shownin Table IX (it is an expansion of Table VIII) In particu-lar the Modal Interfaces encoding chapters payment andsupervisor of the top-level are displayed in Figures 11 to 13Figure 13 showing the contract associated to the supervisor isunreadable and the reader may wonder why we decided to putit here We indeed wanted to show that when contract designis performed formally and carefully top-level contracts rapidlybecome complex even for modest sets of requirements So theformal management of requirements and their translation intoformal contracts must be tool-assisted
Finally the whole top-level contract C is the conjunctionof the contracts representing chapters gate payment and
supervisor of the top-level requirements document
C = Cgate and Cpayment and Csupervisor (54)
Owing to the complexity of Csupervisor shown in Figure 13we do not show the Modal Interface C formalizing the fulldocument Nevertheless the latter was generated and can thenbe exploited as we develop next The above specificationonly covers the functional viewpoint of the system Otherviewpoints might be of interest as well eg regarding timingbehavior and energy consumption They would be developedwith the same method and combined to the above contract Cusing conjunction
D Sub-contracting to suppliers
In this section we apply the technique developed in Sec-tion VIII-E for generating an architecture of sub-systems withtheir associated sets of requirements Each sub-system canthen be submitted for independent development to a differentsupplier
The duty of the designer is to specify an architecture ldquoagravela SysMLrdquo as shown on Figure 14 Some comments arein order regarding this architecture The considered instanceof a parking garage consists of one entry gate one exitgate and one payment machine Compare with the top-levelspecification of Table IX The latter comprises a generic gatea payment machine and a supervisor each one with its setof requirements In contrast the architecture of Figure 14involves no supervisor The supervisor is meant to be dis-tributed among the two gates The architecture of Figure 14seems to be very loosely coupled First the PaymentMachineseems to be totally independent In fact the ticket that isinserted in the exit gate must coincide with the one issued bythe PaymentMachine It turns out that this reflects a missingassumption regarding the environment of the system (namelythe user of the parking) Then the two gates seem to have the
RR ndeg 8147
Contracts for System Design 49
0 1ticket_insert_payment 2
coin_insert_paymentticket_insert_payment
3
coin_insert_payment
ticket_insert_paymentcoin_insert_paymentexit_ticket_issue
exit_ticket_issueticket_insert_paymentcoin_insert_payment
Figure 11 Chapter payment of the top-level requirements documenttranslated into a Modal Interface Cpayment
(a0)
vehicle_exit (b0)request_enter
(a1)vehicle_enter
request_entervehicle_exit
ticket_issue
vehicle_enter
vehicle_exit(b1)
request_enter
(a2)
vehicle_enter
vehicle_exitticket_issuerequest_enter
vehicle_enter
vehicle_exit
vehicle_enter
(b2)request_enter
vehicle_exit
vehicle_enter
request_enter
Figure 12 Modal Interface for Rs3
0
entry_gate_close
1
exit_ticket_insert
7
vehicle_entervehicle_exit
44
request_enter
entry_gate_closeexit_ticket_insert
2
exit_gate_open
vehicle_entervehicle_exit
43
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
3
request_enter
vehicle_enter
75
vehicle_exit
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
4
ticket_issue
vehicle_enter
72
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
vehicle_enter
5
vehicle_exit
11
entry_gate_open
exit_gate_openexit_ticket_insertexit_gate_closeentry_gate_closevehicle_enterentry_gate_openvehicle_exitrequest_enter
ticket_issue
vehicle_entervehicle_exit
exit_ticket_insertrequest_enter
6
exit_gate_open
8
exit_gate_close
59
entry_gate_open
vehicle_enter
vehicle_exit exit_ticket_insertrequest_enter
exit_gate_open
exit_gate_close
58
entry_gate_open
vehicle_entervehicle_exit
request_enter
9
exit_ticket_insert
45
entry_gate_open
exit_gate_open
vehicle_entervehicle_exitexit_ticket_insert
request_enter
10
entry_gate_open
vehicle_exit
entry_gate_openexit_ticket_insertrequest_enter
exit_gate_open
entry_gate_close
47
ticket_issue
68
vehicle_enter
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insertrequest_enter
12
ticket_issue
69
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
49
vehicle_enter
13
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
19
request_enter
77
entry_gate_open
50
vehicle_exit
vehicle_enter
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
20
entry_gate_open
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
21
ticket_issue
34
vehicle_enter
71
entry_gate_close
vehicle_exit
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
22
vehicle_enter
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
23request_enter
84
entry_gate_open
127
vehicle_exit
vehicle_enter
exit_ticket_insertrequest_enter
exit_gate_open
24
vehicle_exit
33
entry_gate_open
vehicle_entervehicle_exit
exit_ticket_insertrequest_enter
16
exit_gate_open
17
exit_gate_close
25
entry_gate_open
vehicle_enter
vehicle_exit
exit_gate_openexit_ticket_insertrequest_enter
exit_gate_close
26
entry_gate_open
vehicle_entervehicle_exit
request_enter
18
exit_ticket_insert
114
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
80
entry_gate_open
vehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
81ticket_issue
79
entry_gate_close
99
vehicle_enter
vehicle_exit
exit_gate_open
entry_gate_open
exit_ticket_insertrequest_enter
82vehicle_enter
vehicle_entervehicle_exitexit_gate_open
exit_ticket_insert
31
request_enter
83
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
32
entry_gate_open
vehicle_exitexit_ticket_insertrequest_enter
entry_gate_open
exit_gate_open
vehicle_enter
91
entry_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
vehicle_enter
92
entry_gate_close
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
35
request_enter
101
entry_gate_close
entry_gate_open
60
vehicle_exit
vehicle_enter
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
36
vehicle_exit
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
37
exit_gate_open
125
exit_gate_close
93
entry_gate_close
entry_gate_open
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
exit_gate_open
38
vehicle_exit
exit_gate_close
94
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
39
exit_gate_open
40
exit_gate_close
entry_gate_close
entry_gate_open
vehicle_enter
ticket_issue
vehicle_exitexit_ticket_insertrequest_enter
exit_gate_open
exit_gate_close
entry_gate_open
73entry_gate_close
vehicle_entervehicle_exit
ticket_issue
request_enter
41
exit_ticket_insert
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
ticket_issue
entry_gate_open
exit_ticket_insertrequest_enter
42
exit_gate_open
entry_gate_close
entry_gate_close
ticket_issue
vehicle_enter
entry_gate_open
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
exit_gate_open vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
exit_ticket_insert
entry_gate_close
request_enterentry_gate_open
46
ticket_issue
124
vehicle_enter
vehicle_exit
entry_gate_open
request_enter
exit_ticket_insert
126
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
48
vehicle_enter
vehicle_entervehicle_exit
exit_gate_open
request_enterexit_ticket_insert
113
entry_gate_open
vehicle_exit
request_enter
exit_ticket_insertentry_gate_open
exit_gate_open
105
entry_gate_close
vehicle_enter
request_enter
vehicle_enter
exit_ticket_insert
entry_gate_openexit_gate_open
56
vehicle_exit
74entry_gate_close
vehicle_exit
exit_ticket_insertentry_gate_open
57
exit_gate_open
entry_gate_close
123
exit_gate_close
vehicle_enter
request_enter
vehicle_exit
exit_ticket_insert
entry_gate_openexit_gate_open
request_enter
76
entry_gate_close
exit_gate_close
61
vehicle_enter
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
14
ticket_issue
entry_gate_close
vehicle_enter
vehicle_exit
exit_gate_closeentry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
15
vehicle_enter
vehicle_exit
vehicle_enter
request_enter
exit_gate_openexit_ticket_insert
vehicle_exit
86
entry_gate_open
exit_gate_close
vehicle_entervehicle_exit
request_enter
entry_gate_openexit_ticket_insert
51
exit_gate_open
52
exit_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit
exit_ticket_insertexit_gate_open exit_gate_close
vehicle_entervehicle_exit
request_enter
53
exit_ticket_insert
entry_gate_open
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
54
exit_gate_open
67entry_gate_open
request_enter
vehicle_enter
vehicle_exit
exit_ticket_insertexit_gate_open
55
entry_gate_open
entry_gate_close
request_enter
vehicle_exit
exit_ticket_insert
entry_gate_openexit_gate_open
vehicle_enter
vehicle_enter
entry_gate_open
exit_ticket_insertexit_gate_open
70
request_enter
62
vehicle_exit
entry_gate_close
vehicle_enter
ticket_issue
entry_gate_open
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
entry_gate_close
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_exit
vehicle_entervehicle_exit
ticket_issue
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_close
exit_gate_open
vehicle_enter
ticket_issue
exit_gate_close
vehicle_exit exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
entry_gate_open
exit_ticket_insert
63
exit_gate_open
64exit_gate_close
entry_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit exit_ticket_insertexit_gate_open
exit_gate_close
entry_gate_close
entry_gate_close
vehicle_entervehicle_exit
request_enter
65
exit_ticket_insert
entry_gate_open
entry_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
66exit_gate_open
entry_gate_open
entry_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit
exit_ticket_insertexit_gate_open
entry_gate_close
vehicle_exit
request_enter
exit_gate_open
exit_ticket_insertentry_gate_open
vehicle_enter
vehicle_entervehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insert
78
request_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
vehicle_enter
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
vehicle_exit
exit_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
exit_gate_close
vehicle_enter
request_enter
vehicle_exit
entry_gate_closeexit_gate_openexit_ticket_insert
entry_gate_close
vehicle_exit
request_enter
exit_ticket_insert
entry_gate_open
vehicle_enter
vehicle_entervehicle_exit
exit_ticket_insert
request_enter
104entry_gate_close
112entry_gate_open
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enter
95entry_gate_close
entry_gate_openvehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
exit_ticket_insert
entry_gate_close
request_enterentry_gate_open
115
ticket_issue
98
vehicle_enter
vehicle_exit
exit_ticket_insert
entry_gate_open
request_enter
116
vehicle_enter
vehicle_entervehicle_exit
exit_ticket_insert
30
request_enter
107
entry_gate_open
vehicle_entervehicle_exit
exit_ticket_insert
request_enter97
entry_gate_open
vehicle_exit
exit_ticket_insert
request_enterentry_gate_open
vehicle_enter
96entry_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
89
request_enter
106
entry_gate_closeentry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insert
90
request_enter
100
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
entry_gate_closeexit_ticket_insertrequest_enter
exit_gate_open
vehicle_enter
entry_gate_closeexit_gate_openexit_ticket_insertrequest_enter
vehicle_exit
vehicle_entervehicle_exit
ticket_issue
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_close
exit_gate_open
vehicle_enter
ticket_issue
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
vehicle_enter
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
102
vehicle_exit
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
103
exit_gate_open
exit_gate_close
vehicle_enter
vehicle_exit
request_enterexit_ticket_insert
entry_gate_closeexit_gate_open
exit_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
request_entervehicle_enter
entry_gate_closeexit_ticket_insertentry_gate_open
exit_gate_open
request_enter
vehicle_enter
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insert
85
vehicle_exit
vehicle_exit
entry_gate_close
entry_gate_openexit_ticket_insert
exit_gate_open
request_enter
117
vehicle_enter
exit_gate_close
vehicle_exit
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insert
request_enter
87
vehicle_enter
exit_gate_close
exit_gate_close
entry_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
27
ticket_issue
vehicle_enter
vehicle_exit
exit_gate_close
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
28
vehicle_enter
vehicle_exit
vehicle_enter
exit_gate_close
exit_ticket_insertexit_gate_open
29request_enter
111
entry_gate_open
vehicle_exit
vehicle_enter
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
exit_gate_open
109
entry_gate_open
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
vehicle_enter
108
entry_gate_close
vehicle_exit
vehicle_enter
exit_gate_close
exit_gate_openexit_ticket_insert
88
request_enter
vehicle_exit
110
entry_gate_close
entry_gate_open
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
exit_gate_close
entry_gate_close
vehicle_entervehicle_exit
entry_gate_open
exit_ticket_insert
request_enter
entry_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enterentry_gate_close
vehicle_enter
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
exit_gate_close
entry_gate_close
entry_gate_open
exit_ticket_insert
exit_gate_open
vehicle_enter
request_enter
vehicle_exit
exit_gate_close
entry_gate_close
entry_gate_open
exit_ticket_insertexit_gate_open
vehicle_enter
vehicle_exit
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
exit_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enter
entry_gate_close
vehicle_exit
request_enter
vehicle_enterentry_gate_close
exit_ticket_insert
entry_gate_openexit_gate_open
exit_gate_close
vehicle_exit
request_enter
vehicle_enter
exit_ticket_insert
entry_gate_close
entry_gate_open
vehicle_exit
exit_gate_close
entry_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
128ticket_issue
vehicle_enter
vehicle_exit
exit_gate_close
exit_gate_open
entry_gate_open
exit_ticket_insertrequest_enter
129vehicle_enter
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insert
130
request_enter
122entry_gate_open
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
120
entry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
vehicle_enter
119entry_gate_close
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insert
118
request_enter
121
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_gate_close
entry_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
exit_gate_closeexit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
exit_gate_open
exit_gate_close
request_enter
exit_ticket_insertentry_gate_close
vehicle_exit
exit_gate_open
exit_gate_close
request_enter
vehicle_enter
entry_gate_close
exit_ticket_insertentry_gate_open
vehicle_entervehicle_exit
request_enter
exit_gate_open
entry_gate_open
exit_ticket_insert
exit_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
entry_gate_open
vehicle_exit
exit_ticket_insert
request_enter
vehicle_enter
entry_gate_closeentry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
vehicle_enter
exit_ticket_insertrequest_enter
entry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
entry_gate_close
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_open
Figure 13 Chapter supervisor of the top-level requirements documenttranslated into a Modal Interface Csupervisor for a capacity of two for theparking garage
shared input ldquovehicle exitrdquo as their only interaction But thisshared input is involved in requirement Rs3 which forbidsthe entry if the parking is full
In Figure 15 we show the result of applying to the ar-chitecture of Figure 14 the Algorithm 1 developed in Sec-tion VIII-E which yields by construction a refinement of thetop-level contract C by a decomposition into local contracts
C C(ΣEntryGate)otimes C(ΣExitGate)otimes C(ΣPaymentMachine)
(55)
Local contract C(ΣEntryGate) is the more complex one becauseit involves countingmdashwe have assumed a capacity of two tokeep it simple Remarkably enough the decomposition (55)involves small sub-systems compared to Csupervisor (Fig 13)and the global contract C the restriction operation is to beacknowledged for this strong reduction in size
E The four ldquoCrdquo
Requirements capture and management are important mat-ters for discussion with certification bodies These bodieswould typically assess a number of quality criteria from egthe following list elaborated by INCOSE [114] AccuracyAffordability Boundedness Class Complexity Completeness
request enter
ticket issue
entry gate open
entry gate closeEntryGate
vehicle enter
vehicle exit
exit ticket insert ExitGateexit gate open
exit gate close
ticket insert payment
coin insert paymentPaymentMachine exit ticket issue
Figure 14 System architecture as specified by the designer
0
vehicle_exit
1
request_enter
3
vehicle_enter
request_entervehicle_exit
2ticket_issue
vehicle_enter
request_entervehicle_exit
vehicle_enter
4
entry_gate_open
entry_gate_closeentry_gate_open
ticket_issuevehicle_enterrequest_entervehicle_exit
entry_gate_close
request_entervehicle_exit
5vehicle_enter
vehicle_enter
6
request_enter
15
entry_gate_close
16
vehicle_exit vehicle_enter
request_enter
7
vehicle_exit
8
entry_gate_close
entry_gate_closevehicle_enter
request_entervehicle_exit
vehicle_exit
vehicle_enter
request_enter
9ticket_issue
vehicle_exit
vehicle_enter
request_enter
10
entry_gate_open
vehicle_exit
entry_gate_closerequest_enter
11
vehicle_enter
vehicle_enter
vehicle_exit12
request_enter
14entry_gate_close
vehicle_enter
vehicle_exit
request_enter
13entry_gate_close
vehicle_enter
vehicle_exit request_enter
vehicle_enter
request_enter
vehicle_exit
vehicle_exit
vehicle_enter
request_enter
entry_gate_close
vehicle_enter
request_entervehicle_exit
0 1exit_ticket_insert
4
vehicle_exit
exit_ticket_insert
2
exit_gate_open
vehicle_exit
exit_ticket_insert
3vehicle_exitexit_gate_close
exit_ticket_insertvehicle_exit
exit_ticket_insertexit_gate_close
vehicle_exitexit_gate_open
0 1ticket_insert_payment 2
coin_insert_paymentticket_insert_payment
3
coin_insert_payment
ticket_insert_paymentcoin_insert_paymentexit_ticket_issue
exit_ticket_issueticket_insert_paymentcoin_insert_payment
Figure 15 The three restrictions of the global contract C for the three sub-systems EntryGate (top) ExitGate (mid) and PaymentMachine (bottom)
Conciseness Conformance Consistency Correctness Criti-cality Level Orthogonality Priority Risk Unambiguousnessand Verifiability In this section we focus on four quality crite-ria that are considered central by certification authorities andare relevant to contracts namely Completeness CorrectnessConsistency and Compatibility
1) Consistency amp Compatibility Consistency and compat-ibility have been formally defined in the meta-theory seeSection V and Table IV therein In particular those formaldefinitions can be formally checked Thus the question ariseswhether these formal definitions suitably reflect the commonsense meaning of these terms
According to the common meaning a set of requirementsis consistent if it is not self-contradicting The intent is thatthere is no point in trying to implement an inconsistent set ofrequirements as no such implementation is going to exist
RR ndeg 8147
Contracts for System Design 50
It turns out that the existence of implementations is theformal definition of consistency according to the meta-theoryClearly the formal definition of consistency meets its commonsense interpretation We illustrate consistency on the top-levelspecification of Table IX Referring to this table we havestrengthened Rs6 and Rs7 in some way Lack of consistencyis revealed by checking the mutual consistency of these tworequirements with the requirement Rg3 applied to the exitgate After the following scenario
exit_ticket_insertexit_gate_openexit_ticket_insert
event exit_gate_open has modality must in left-hand interfaceand modality cannot in right-hand interface
According to the common meaning an architecture of sub-systems as characterized by their respective specifications iscompatible if these sub-systems ldquomatch togetherrdquo in that theycan be composed and the resulting system can interact withthe environment as expectedmdashuse cases can be operated aswished As explained in Table IV of Section V this is theformal definition of compatibility in the meta-theory Againthe formal definition of compatibility meets its common senseinterpretation
2) Correctness Correctness can only be defined withreference to another specification We propose to translateldquocorrectnessrdquo by one of the following properties dependingon the case (see Table IV for the notations)bull ldquois a correct implementation ofrdquo written |=Mbull ldquois a correct environment ofrdquo written |=Ebull ldquorefinesrdquo written
3) Completeness Completeness raises a difficulty Al-though the term ldquocompletenessrdquo speaks for itself it cannotbe formally defined what it means to be complete for a top-level specification in the form of a set of requirements Thereason is that we lack a reference against which completenesscould be checked Hence the only way to inspect a top-level specification for completeness is to explore it manuallyThe best help for doing this is to execute the specificationThus specifications must be executable Fortunately ModalInterfaces are executable and this way undesirable behaviorscan be revealed We illustrate this on the top-level specificationof Table IX where Rs6 is changed into ldquoexit gate must openafter an exit ticket is insertedrdquo (by omitting ldquoand only thenrdquo)Lack of completeness is revealed by simulation The followingscenario can occur
exit_ticket_insertexit_gate_openvehicle_exitexit_gate_closeexit_gate_open
which allows vehicles to exit without having inserted an exitticket an unwanted behavior This reveals that the specificationwas not tight enough ie incomplete So far for completenessof the top-level specification
In contrast completeness can be formally defined whena reference C is available We propose to say that Cprime isincomplete with reference to C if
1) Cprime does not refine C but2) there exists Cprimeprime Cprime such that Cprimeprime is consistent and
compatible and refines CThe rationale for this definition is that Cprime is not precise enoughbut can be made so by adding some more requirementsNote that Cprime is incomplete with reference to C if and onlyif Cprime and C is consistent and compatible This criterion is ofparticular relevance when Cprime =
otimesiisinI Ci is an architecture of
sub-contracts where Ci is to be submitted to supplier i forindependent development
F Discussion
Requirements engineering is considered very difficult Re-quirements are typically numerous and very difficult to struc-ture Requirements concern all aspects of the system func-tion performance energy reliabilitysafety Hence systemsengineers generally use several frameworks when expressingrequirements The framework of contracts expressed as ModalInterfaces that we have proposed here improves the situationin a number of aspectsbull It encompasses a large part of the requirements52
bull It can accommodate different concrete formalisms Inour example we have blend textual requirements withrequirements specified as state machines Richer for-malisms such as Stateflow diagrams can be accom-modated in combination with abstract interpretationtechniquesmdashthis is not developed here
bull We have shown how to offer formal support to importantproperties such as the four Crsquos during the process ofcertification
bull We have proposed a correct-by-construction approach tothe difficult step of moving from the top-level specifi-cation in the form of a requirements document to anarchitecture of sub-contracts for the suppliers53
XII CONTRACTS IN THE CONTEXT OF AUTOSAR
In this section we use AUTOSAR as an industrial exampleof how to leverage contracts within an existing standard toextend it
A The AUTOSAR context
AUTOSAR54 is a world-wide development partnership in-cluding almost all players in the automotive domain electronics
52 According to figures that were given to us by industrials 70-80 of therequirements can be expressed using the style we have developed here Otherrequirements typically involve physical characteristics of the system or definethe range for some parameters
53 The framework of AssumeGuarantee contracts that is used in Section XIIdoes not offer this for two reasons First it lacks the quotient and secondlocal alphabets are not properly handled In contrast AssumeGuarantee con-tracts are very permissive in how they can be expressed In particular dataflowdiagrams (Simulink) can be used to express assumptions and guarantees
54httpwwwautosarorg
RR ndeg 8147
Contracts for System Design 51
supply chain It has been created with the purpose of de-veloping an open industry standard for automotive softwarearchitectures To achieve the technical goals of modularityscalability transferability and reusability of functions AU-TOSAR provides a common software infrastructure based onstandardized interfaces for the different layers The AUTOSARproject has focused on the objectives of location indepen-dence standardization of interfaces and portability of codeWhile these goals are undoubtedly of paramount importancetheir achievement may not be sufficient for improving thequality of software systems As for most other embeddedsystem car electronics is characterized by functional as well asnon functional properties assumptions and constraints [111]Therefore an AUTOSAR based development process benefitsfrom adding contracts as the this section will demonstrate
B The contract framework
Extensive use of SimulinkStateflow modeling is performedfor system design in the automobile sector It is thus naturalto try reusing this modeling style for defining contractsSince AG contracts of Section VII simply rely on specify-ing assertions regardless of how they are actually describedwe use AG contracts for this AUTOSAR case study SinceSimulinkStateflow diagrams are very flexible contracts canbe expressed for all viewpoints (function timing safety) Inturn reasoning on such contracts is beyond the capability ofautomatic tools Consequently checking for implementationand refinement relations will be performed manually on smallmodels In contrast the powerful contract algebra developedin the meta-theory is fully generic and does not depend onthe nature and complexity of the considered models Themodularity it offers will thus be the main help offered bycontract based design in this case study As another featureof this this study the distinction between ldquohorizontalrdquo andldquoverticalrdquo contracts is used see Section IV-D4 Finally thefollowing variation of AG contracts is used
Assertions consist of a timed extension of the weaklysynchronous model (18) namely
P sube ((Σ 7rarr D) cup R+)lowast cup ((Σ 7rarr D) cup R+)
ω (56)
meaning that the assertion proceeds by a succession of stepsconsisting of either assignment of values to variables (includ-ing the special status absent for multiple-clocked assertions)or time progress Composition is by intersection P1timesP2 =def
P1 and P2 with alphabet equalization by inverse projection asin see Section VII-C Following Section VII-B componentsare tuples M = (ΣinΣout P ) where Σ = Σin cup Σout is thedecomposition of alphabet Σ into its inputs and outputs andP is an assertion following (56) Components must be free ofexception in the sense of Definition 4
A contract is a tuple C = (ΣinΣoutAs AwG) whereΣ = Σin cup Σout is the decomposition of alphabet Σ intoits inputs and outputs As and Aw the strong and weakassumptions and G the guarantees are assertions over ΣThe set EC of the legal environments for C collects all com-ponents E such that E sube A The set MC of all components
implementing C is defined by (As andAw)timesM sube G meaningthat implementations guarantee G under the condition that theenvironment satisfies the stronger condition AsandAw In otherwords in this framework legal environments are constrainedby strong assumptions only whereas the conjunction of strongand weak assumptions is required to guarantee G Weakassumptions are useful for design iterations in case strictobligations for the context of use may not be realizable
To conclude on this framework its difference is onlymethodological since any contract with strong and weakassumptions C = (ΣinΣoutAs AwG) is equivalent to anordinary AG contract (ΣinΣoutAsG or notAw) Thus thereader is referred to Section VII Adding time to the paradigmdoes not change anything to the relations or operators definedin that section
However adding time results in decidability and complexityissues The latter problem can be fixed in part by usingobservers see Sections V-G and VII Other proofs can be car-ried on manuallymdashthis is feasible for undecidable propertieswhen the needed reasoning only involves a small part of theanalyzed system involving few locally interacting componentsThe added value of our contract framework is to supportthe combination of proofs into a validation for the overallsystem taking into account detailed design decisions capturedin system and ECU configurations
C Exterior Light Management System
To illustrate the benefits of contract-based systems engineer-ing in AUTOSAR we consider as an example an excerpt of anExterior Light Management for an automobile55 We focus onthe parts responsible for sensing driver inputs and actuatingthe rear direction indicator lights and brake lights With thisexample we show how requirements can be refined to contractsand discuss the added value of contracts for negotiationsbetween OEM and suppliers We will also illustrate the useof vertical contracts eg to specify the expected latency ofthe communication solution and computations from the timingviewpoint and a failure hypothesis in terms of reliability
1) Function and timing We begin our study by showinghow AUTOSAR models can be enhanced with contracts
System
ext_pedal
ext_lamp
ext_tssext_wls
ext_rlaext_rra
Figure 16 Virtual Functional Bus model
The Virtual Functional Bus model Figure 16 shows the Vir-tual Functional Bus (VFB) model encompassing the exteriorlights management This software composition specifies the
55A case-study from the German SPES2020 project
RR ndeg 8147
Contracts for System Design 52
interfaces exposed by the component to the sensors deliveringdriver inputs (brake pedal warn light button turn signallever) and to the actuators controlling the lights Ports witharrowheads denote an asynchronous data flow interface whichis a SenderReceiverInterface Here it is a special kind calledServiceInterface which means the data is provided by somelocal service located in the BasicSoftware stack of an ECU(Electronic Computing Unit) The requirements document ofthe system contains one timing-related requirementbull R1 If the driver presses the brake pedal the brake lights
must light not later than 25msWe formalize in Table X this requirement as a contract by
using a pattern-based contract specification language (terms inbold-face are keywords)
CR1
As whenever ext_pedal occursext_pedal does not occur during[ext_pedalext_lamp]ext_pedal occurs sporadicwith minperiod 25ms
Aw trueG delay between ext_pedal and
ext_lamp within [0ms25ms]
Table XHORIZONTAL CONTRACT OF VFB MODEL
Indicator
BrakePedalSensor PedalToLamp
TurnSwitchSensor
WarnLightsSensor
SwitchLightActuator
RearLeftActuator
RearRightActuator
BrakeLampActuator
ext_pedal
pos_pedal_out lamp_intensity ext_lamp
ext_tss
ext_wls
tss
wls
ext_rla
ext_rra
rla_signalrra_signal
emcyBrake
pos_pedal_in
Figure 17 Decomposed Virtual Functional Bus model
Decomposed VFB Software composition Figure 17 showsthe decomposed VFB model AssemblySwConnectors link theports of parts of the composition and are subject to commu-nication refinement The components used in the compositionand their functions are as followsbull BrakePedalSensor receives the position of the brake pedal
(ext_pedal) and distributes it to other components
bull PedalToLamp reads the brake pedal position (pos_pedal)and calculates requested brightness of the brake indicatorlights (lamp_intensity)
bull BrakeLampActuator reads the requested brightness of thebrake indicator lights (lamp_intensity) and actuates thebrake lamps accordingly (ext_lamp)
bull TurnSwitchSensor reads the position of the lever and for-wards it (tss)
bull WarnLightsSensor reads status of the warn blink button andforwards it (wls)
bull Indicator reads the status of the warn blink button the leverposition and cyclically toggles the left and right signals(rla_signal rra_signal)
bull Rear(Left|Right)Actuator reads its input signal ((rla|rra)_signal)and actuates the bulb (ext_(rla|rra))
bull SwitchLightActuator reads left and right signals((rla|rra)_signal) and provides feedback on the dashboard
Horizontal (functional) contracts associated to the VFBmodel For the decomposed VFB model we derive horizontalcontracts specifying the desired IO behavior of the parts Asan example for the component BrakePedalSensor we state thecontracts shown in Table XI Contract CfIOBPS
specifies that
CfIOBPS
Afs whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Afw true
Gf whenever ext_pedal occurspos_pedal_out occurs
CfSIGNALBPS
Afs whenever pos_pedal_out occurs
pos_pedal_out does not occur during[pos_pedal_outpos_pedal_in]
Afw true
Gf whenever pos_pedal_out occurspos_pedal_in occurs
Table XIA SAMPLE OF THE HORIZONTAL CONTRACTS OF THE DECOMPOSED VFB
MODEL SUPERSCRIPT f REFERS TO ldquoFUNCTIONrdquo
provided that the pedal is not ldquomultiply pressedrdquo then thepos_pedal message traverses the BrakePedalSensor and then thewire following it with some unspecified delay In particular nomessage is lost due to a miss by this block Similar contractsare stated for all blocks of the VFB model thus resultingin a set Cf
IO of contracts For all AssemblySwConnectors ofthe composition horizontal contracts are specified that aresimilar to that of CfSIGNALBPS
resulting in a set CfSIGNAL
of contracts This contract scheme guarantees a reliable datatransport by each wire of the VFB model no matter how thecommunication is refined
So far we have stated contracts for each block and eachwire of the VFB model Compose the above contracts usingcontract composition (14) ie compute
CfVFB =otimes(otimes
C | C isin CfIO)
otimes(otimesC | C isin Cf
SIGNAL) (57)
RR ndeg 8147
Contracts for System Design 53
The guarantee offered by overall contract CfVFB is the con-junction of the guarantees of the constitutive contracts Hencecontract CfVFB guarantees that messages reliably traverse theVFB model with however an unspecified delay On the otherhand contract composition (14) assumes the conjunction ofall assumptions stated for each blockmdashthe guarantee offeredby CfVFB and the strong assumption of CR1
discharge all ofthese assumptions
At this point we observe that contract CfVFB involves notiming characteristics and thus functional contract CfVFB doesnot refine the initial contract CR1 To overcome this timingcontracts are added in the next step that will complement thisfunctional contract with timing viewpoint based on expectedperformance characteristics of the computing platform
Budgeting time using contracts We now state additionalcontracts such as the ones shown in Table XII Observethat for those contracts weak assumptions are used see Sec-tion XII-B regarding the motivations for doing this Observealso that we repeated the functional strong assumption56
Again stating similar contracts for each block and wire of the
CtIOBPS
Ats whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Atw ext_pedal occurs sporadic
with minperiod 15msGt delay between ext_pedal and
pos_pedal_out within [0ms15ms]
CtSIGNALBPS
Ats whenever pos_pedal_out occurs
pos_pedal_out does not occur during[pos_pedal_outpos_pedal_in]
Atw pos_pedal_out occurs sporadic
with minperiod 2msGt delay between pos_pedal_out and
pos_pedal_in within [0ms2ms]
Table XIITIMING CONTRACT OF DECOMPOSED VFB MODEL SUPERSCRIPT t
INDICATES THAT THESE CONTRACTS DEAL WITH TIMING
VFB model yields two sets CtIO and Ct
SIGNAL of contractsand we consider
CtVFB =otimes
(otimesC | C isin Ct
IO)otimes(otimesC | C isin Ct
SIGNAL)(58)
The next step is to combine for each component (blockor wire) of the VFB model the two functional and timingviewpoints using conjunction ie to compute
CVFB =otimes(otimes[
Cf and Ct]| (Cf Ct) isin CIO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin CSIGNAL
) (59)
where CIO collects for each block the pair of functional andtiming contracts associated with it and similarly for CSIGNAL
56 If we do not do this then when taking the conjunction of functionaland timing contracts the functional strong assumption gets absorbed by thestrong assumption of the timing contract since the latter is equal to T Seethe discussion regarding AssumeGuarantee contracts with variable alphabetsat the end of Section VII-C
At this point we observe that the architecture of the VFBmodel is a directed acyclic graph
Consider the conjunction C = Cf and Ct = (AG) for eachblock or wire As an example focus on block IOBPS whichis the first block of VFB seen as a directed acyclic graphRegarding the combination of strong and weak assumptionswe have A = Afs and Atw which is weaker than As theassumption of CR1
in Table X Regarding guarantees we haveG = Gf and Gt which ensures that messages traverse thecomponent without duplication or loss and with a delay lessthan the ldquominperiodrdquo of the input signal (15ms) Also guar-antee G offered by this block is strong enough to dischargethe assumption of the next wire when performing contractcomposition Reproducing the same reasoning inductivelyalong all blocks and wires of the VFB model seen as an acyclicgraph shows that
CVFB CR1(60)
Consequently submitting the pairs of contracts (Cf Ct) asso-ciated to each component for separate development possiblyby different suppliers will ensure correct integration (providedimplementations by the suppliers are correct with respect totheir contracts) In particular the component BrakePedalSensorbelongs to the chassis domain and is implemented by adifferent supplier than the other components
Discussion The above step of our contract based designmethodology leads to the following important notices
1) So far our proof steps were all manual Our contractbased reasoning however was instrumental in ensuring thatelementary proof steps were combined correctly Reasoningbased on intuition when component composition and view-point combination both occur is very likely to lead to wrongconclusions There is a strong added value in contract basedreasoning even if elementary proof steps are manual
2) Manual reasoning can be complemented by the use ofobservers Again it is important that the use of observerswhen component composition and viewpoint combination bothoccur is performed correctly Our development in Section V-Gprovides the formal support for this For the pattern basedlanguage used here a framework for checking refinement ofcontracts using an observer based strategy is described in [94]
3) The responsibility of establishing the sub-contracts sub-mitted to the different suppliers is assigned to the OEM inaccordance with his role as integrator Components belongingto different domains of a car (engine chassis etc) are likely tooriginate from different vendorssuppliers By using our abovereasoning the OEM can decompose its contract specificationspassing them to supplier(s) For example the componentBrakePedalSensor is the only one in the VFB model that belongsto the chassis domain and other components are developed byone or more different suppliers Thus in decomposition (59)the two sets of contracts CIO and CSIGNAL are partitioned
RR ndeg 8147
Contracts for System Design 54
eg for subcontracting to two different suppliers
Csupplier1VFB =
otimes(otimes[Cf and Ct
]| (Cf Ct) isin C1
IO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin C1
SIGNAL
)Csupplier2VFB =
otimes(otimes[Cf and Ct
]| (Cf Ct) isin C2
IO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin C2
SIGNAL
)Each supplier can then safely develop its own sub-systemindependently We develop this in the next sub-section
Implementation of software components and vertical as-sumptions Each of the software components being part ofthe software system composition (cf Figure 17) is a Compo-sitionSoftwareComponents as this allows the supplier to reusealready designed components We thus consider one suchcomponent with its contract C = Cf and Ct consisting of thefunctional contract Cf in conjunction with the timing contractCt The supplier can then follow two different approaches fordeveloping this component
In a first approach the supplier reuses a composition
C =otimes
iisinI Ci (61)
of off-the-shelf components available from a library Twosituations can then occurbull The easy case is when refinement holds C C This
means that for C = (As Aw G) guarantees are strongenough and assumptions are weak enough to implyrefinement with respect to the contract C specified bythe OEM
bull A more realistic (but also more delicate) case is when thefollowing weaker relations are satisfied
C Cf (62)G sube G (63)
As and Aw supe Afs andAfw (64)
but the conditions requested on timing assumptions forrefinement C C to hold are not satisfied
As and Aw 6supe Ats andAtw (65)
Under (65) composition from library C cannot be usedas such It can however still be used as a valid imple-mentation provided that some additional missing verticalassumption regarding timing is stated such that
As and Aw supe Ats andAtw and Atw︸ ︷︷ ︸for negotiation
(66)
(66) requires a negotiation in which additional verticalassumption Atw is returned back to the OEM as an ad-ditional performance requirement for the ECU platformIf this is accepted by the OEM then development by thesupplier using off-the-shelf components from the library(61) can proceed
The alternative approach is to implement the componentEventually this results in a composition of AtomicSoftwareCom-ponents This component type has an internal behavior specifi-cation comprising so called Runnables which are the smallest
executable entities known to AUTOSAR For each runnableactivation conditions are defined by means of RTEEvents con-trolled by the RuntimeEnvironment on the corresponding ECUand data accesses referring ports of the owning component AnRTEEvent can be configured to occur either cyclically (time-triggered) or by the data arrival on some input port of theowning component (event-triggered)
Figure 18 depicts the internal behavior of componentBrakePedalSensor This component consists of a single
BrakePedalSensor
BPSRunnable
pos_pedal_out
P=10ms
ext_pedal
Figure 18 Internal behavior of BrakePedalSensor-component
CfIBBPS
Afs whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Afw true
Gf whenever ext_pedal occurspos_pedal_out occurs
CtIBBPS
Ats whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Atw ext_pedal occurs sporadic
with minperiod 10msBPSRunnableact occurs each 10msdelay between BPSRunnableact andpos_pedal_out within [0ms10ms]
Gt delay between ext_pedal andpos_pedal_out within [0ms10ms + 10ms]
CprimetIBBPS
Aprimets whenever ext_pedal occursext_pedal does not occur during[ext_pedalpos_pedal_out]
Aprimetw ext_pedal occurs sporadicwith minperiod 10msBPSRunnableact occurs each 10msdelay between BPSRunnableact andpos_pedal_out within [0ms5ms]
Gprimet delay between ext_pedal andpos_pedal_out within [0ms10ms + 5ms]
Table XIIICONTRACTS FOR INTERNAL BEHAVIOR OF
BRAKEPEDALSENSOR-COMPONENT
runnable BPSRunnable which is activated cyclically with aperiod of 10ms Upon its activation it reads the sensorvalues from the ECU abstraction component and writes the
RR ndeg 8147
Contracts for System Design 55
position of the brake pedal on its provided SenderReceiverport The timing behavior of the component owning a time-triggered runnable can be characterized by the contract shownin Table XIII top
We now focus on the second situation in which the supplierwants to reuse components from a library to implementcontract C = CfIOBPS
and CtIOBPS We consider the case where
a component BrakePedalSensor has already been implementedand characterized by C = CfIBBPS
and CtIBBPSNow observe that
relation (62) holds However G 6sube G Taking a closer lookat Atw we see it assumes a worst case response time forBPSRunnable Thus the guarantee Gt can be strengthened ifweak assumption Atw is replaced by Aprimetw ensuring a shorterresponse time The supplier would then consider the con-tract Cprime = CfIBBPS
and CprimetIBBPS where the re-adjusted contract
CprimetIBBPScorresponds to assuming Aprimetw and guaranteeing Gprimet
For that modified contract relations (62ndash65) hold Howeverstrengthening an assumption is not a refinement Thereforeapplying this modification cannot be performed by the supplieron its own but rather requires negotiation with the OEM Ifthe OEM is willing to accept the stronger assumption Aprimetwthe component from the libary can be used and the modifiedcontract of the supplier is refined Cprime Cprimesupplier1
VFB The next process steps in the AUTOSAR methodology called
System configuration and ECU configuration define the targetarchitecture (ECUs and communication network) as well asthe deployment of the application software components onthat distributed architecture Thus satisfaction of the contractsspecified for the application needs to be verified for the givenarchitecture and deployment (cf IV-D4) We develop this inthe next two sub-sections
ECU configuration and vertical contracts During thefollowing discussion we assume that for each componentimplementation a contract similar to Cprime has been specifiedand possibly an associated Aprimetw has been negotiated Observethat Aprimetw may invalidate refinement of system requirements bythe VFB contract Consider the example above Aprimetw assumesan activation of BPSRunnable each 10ms and a worst caseresponse time less than 5ms This additional weak assumptionis now part of Cprimesupplier1
VFB However it is neither dischargedby any guarantee of CprimeVFB nor by the strong assumption ofCR1 Thus we need to verify that 1 all vertical assumptionscollected during previous steps are discharged during system-and ECU configuration and 2 all guarantees are met bysoftware components and connectors For both tasks state-of-the-art verification techniques can be used
As an example focus on the vertical assumption Aprimetw ofthe BrakePedalSensor-component and consider the ECU con-figuration depicted in Figure 19 The ECU hosts the twocomponents BrakePedalSensor and PedalToLamp of the VFBmodel57 These components are integrated with a layered basicsoftware stack on an ECU That stack consists of multipleBasicSoftwareModules (BSWM) Each of these modules has aset of standardized interfaces and is implemented by a set
57To simplify we omit port emcyBrake
RTE
BrakePedal
SensorPedalToLamp
BSW
COMOSt1 t2
Complex
Device
Driver
ext_pedal
pos_pedal_out
pos_pedal_in
lamp_intensity
isr
Figure 19 Extracting platform contracts from ECU configuration
of BswModuleEntities These are analogous to the Runnables ofapplication software components and are either executed by adedicated OS task or interrupt service routine Therefore weexpect BasicSoftwareModules to be characterized by contractsin a way similar to the internal behavior of applicationcomponents (cf contracts in Table XIII) In case a BSWM hasa BswModuleEntity that is not mapped to some task or interruptservice routine that entity is an ldquoordinaryrdquo function calledwithin the context of another BswModuleEntity or Runnable Inthe example ECU configuration two BSWMs are shown
bull A ComplexDeviceDriver which has direct access to thesensor of the ECU that detects position of the brake pedal
bull An AUTOSAR COM module and a CAN interface (notshown here)
The components and BSWMs own a single runnable eachbsw entity respectively The ECU configuration maps BP-SRunnable to task t1 of the operating system (OS) and PTL-Runnable to task t2 The BswModuleEntity of the ComplexDe-viceDriver is mapped to an interrupt service routine while theentity of the COM module is simply a function for sendinga signal That function is used by the AUTOSAR runtimeenvironment (RTE) to realize the communication specified onVFB-level by means of the connectors For each task of theOS the ECU configuration specifies at least its priority andwether it is preemptable The activation of a task is specifiedby linking an alarm of the OS to that task Those alarmscan also be configured to occur cyclically For each cyclicalarm we generate a contract PALARMi
with trivial strongand weak assumptions and as guarantee the cycle time ofthe alarm The example ECU configuration contains a singlealarm whose contract is listed in Table XIV top Furthermore
PALARM1
As trueAw trueG Alarmi occurs each 10ms
PBPSRunnable
As trueAw trueG delay between BPSRunnableact and
pos_pedal_out within [1ms4ms]
Table XIVPLATFORM CONTRACTS OBAINED BY ANALYSIS OF ECU CONFIGURATION
RR ndeg 8147
Contracts for System Design 56
we can extract from the AUTOSAR model of the componentimplementation a set of execution time specifications for eachRunnable owned by the component Again the same appliesto BswModuleEntities With this information we can create atask network and obtain response times for each Runnableand BswModuleEntity (if executed by some task or interruptservice routine) using tools like SymTAS58 or chronVAL59Afterwards we generate for each Runnable and BswModuleEntity(if executed by task or ISR) a contract PRunnablei
with stongand weak assumption T and as guarantee the reponse timeinterval determined by analysis For the ECU configurationsketched in Figure 19 BPSRunnable has a response time thatlies in the interval [1ms 4ms] resulting in the contract shownin Table XIV bottom Similar contracts are stated for all tasksand alarms extracted from the ECU configurations We thencompose these contracts and the contracts of the BSWMswhich yields the contract P characterizing the executionplatform Following the approach outlined in Section IV-D4we compose the VFB contract with the platform contract andcheck for refinement ie
CprimeVFB otimes P CprimeVFB (67)
The vertical assumption Aprimetw is discharged in the compositionof the VFB and platform contracts and refinement holdsFurthermore with Aprimetw being discharged refinement of thesystem requirement holds again
CprimeVFB otimes P CR1(68)
The approach outlined here to analyze the mapping of applica-tion software components and their associated contracts on anECU network by creating contracts from ECU configurationsand results of response time analysis has been implemented ina framework That framework includes a meta-model support-ing contract-based design and enables to 1 specify contractsfor components in foreign models and 2 check for refinementbetween contracts belonging to different models [24]
Inter-ECU communication During system configurationthe leaves of the hierarchical software composition calledAtomicSoftwareComponents are mapped to ECUs of the targetarchitecture Thus we know for each connector of the VFBmodel whether it must be implemented by the communicationnetwork interconnecting the ECUs
For both intra- and inter-ECU communication the designmust be verified against the corresponding contracts of theVFB model ie the set of contracts[
Cf and Ct] ∣∣ (Cf Ct) isin CSIGNAL
(69)
Again available analysis techniques can be used Suppose asignal from the VFB model is mapped to a frame transmittedon a CAN bus The OEM can then for each such contractuse the combination of strong and weak assumptions A =Afs and Atw as specification of the minimal inter-arrival timesof subsequent occurrences of the signal Taking into account
58httpwwwsymtavisioncomsymtashtml59httpwwwinchroncomchronvalhtml
the priority of each CAN frame given by its identifier theresponse time of each signal can be computed and comparedagainst the guarantee G = Gf andGt
If the communication network whose configuration is partof the AUTOSAR system configuration is successfully verifiedagainst the contracts defined in (69) deployment of the VFBmodel on the target architecture is correct with regard tothe VFB contract and the design fulfills the initial systemrequirement CR1
Discussion The above development highlights themethodological value of contracts for system design in AU-TOSAR context at later design stages First both contractconjunction and composition are used Then modificationsthat are not refinements are pinpointed which forces thesupplier to engage on a negotiation with the OEM regardingsystem specifications Without the solid support of contractsand its rules such kind of reasoning would be error prone
2) Safety The virtual function bus (VFB) concept wasintended to enable a distributed development of software com-ponents independently from the underlying hardware architec-ture The specification of the interfaces in the 3x releases didnot support the kind of non functional property necessary todevelop safety aspects of critical systems This fact lead to thedevelopment of the previously mentioned Timing Extensionand Safety Extension to Methodology and Templates Thesafety extension directly addresses the use of contracts forthe specification of safety relevant properties driven by theneed for compliance to the upcoming ISO26262 standardThe ISO26262 not only requires comprehensive checking ofrequirements but also states explicitly the need for usingassumptions on the environment to develop a safety relevantelement on the supplier side (ldquosafety element out of contextrdquo)In particular the standard distinguishes betweenbull A functional safety concept comprising the functional
safety requirements their allocation to architectural el-ements and their interaction necessary to achieve thesafety goals This is used to demonstrate that the risksrelated to an item of a vehicle are addressed by anadequate functional architecture
bull A technical safety concept used to demonstrate that thefunctional safety concept is addressed by an adequatetechnical solution
As a simple example for this approach we take the functionalarchitecture of Figure 20 showing the decomposition of theSafeBrakeIndication function into the ldquonormalrdquo BrakeIndicationfunction and the SignalingFailureDetection safety function in casethe BrakeIndication fails The corresponding safety goal requiresthat a loss of the braking indication function shall be detectedThis is formalized as contract CS0 shown in Table XV Thiscontract states that under a given failure hypothesis (ldquonodouble failurerdquo) either the brake lamp is activated or the driveris warned by the SignalingFailureDetection function This contractis attached to the function SafeBrakeIndication
For the subfunction BrakeIndication we show in Table XVIa contract CS1 stating the correct behavior in the absence
RR ndeg 8147
Contracts for System Design 57
CS0
As trueAw Only one of Fail(BrakeIndication)
and Fail(SignalFailureDetection) occursG Whenever BreakRequest occurs then
BreakIndication or SignalFailureDetection is performed
Table XVHORIZONTAL CONTRACT REPRESENTING FUNCTIONAL SAFETY
REQUIREMENT
ltltFunctiongtgt SafeBrakeIndication
ltltFunctiongtgt BrakeIndication
ltltSafetyFunctiongtgt SignalingFailureDetection
ltltFunctionalExchangegtgt BrakeRequest
ltltFunctionalExchangegtgt Detect(BrakeIndicationFail)
Figure 20 Functional architecture including safety function
of a failure of this function For the SignalingFailureDetection
CS1
As trueAw Absence of Fail(BrakeIndication)G Whenever BrakeRequest occurs then
BrakeIndication is performed
Table XVIHORIZONTAL CONTRACT FOR FUNCTION OF BRAKING LAMP
the associated contract states that a detected failure of thesub-function BrakeIndication is correctly indicated under theassumption that the provided function itself is not impacted bya failure see Table XVII An easy manual inspection shows
CS2
As trueAw Absence of fail(SignalingFailureDetection)G Whenever detect(fail(BrakeIndication))
SignalingFailureDetection is performed
Table XVIIHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
that the composition of CS1 otimes CS2 refines CS0 ie we haveformally validated the functional safety concept
The next step consists in allocating these functions tosoftware components on the VFB and developing a simpletechnical safety concept The corresponding technical architec-ture is shown in Figure 21 For the sake of simplicity we onlyconsider corrupted data while transmitting under failure modeThe affected communication links are marked in blue in Fig-ure 21 Thus fail(BrakeIndication) is mapped to fail(pos_pedal) andfail(lamp_intensity) In the same way fail(SignalingFailureDetection)is mapped to fail(mal_indication) This mapping is not furtherelaborated in this paper
For defining the technical safety concept so-called prop-agation contracts are used Propagation contracts expresshow failures (from the environment of the component) are
BrakePedal Sensor
PedalTo Lamp
BrakeLamp Actuator
MalfunctionIndication
lamp_intensity pos_pedal
ext_pedal mal_indication
ext_lamp
ext_indication
Figure 21 Extract of Indicator System
processed by the component According to the ISO 26262 (seeFigure 22) Faults Errors and Failures are distinguished by thepatterns used for the contracts
Figure 22 The role of Faults Errors and failures
For instance the contract CS4 of Table XVIII states that theerror state of the PedalToLamp component is caused by a failurein the communication
CS4
As trueAw trueG Mode PedalToLampError is caused by
fail(pos_pedal)
Table XVIIIHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
The nominal behavior is again given by the contract with anassumption about the absence of the communication failuresee Table XIX
Similarly the error state of the BreakLampActuator iscaused by a failure on the second communication link(fail(lamp_intensity)) or by a failure propagated from the PedalTo-Lamp component see Table XX The nominal behavior of the
RR ndeg 8147
Contracts for System Design 58
CS5
As trueAw Absence of fail(pos_pedal)G Whenever pos_pedal occurs then
lamp_intensity occurs
Table XIXEXEMPLARY CONTRACT FOR NOMINAL BEHAVIOR SPECIFICATION
BrakePedalSensor and the MalfunctionIndicator is formed similarlyto CS5
CS6
As trueAw trueG Mode BreakLampActuatorError is caused by
fail(lamp_intensity) or mode PedalToLampError
Table XXHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
The composition of contracts CS4 CS7
together with thenot stated simple nominal contracts entails the contract CS8
shown on Table XXI stating the functional safety requirement
CS8
As trueAw only one of faila failb failcG Whenever ext_pedal occurs then
ext_lamp or ext_indication occurs
Table XXICONTRACT STATING THE TECHNICAL SAFETY REQUIREMENT
Contract CS8is directly related to the functional safety goal
and includes the allocation to a technical safety concept Thisway a consistency between the functional and the technicalsafety concept has been established Furthermore thanks tothe formal pattern-based specification language the refinementrelations ensure that the concepts themselves are correct
To conclude let us mention other safety related use-caseswhich benefit from contract based specification such as theautomatic generation of fault-trees or FMEA tables as well asthe safe-state management
D Integrating Contracts in AUTOSAR
An important challenge is to smoothly integrate the use ofcontracts as part of AUTOSAR methodology We advocate amigration in two steps
TodaymdashOffering a Smooth Integration of Contract-BasedSystem Engineering with AUTOSAR The metamodel under-lying the CESAR reference technology platform has beencarefully designed to support a seamless design flow fromthe derivation of high-level requirements of new automotivefunctions to the level of detailed application design defined asthe entry point in the AUTOSAR design methodology The keyfor this smooth integration has been laid by AUTOSAR itselfby enforcing a clean separation between application develop-ment on the one side and deployment to distributed target
architectures on the other side Regarding layered design thejoint scope of CESAR and AUTOSAR ranges from systems-of-systems levels for Car2X applications to the introductionof new automotive functions and down to the detailed designlevel As illustrated in the previous section such phases wouldbuild on established design processes and currently used de-sign tools where contracts and viewpoints are conservativelyadded as additional flavor to existing design methodologiesFull hand-over to AUTOSAR takes place at the detailed designstage where component contracts get implemented using theAUTOSAR component model thus providing the entry pointfor the AUTOSAR design methodology
Following the AUTOSAR flow system configurations andECU configurations describe the detailed target hardware Wecan then automatically extract from system and ECU con-figurations all information for performing real-time analysisVertical assumptions on the component level can be derivedby back-annotation from the underlying target hardware Alter-natively vertical assumptions can be seen as constraining thetarget architecture (regarding its timing characteristics) and canthus be used to constrain the design space for possible targetarchitectures Finally when deploying components to ECUscommunications of the virtual functional bus are mapped to theinter-component communications on the physical architecture
The FuturemdashIntegrating Contracts in AUTOSAR The cur-rent AUTOSAR release is expressive enough to represent real-time contracts Using the concept of timing chains both end-to-end deadlines as well as assumed response times for compo-nent execution and communication can be expressed Howeverthe current release was not designed for extensibility thereis no established notion of viewpoints and hence no anchorto easily migrate from the current setting to one supportingmultiple viewpoints As pointed out before the decision asto which viewpoints should or should not be anchored is abusiness decision However given that ISO 26262 has becomebinding we see the need for a systematic integration of thesafety viewpoint
In fact a safety extension has already been proposed forinclusion in AUTOSAR It allows to use contracts for theencapsulation of Basic SoftWare (BSW) modules applicationsoftware components entities of the hardware architecture(like ECUs and buses) and the characterization of commu-nication services Such encapsulation would for instancedistinguish between BSW modules that (1) contribute to safety(safety mechanisms) and (2) those that could potentiallyimpact systemrsquos safety (by providing their failure propagationbehavior) A typical example for (1) would be the func-tion inhibition manager that maintains function inhibitionswhenever for instance implausible outputs are generated Atypical example for (2) would be an error that occurs inthe communication services or an error that is generated incommunication HW that impacts communication services
The objective of the extension is to provide an ISO 26262compliant traceability This allows for instance to deal withcompliance between functional safety (where functions haz-ards and safety functions are collected in the functional
RR ndeg 8147
Contracts for System Design 59
model) and technical safety of the AUTOSAR architectureinstance (guaranteeing that the AUTOSAR implementationmdashusing given safety functions of the AUTOSAR architecturemdashindeed implements the identified functional safety concept)
Since timing and safety viewpoints will be supported inAUTOSAR it is at least worthwhile to consider introducingthe concepts of viewpoints systematically Doing so will easetheir activation at times when other market factors such aspower-management mandate their introduction
E Summary and discussion
We have proposed a smooth path for integrating contractsin the context of AUTOSAR at the level of detailed designWe believe that the main aspects for consideration whileintroducing contracts are the handling of time budgets andthe specification of failure modes and failure propagation incombination with the functional aspect itself Vertical contractswere instrumental in handling time budgets Such contractsrelate two different layers of the AUTOSAR framework
XIII CONCLUSION
This paper presented past and recent results as well asnovel advances in the area of contracts and their theory Byencompassing (functional and non-functional) behaviors thenotion of contract we considered here represents a significantstep beyond the one originally developed in the softwareengineering community
A What contracts can do for the designer
This paper demonstrates that contracts offer a number ofadvantages
Contracts offer a technical support to legal customer-supplier documents Concurrent developmentmdashboth withinand across companiesmdashcalls for smooth coordination andintegration of the different design activities Properly definingand specifying the different concurrent design tasks is andremains a central difficulty Obligations must therefore beagreed upon together with suspensive conditions seen aslegal documents By clearly establishing responsibilities ourformalization of contracts constitutes the technical counterpartof such legal documents Contracts are an enabling technologyfor concurrent development
Contracts offer support to certification By providing for-mal arguments that can assess and guarantee the qualityof a design throughout all design phases (including earlyrequirements capture) contracts offer support for certificationBy providing sophisticated tools in support of modularityreuse in certification is made easier
Contracts comply with formal and semi-formal approachesThe need for being ldquocompletely formalrdquo has hampered for along time formal verification in many industrial sectors inwhich flexibility and intuitive expression in documentationsimulation and testing were and remain preferred As theAUTOSAR use case of Section XII demonstrated using con-tracts makes semi-formal design safer Small analysis stepsare within the reach of human reasoning A valid system
wide analysis for both component-based and refinement-baseddesigns is typically beyond the reach of human reasoningContract based design enables it
Contracts improve requirement engineering As illustratedin the Parking Garage example of Section XI contracts areinstrumental in decoupling top-level system architecture fromthe architecture used for sub-contracting to suppliers Formalsupport is critical in choosing alternative solutions and migrat-ing between different architectures with relatively small effortOf course contracts are not the only important technologyfor requirements engineeringmdashtraceability is essential anddeveloping domain specific ontologies is also important
Contracts can be used in any design process Contractsoffer a orthogonal support for all methodologies and can beused in any flow as a supporting technology in composing andrefining designs
B Status of research
The area of contracts benefits from many advances inresearch that were not targeted to it Interface theories weredeveloped by the community of game theorymdashcomponent andenvironment are seen as two players in a game Modalitiesaimed to offer more expressive logics were born at theboundary between logics and formal verification Contractsas a philosophy originated both from software engineeringand formal verification communities with the paradigms ofPre-conditionPost-condition or AssumeGuarantee It is notuntil the 2000rsquos that the concept of contracts presented hereas a tool to support system design emerged In this evolutionvarious formalisms and theories were borrowed to developa rigorous framework This paper was intended to show thepower of a unified theoretical background for contracts the useof contracts in present methodologies and the challenges for itseffective applications in future applications The mathematicalelegance of the concepts underpinning this area providesconfidence in a sustained continuation of the research effort
C Status of practice
The use of contract-based techniques in system design isin its infancy in industry Further maturation is needed forits paradigm and concepts to become on one side clearand simple to be widely accepted by engineers in their day-to-day work and on the other side developed enough toallow for the development of tools for automatic verificationand synthesis While powerful contract-based proof-of-concepttools are being experimentedmdashsome of them were presentedin this papermdashthe robustness of the tools and the underlyingtechniques is still weak and contract-based design flows andmethodologies are not yet fully developed nor mature
D The way forward
The ability of contracts to accommodate semi-formal andformal methodologies should enable a smooth and rapid mi-gration from theory and proof-of-concepts to robust flows andmethodologies The need for jointly developing new systemswhile considering issues of intellectual property will make
RR ndeg 8147
Contracts for System Design 60
it attractive to rely on contracts in supplier chains In ouropinion contracts are primarily helpful for early stages ofsystem design and particularly requirement engineering whereformal methods are desperately needed to support distributedand concurrent development by independent actors
We have illustrated in this paper how suppliers can be givensub-contracts that are correct by construction and can be auto-matically generated from top-level specification We believehowever that the semi-assistedsemi-manual use of contractssuch as exemplified by our AUTOSAR case study is alreadya significant help useful for requirements engineering tooAltogether a contract engine (such as the MICA tool presentedin Section XI) can be used in combination with both manualreasoning and dedicated formal verification engines (eg fortargeting the timing viewpoint or the safety viewpoint) as thebasis for future development that will make contracts mainstream
REFERENCES
[1] Martiacuten Abadi and Leslie Lamport Conjoining specifications ACMTrans Program Lang Syst 17(3)507ndash534 1995
[2] Yael Abarbanel Ilan Beer Leonid Gluhovsky Sharon Keidar andYaron Wolfsthal FoCs - Automatic Generation of Simulation Checkersfrom Formal Specifications In E Emerson and A Sistla editors Com-puter Aided Verification volume 1855 of Lecture Notes in ComputerScience pages 538ndash542 Springer Berlin Heidelberg 2000
[3] B Thomas Adler Luca de Alfaro Leandro Dias da Silva MarcoFaella Axel Legay Vishwanath Raman and Pritam Roy Ticc A Toolfor Interface Compatibility and Composition In Proc of the 18thInternational Conference on Computer Aided Verification (CAVrsquo06)volume 4144 of Lecture Notes in Computer Science pages 59ndash62Springer 2006
[4] Albert Benveniste and Benoicirct Caillaud and Jean-Baptiste RacletApplication of Interface Theories to the Separate Compilation ofSynchronous Programs In IEEE Conf on Decision and Control dec2012
[5] Luca De Alfaro and Thomas A Henzinger Interface-based design InIn Engineering Theories of Software Intensive Systems proceedings ofthe Marktoberdorf Summer School Kluwer 2004
[6] Rajeev Alur and David L Dill A theory of timed automata TheoreticalComputer Science 126(2)183ndash235 1994
[7] Rajeev Alur Limor Fix and Thomas A Henzinger A determinizableclass of timed automata In David L Dill editor CAV volume 818 ofLecture Notes in Computer Science pages 1ndash13 Springer 1994
[8] Rajeev Alur Limor Fix and Thomas A Henzinger Event-clockautomata A determinizable class of timed automata Theor ComputSci 211(1-2)253ndash273 1999
[9] Rajeev Alur Thomas A Henzinger and Orna Kupferman Alternating-time temporal logic J ACM 49(5)672ndash713 2002
[10] Rajeev Alur Thomas A Henzinger Orna Kupferman and Moshe YVardi Alternating refinement relations In Proc of the 9th InternationalConference on Concurrency Theory (CONCURrsquo98) volume 1466 ofLecture Notes in Computer Science pages 163ndash178 Springer 1998
[11] Adam Antonik Michael Huth Kim G Larsen Ulrik Nyman andAndrzej Wasowski 20 Years of Modal and Mixed SpecificationsBulletin of European Association of Theoretical Computer Science1(94) 2008
[12] Adam Antonik Michael Huth Kim Guldstrand Larsen Ulrik Nymanand Andrzej Wasowski Complexity of Decision Problems for Mixedand Modal Specifications In FoSSaCS pages 112ndash126 2008
[13] Road vehicles ndash functional safety Standard ISO 26262[14] Christel Baier and Joost-Pieter Katoen Principles of Model Checking
MIT Press Cambridge 2008[15] Felice Balarin Jerry R Burch Luciano Lavagno Yosinori Watanabe
Roberto Passerone and Alberto L Sangiovanni-Vincentelli Con-straints specification at higher levels of abstraction In Proceedingsof the Sixth IEEE International High-Level Design Validation and Test
Workshop (HLDVT01) pages 129ndash133 Monterey CA November 7ndash92001 IEEE Computer Society Los Alamitos CA USA
[16] Felice Balarin Abhijit Davare Massimiliano DrsquoAngelo Douglas Dens-more Trevor Meyerowitz Roberto Passerone Alessandro Pinto Al-berto Sangiovanni-Vincentelli Alena Simalatsar Yoshinori WatanabeGuang Yang and Qi Zhu Platform-based design and frameworksMETROPOLIS and METRO II In Gabriela Nicolescu and Pieter JMosterman editors Model-Based Design for Embedded Systems chap-ter 10 page 259 CRC Press Taylor and Francis Group Boca RatonLondon New York November 2009
[17] Felice Balarin and Roberto Passerone Functional verification method-ology based on formal interface specification and transactor generationIn Proceedings of the Conference on Design Automation and Test inEurope (DATE06) pages 1013ndash1018 Munich Germany March 6ndash102006 European Design and Automation Association 3001 LeuvenBelgium
[18] Felice Balarin and Roberto Passerone Specification synthesis andsimulation of transactor processes IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 26(10)1749ndash1762October 2007
[19] Felice Balarin Roberto Passerone Alessandro Pinto and Alberto LSangiovanni-Vincentelli A formal approach to system level designMetamodels and unified design environments In Proceedings of theThird ACM and IEEE International Conference on Formal Methodsand Models for Co-Design (MEMOCODE05) pages 155ndash163 VeronaItaly July 11ndash14 2005 IEEE Computer Society Los Alamitos CAUSA
[20] Felice Balarin Yosinori Watanabe Harry Hsieh Luciano LavagnoClaudio Passerone and Alberto L Sangiovanni-Vincentelli Metropo-lis An Integrated Electronic System Design Environment IEEEComputer 36(4)45ndash52 2003
[21] Krishnakumar Balasubramanian Aniruddha Gokhale Gabor KarsaiJanos Sztipanovits and Sandeep Neema Developing applicationsusing model-driven design environments IEEE Computer 39(2)33ndash40 2006
[22] Sebastian S Bauer Alexandre David Rolf Hennicker Kim GuldstrandLarsen Axel Legay Ulrik Nyman and Andrzej Wasowski Movingfrom specifications to contracts in component-based design In Juande Lara and Andrea Zisman editors FASE volume 7212 of LectureNotes in Computer Science pages 43ndash58 Springer 2012
[23] Sebastian S Bauer Philip Mayer Andreas Schroeder and Rolf Hen-nicker On Weak Modal Compatibility Refinement and the MIOWorkbench In Proc of 16th International Conference on Tools andAlgorithms for the Construction and Analysis of Systems (TACASrsquo10)volume 6015 of Lecture Notes in Computer Science pages 175ndash189Springer 2010
[24] Andreas Baumgart Eckard Boumlde Matthias Buumlker Werner Damm Guumln-ter Ehmen Tayfun Gezgin Stefan Henkler Hardi Hungar BernhardJosko Markus Oertel Thomas Peikenkamp Philipp Reinkemeier IngoStierand and Raphael Weber Architecture Modeling Technical reportOFFIS March 2011
[25] Nikola Benes Jan Kretiacutenskyacute Kim Guldstrand Larsen and Jiriacute SrbaChecking Thorough Refinement on Modal Transition Systems IsEXPTIME-Complete In Martin Leucker and Carroll Morgan editorsICTAC volume 5684 of Lecture Notes in Computer Science pages112ndash126 Springer 2009
[26] Nikola Benes Jan Kretiacutenskyacute Kim Guldstrand Larsen and Jiriacute SrbaOn determinism in modal transition systems Theoretical ComputerScience 410(41)4026ndash4043 2009
[27] Benoicirct Caillaud and Jean-Baptiste Raclet Ensuring Reachability byDesign In Int Colloquium on Theoretical Aspects of Computing sept2012
[28] Albert Benveniste and Geacuterard Berry The synchronous approach toreactive and real-time systems Proceedings of the IEEE 79(9)1270ndash1282 1991
[29] Albert Benveniste Benoicirct Caillaud Alberto Ferrari LeonardoMangeruca Roberto Passerone and Christos Sofronis Multiple view-point contract-based specification and design In Proceedings of theSoftware Technology Concertation on Formal Methods for Componentsand Objects FMCOrsquo07 volume 5382 of Lecture Notes in ComputerScience pages 200ndash225 Springer October 2008
[30] Albert Benveniste Paul Caspi Stephen A Edwards Nicolas Halb-wachs Paul Le Guernic and Robert de Simone The SynchronousLanguages 12 years later Proceedings of the IEEE 91(1)64ndash83 2003
RR ndeg 8147
Contracts for System Design 61
[31] Luca Benvenuti Alberto Ferrari Leonardo Mangeruca EmanueleMazzi Roberto Passerone and Christos Sofronis A contract-basedformalism for the specification of heterogeneous systems In Proceed-ings of the Forum on Specification Verification and Design Languages(FDL08) pages 142ndash147 Stuttgart Germany September 23ndash25 2008
[32] Gerard Berry The effectiveness of synchronous languages for thedevelopment of safety-critical systems White paper Esterel Technolo-gies 2003
[33] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet A compositional approach on modal specifications for timedsystems In Proc of the 11th International Conference on FormalEngineering Methods (ICFEMrsquo09) volume 5885 of Lecture Notes inComputer Science pages 679ndash697 Springer 2009
[34] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet Modal event-clock specifications for timed component-baseddesign Science of Computer Programming 2011 To appear
[35] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet Modal event-clock specifications for timed component-baseddesign Science of Computer Programming 2012 to appear
[36] Nathalie Bertrand Sophie Pinchinat and Jean-Baptiste Raclet Refine-ment and consistency of timed modal specifications In Proc of the3rd International Conference on Language and Automata Theory andApplications (LATArsquo09) volume 5457 of Lecture Notes in ComputerScience pages 152ndash163 Springer 2009
[37] Antoine Beugnard Jean-Marc Jeacutezeacutequel and Noeumll Plouzeau Makingcomponents contract aware IEEE Computer 32(7)38ndash45 1999
[38] Dirk Beyer Arindam Chakrabarti and Thomas A Henzinger Webservice interfaces In Allan Ellis and Tatsuya Hagino editors WWWpages 148ndash159 ACM 2005
[39] Purandar Bhaduri and S Ramesh Interface synthesis and protocolconversion Formal Aspects of Computing 20(2)205ndash224 2008
[40] Purandar Bhaduri and Ingo Stierand A proposal for real-time interfacesin speeds In Design Automation and Test in Europe (DATErsquo10) pages441ndash446 IEEE 2010
[41] Simon Bliudze and Joseph Sifakis The Algebra of Connectors -Structuring Interaction in BIP IEEE Trans Computers 57(10)1315ndash1330 2008
[42] R Bloem and B Jobstmann Manual for property-based synthesis toolTechnical Report Prosyd D223 2006
[43] Roderick Bloem Alessandro Cimatti Karin Greimel Georg HofferekRobert Koumlnighofer Marco Roveri Viktor Schuppan and RichardSeeber RATSY - A New Requirements Analysis Tool with SynthesisIn Tayssir Touili Byron Cook and Paul Jackson editors CAV volume6174 of Lecture Notes in Computer Science pages 425ndash429 Springer2010
[44] Grady Booch James Rumbaugh and Ivar Jacobson Unified ModelingLanguage User Guide The (2nd Edition) (Addison-Wesley ObjectTechnology Series) Addison-Wesley Professional 2005
[45] Amar Bouali XEVE an Esterel Verification Environment In Alan JHu and Moshe Y Vardi editors CAV volume 1427 of Lecture Notesin Computer Science pages 500ndash504 Springer 1998
[46] Geacuterard Boudol and Kim Guldstrand Larsen Graphical versus logicalspecifications Theor Comput Sci 106(1)3ndash20 1992
[47] Jerry R Burch Trace Algebra for Automatic Verification of Real-Time Concurrent Systems PhD thesis School of Computer ScienceCarnegie Mellon University August 1992
[48] Jerry R Burch Roberto Passerone and Alberto L Sangiovanni-Vincentelli Overcoming heterophobia Modeling concurrency in het-erogeneous systems In Proceedings of the 2nd International Confer-ence on Application of Concurrency to System Design (ACSD01) pages13ndash32 Newcastle upon Tyne UK June 25ndash29 2001 IEEE ComputerSociety Los Alamitos CA USA
[49] Benoicirct Caillaud Mica A Modal Interface Compositional AnalysisLibrary October 2011 httpwwwirisafrs4toolsmica
[50] Benoicirct Caillaud Benoicirct Delahaye Kim G Larsen Axel LegayMikkel Larsen Pedersen and Andrzej Wasowski Compositional designmethodology with constraint Markov chains In Proceedings of the7th International Conference on Quantitative Evaluation of SysTems(QEST) 2010 IEEE Computer Society 2010
[51] Daniela Cancila Roberto Passerone Tullio Vardanega and MarcoPanunzio Toward correctness in the specification and handling ofnon-functional attributes of high-integrity real-time embedded systemsIEEE Transactions on Industrial Informatics 6(2)181ndash194 May 2010
[52] Karlis Cerans Jens Chr Godskesen and Kim Guldstrand LarsenTimed Modal Specification - Theory and Tools In Costas Courcou-betis editor CAV volume 697 of Lecture Notes in Computer Sciencepages 253ndash267 Springer 1993
[53] Pavol Cernyacute Martin Chmelik Thomas A Henzinger and ArjunRadhakrishna Interface simulation distances In Marco Faella andAniello Murano editors GandALF volume 96 of EPTCS pages 29ndash42 2012
[54] Arindam Chakrabarti A Framework for Compositional Design andAnalysis of Systems PhD thesis EECS Department University ofCalifornia Berkeley Dec 2007
[55] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger MarcinJurdzinski and Freddy Y C Mang Interface compatibility checkingfor software modules In Ed Brinksma and Kim Guldstrand Larseneditors CAV volume 2404 of Lecture Notes in Computer Sciencepages 428ndash441 Springer 2002
[56] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger andFreddy Y C Mang Synchronous and Bidirectional Component Inter-faces In Proc of the 14th International Conference on Computer AidedVerification (CAVrsquo02) volume 2404 of Lecture Notes in ComputerScience pages 414ndash427 Springer 2002
[57] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger andMarieumllle Stoelinga Resource Interfaces In Rajeev Alur and InsupLee editors EMSOFT volume 2855 of Lecture Notes in ComputerScience pages 117ndash133 Springer 2003
[58] Edward Y Chang Zohar Manna and Amir Pnueli Characterizationof temporal property classes In Werner Kuich editor ICALP volume623 of Lecture Notes in Computer Science pages 474ndash486 Springer1992
[59] Taolue Chen Chris Chilton Bengt Jonsson and Marta ZKwiatkowska A compositional specification theory for componentbehaviours In Helmut Seidl editor ESOP volume 7211 of LectureNotes in Computer Science pages 148ndash168 Springer 2012
[60] Chris Chilton Marta Z Kwiatkowska and Xu Wang Revisiting timedspecification theories A linear-time perspective In Marcin Jurdzinskiand Dejan Nickovic editors FORMATS volume 7595 of Lecture Notesin Computer Science pages 75ndash90 Springer 2012
[61] E Clarke O Grumberg and D Peled Model Checking MIT Press1999
[62] Edmund M Clarke David E Long and Kenneth L McMillanCompositional model checking In LICS pages 353ndash362 1989
[63] W Damm E Thaden I Stierand T Peikenkamp and H HungarUsing Contract-Based Component Specifications for Virtual Integra-tion and Architecture Design In Proceedings of the 2011 DesignAutomation and Test in Europe (DATErsquo11) March 2011 To appear
[64] Werner Damm and David Harel LSCs Breathing life into messagesequence charts Formal Methods in System Design 19(1)45ndash80 2001
[65] Werner Damm Angelika Votintseva Alexander Metzner BernhardJosko Thomas Peikenkamp and Eckard Boumlde Boosting reuse ofembedded automotive applications through rich components In Pro-ceedings of FIT 2005 - Foundations of Interface Technologies 2005
[66] Werner Damm and Bernd Westphal Live and let die LSC basedverification of UML models Sci Comput Program 55(1-3)117ndash1592005
[67] Abhijit Davare Douglas Densmore Trevor Meyerowitz AlessandroPinto Alberto Sangiovanni-Vincentelli Guang Yang and Qi Zhu Anext-generation design framework for platform-based design In DesignVerification Conference (DVCon) San Josersquo California 2007
[68] Alexandre David Kim G Larsen Axel Legay Ulrik Nyman andAndrzej Wasowski Timed IO automata A complete specificationtheory for real-time systems In Proc of the 13th ACM InternationalConference on Hybrid Systems Computation and Control (HSCCrsquo10)pages 91ndash100 ACM 2010
[69] Alexandre David Kim Guldstrand Larsen Axel Legay Ulrik Nymanand Andrzej Wasowski ECDAR An Environment for CompositionalDesign and Analysis of Real Time Systems In Proc of the 8thInternational Symposium on Automated Technology for Verificationand Analysis (ATVArsquo10) volume 6252 of Lecture Notes in ComputerScience pages 365ndash370 2010
[70] Luca de Alfaro Game Models for Open Systems In VerificationTheory and Practice volume 2772 of Lecture Notes in ComputerScience pages 269ndash289 Springer 2003
[71] Luca de Alfaro Leandro Dias da Silva Marco Faella Axel LegayPritam Roy and Maria Sorea Sociable Interfaces In Proc of
RR ndeg 8147
Contracts for System Design 62
the 5th International Workshop on Frontiers of Combining Systems(FroCosrsquo05) volume 3717 of Lecture Notes in Computer Sciencepages 81ndash105 Springer 2005
[72] Luca de Alfaro and Thomas A Henzinger Interface automata In Procof the 9th ACM SIGSOFT International Symposium on Foundations ofSoftware Engineering (FSErsquo01) pages 109ndash120 ACM Press 2001
[73] Luca de Alfaro and Thomas A Henzinger Interface theories forcomponent-based design In Thomas A Henzinger and Christoph MKirsch editors EMSOFT volume 2211 of Lecture Notes in ComputerScience pages 148ndash165 Springer 2001
[74] Luca de Alfaro Thomas A Henzinger and Marieumllle Stoelinga TimedInterfaces In Proc of the 2nd International Workshop on EmbeddedSoftware (EMSOFTrsquo02) volume 2491 of Lecture Notes in ComputerScience pages 108ndash122 Springer 2002
[75] Benoicirct Delahaye Modular Specification and Compositional Analysisof Stochastic Systems PhD thesis Universiteacute de Rennes 1 2010
[76] Benoicirct Delahaye Benoicirct Caillaud and Axel Legay ProbabilisticContracts A Compositional Reasoning Methodology for the Designof Stochastic Systems In Proc 10th International Conference onApplication of Concurrency to System Design (ACSD) Braga PortugalIEEE 2010
[77] Benoicirct Delahaye Benoicirct Caillaud and Axel Legay Probabilisticcontracts A compositional reasoning methodology for the designof systems with stochastic andor non-deterministic aspects FormalMethods in System Design 2011 To appear
[78] Benoicirct Delahaye Uli Fahrenberg Thomas A Henzinger Axel Legayand Dejan Nickovic Synchronous interface theories and time trig-gered scheduling In Holger Giese and Grigore Rosu editorsFMOODSFORTE volume 7273 of Lecture Notes in Computer Sci-ence pages 203ndash218 Springer 2012
[79] Benoicirct Delahaye Joost-Pieter Katoen Kim G Larsen Axel LegayMikkel L Pedersen Falak Sher and Andrzej Wasowski AbstractProbabilistic Automata In Ranjit Jhala and David A Schmidt editorsVMCAI volume 6538 of Lecture Notes in Computer Science pages324ndash339 Springer 2011
[80] Douglas Densmore Sanjay Rekhi and Alberto L Sangiovanni-Vincentelli Microarchitecture Development via Metropolis SuccessivePlatform Refinement In DATE pages 346ndash351 IEEE ComputerSociety 2004
[81] David L Dill Trace Theory for Automatic Hierarchical Verificationof Speed-Independent Circuits ACM Distinguished Dissertations MITPress 1989
[82] Nicolaacutes DrsquoIppolito Dario Fischbein Marsha Chechik and SebastiaacutenUchitel MTSA The Modal Transition System Analyser In Proc ofthe 23rd IEEEACM International Conference on Automated SoftwareEngineering (ASErsquo08) pages 475ndash476 IEEE 2008
[83] Laurent Doyen Thomas A Henzinger Barbara Jobstmann and TatjanaPetrov Interface theories with component reuse In Proceedings of the8th ACM amp IEEE International conference on Embedded softwareEMSOFTrsquo08 pages 79ndash88 2008
[84] Dumitru Potop-Butucaru and Stephen Edwards and Geacuterard BerryCompiling Esterel Springer V 2007 ISBN 0387706267
[85] Cindy Eisner PSL for Runtime Verification Theory and Practice InOleg Sokolsky and Serdar Tasiran editors RV volume 4839 of LectureNotes in Computer Science pages 1ndash8 Springer 2007
[86] Cindy Eisner Dana Fisman John Havlicek Michael JC GordonAnthony McIsaac and David Van Campenhout Formal Syntax andSemantics of PSL - Appendix B of Accellera LRM January 2003Technical report IBM 2003
[87] Cindy Eisner Dana Fisman John Havlicek Yoad Lustig AnthonyMcIsaac and David Van Campenhout Reasoning with temporal logicon truncated paths In Warren A Hunt Jr and Fabio Somenzi editorsCAV volume 2725 of Lecture Notes in Computer Science pages 27ndash39Springer 2003
[88] Johan Eker Joumlrn W Janneck Edward A Lee Jie Liu Xiaojun LiuJ Ludvig Stephen Neuendorffer S Sachs and Yuhong Xiong Tamingheterogeneity - the ptolemy approach Proc of the IEEE 91(1)127ndash144 2003
[89] G Feuillade Modal specifications are a syntactic fragment of the Mu-calculus Research Report RR-5612 INRIA June 2005
[90] Dario Fischbein and Sebastiaacuten Uchitel On correct and completestrong merging of partial behaviour models In Proc of the 16thACM SIGSOFT International Symposium on Foundations of SoftwareEngineering (SIGSOFT FSErsquo08) pages 297ndash307 ACM 2008
[91] F Fleurey P A Muller and J M Jzquel Weaving executabilityinto object-oriented meta-languages In Proceedgins of the 8th In-ternational Conference on Model Driven Engineering Languages andSystems (MODELS05) October 2005
[92] Freacutedeacuteric Boussinot and Robert de Simone The Esterel languageProceedings of the IEEE 79(9)1293ndash1304 1991
[93] Peter Fritzson Principles of Object-Oriented Modeling and Simulationwith Modelica 21 Wiley 2003
[94] Tayfun Gezgin Raphael Weber and Maurice Girod A RefinementChecking Technique for Contract-Based Architecture Designs InFourth International Workshop on Model Based Architecting andConstruction of Embedded Systems ACES-MBrsquo11 volume 7167 ofLecture Notes in Computer Science Springer October 2011
[95] Jens Chr Godskesen Kim Guldstrand Larsen and Arne Skou Auto-matic verification of real-time systems using Epsilon In Son T Vuongand Samuel T Chanson editors PSTV volume 1 of IFIP ConferenceProceedings pages 323ndash330 Chapman amp Hall 1994
[96] G Goumlssler and J-B Raclet Modal Contracts for Component-basedDesign In Proc of the 7th IEEE International Conference on SoftwareEngineering and Formal Methods (SEFMrsquo09) IEEE Computer SocietyPress November 2009
[97] Susanne Graf and Sophie Quinton Contracts for BIP HierarchicalInteraction Models for Compositional Verification In John Derrick andJuumlri Vain editors FORTE volume 4574 of Lecture Notes in ComputerScience pages 1ndash18 Springer 2007
[98] Orna Grumberg and David E Long Model checking and modularverification ACM Trans Program Lang Syst 16(3)843ndash871 1994
[99] Imene Ben Hafaiedh Susanne Graf and Sophie Quinton Reasoningabout Safety and Progress Using Contracts In Proc of ICFEMrsquo10volume 6447 of LNCS pages 436ndash451 Springer 2010
[100] Nicolas Halbwachs Synchronous programming of reactive systemsKluwer Academic Pub 1993
[101] Nicolas Halbwachs Fabienne Lagnier and Christophe Ratel Program-ming and Verifying Real-Time Systems by Means of the SynchronousData-Flow Language Lustre IEEE Trans Software Eng 18(9)785ndash793 1992
[102] Nicolas Halbwachs Fabienne Lagnier and Pascal Raymond Syn-chronous observers and the verification of reactive systems In MauriceNivat Charles Rattray Teodor Rus and Giuseppe Scollo editorsAMAST Workshops in Computing pages 83ndash96 Springer 1993
[103] Nicolas Halbwachs and Pascal Raymond Validation of synchronousreactive systems From formal verification to automatic testing In P SThiagarajan and Roland H C Yap editors ASIAN volume 1742 ofLecture Notes in Computer Science pages 1ndash12 Springer 1999
[104] David Harel Statecharts A visual formalism for complex systemsSci Comput Program 8(3)231ndash274 1987
[105] David Harel Hillel Kugler Shahar Maoz and Itai Segall Acceleratingsmart play-out In Jan van Leeuwen Anca Muscholl David PelegJaroslav Pokornyacute and Bernhard Rumpe editors SOFSEM volume5901 of Lecture Notes in Computer Science pages 477ndash488 Springer2010
[106] David Harel Robby Lampert Assaf Marron and Gera Weiss Model-checking behavioral programs In Samarjit Chakraborty Ahmed Jer-raya Sanjoy K Baruah and Sebastian Fischmeister editors EMSOFTpages 279ndash288 ACM 2011
[107] David Harel and Rami Marelly Come Letrsquos Play Scenario-BasedProgramming Using LSCs and the Play-Engine Springer-Verlag 2003httpwwwwisdomweizmannacil~harelComeLetsPlaypdf
[108] David Harel Assaf Marron and Gera Weiss Behavioral programmingCommun ACM 55(7)90ndash100 2012
[109] David Harel Assaf Marron Guy Wiener and Gera Weiss Behavioralprogramming decentralized control and multiple time scales InCristina Videira Lopes editor SPLASH Workshops pages 171ndash182ACM 2011
[110] David Harel and Amir Pnueli On the development of reactive systemsIn K R Apt editor Logic and Models for Verification and Specificationof Concurrent Systems volume F13 of NATO ASI Series pages 477ndash498 Springer-Verlag 1985
[111] H Heinecke W Damm B Josko A Metzner H KopetzA Sangiovanni-Vincentelli and M Di Natale Software Componentsfor Reliable Automotive Systems In Design Automation and Test inEurope 2008 DATE rsquo08 pages 549ndash554 march 2008
[112] Thomas A Henzinger and Dejan Nickovic Independent imple-mentability of viewpoints In Radu Calinescu and David Garlan edi-
RR ndeg 8147
Contracts for System Design 63
tors Monterey Workshop volume 7539 of Lecture Notes in ComputerScience pages 380ndash395 Springer 2012
[113] C A R Hoare An axiomatic basis for computer programmingCommun ACM 12(10)576ndash580 1969
[114] INCOSE Incose systems engineering handbook 2010 httpwwwincoseorgProductsPubsproductssehandbookaspx
[115] Cliff B Jones Specification and design of (parallel) programs In IFIPCongress pages 321ndash332 1983
[116] B Jonsson and K G Larsen Specification and refinement ofprobabilistic processes In Logic in Computer Science (LICS) pages266ndash277 IEEE Computer 1991
[117] Gilles Kahn The Semantics of Simple Language for Parallel Program-ming In IFIP Congress pages 471ndash475 1974
[118] S Karris Introduction to Simulink with Engineering ApplicationsOrchard Publications 2006
[119] G Karsai J Sztipanovits A Ledeczi and T Bapty Model-integrated development of embedded software Proceedings of theIEEE 91(1)145ndash164 January 2003
[120] Gabor Karsai Janos Sztipanovitz Akos Ledczi and Ted Bapty Model-integrated development of embedded software Proceedings of theIEEE 91(1) January 2003
[121] Orna Kupferman and Moshe Y Vardi Modular model checking InWillem P de Roever Hans Langmaack and Amir Pnueli editorsCOMPOS volume 1536 of Lecture Notes in Computer Science pages381ndash401 Springer 1997
[122] Leslie Lamport Proving the correctness of multiprocess programsIEEE Trans Software Eng 3(2)125ndash143 1977
[123] C Larman and VR Basili Iterative and incremental developments abrief history Computer 36(6)47ndash56 June 2003
[124] Kim G Larsen and L Xinxin Equation solving using modal transitionsystems In Proceedings of the 5th Annual IEEE Symp on Logic inComputer Science LICSrsquo90 pages 108ndash117 IEEE Computer SocietyPress 1990
[125] Kim Guldstrand Larsen Modal specifications In Automatic Verifica-tion Methods for Finite State Systems volume 407 of Lecture Notes inComputer Science pages 232ndash246 Springer 1989
[126] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski In-terface InputOutput Automata In Jayadev Misra Tobias Nipkowand Emil Sekerinski editors FM volume 4085 of Lecture Notes inComputer Science pages 82ndash97 Springer 2006
[127] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski ModalIO Automata for Interface and Product Line Theories In ProgrammingLanguages and Systems 16th European Symposium on ProgrammingESOPrsquo07 volume 4421 of Lecture Notes in Computer Science pages64ndash79 Springer 2007
[128] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski OnModal Refinement and Consistency In Proc of the 18th InternationalConference on Concurrency Theory (CONCURrsquo07) pages 105ndash119Springer 2007
[129] Kim Guldstrand Larsen Bernhard Steffen and Carsten Weise A con-straint oriented proof methodology based on modal transition systemsIn Proc of the 1st International Workshop on Tools and Algorithmsfor Construction and Analysis of Systems (TACASrsquo95) volume 1019of Lecture Notes in Computer Science pages 17ndash40 Springer 1995
[130] Kim Guldstrand Larsen and Bent Thomsen A Modal Process LogicIn Proceedings of the Third Annual Symposium on Logic in ComputerScience (LICSrsquo88) pages 203ndash210 IEEE 1988
[131] A Ledeczi A Bakay M Maroti P Volgyesi G Nordstrom J Sprin-kle and G Karsai Composing domain-specific design environmentsIEEE Computer 34(11)44 ndash51 November 2001
[132] Akos Ledeczi Miklos Maroti Arpad Bakay Gabor Karsai JasonGarrett Charles Thomason Greg Nordstrom Jonathan Sprinkle andPeter Volgyesi The generic modeling environment In Proceedingsof the IEEE International Workshop on Intelligent Signal Processing(WISP2001) Budapest Hungary May 24ndash25 2001
[133] Edward A Lee Cyber physical systems Design challenges TechnicalReport UCBEECS-2008-8 EECS Department University of Califor-nia Berkeley Jan 2008
[134] Nancy A Lynch Inputoutput automata Basic timed hybrid proba-bilistic dynamic In Roberto M Amadio and Denis Lugiez editorsCONCUR volume 2761 of Lecture Notes in Computer Science pages187ndash188 Springer 2003
[135] Nancy A Lynch and Eugene W Stark A proof of the kahn principlefor inputoutput automata Inf Comput 82(1)81ndash92 1989
[136] Zohar Manna and Amir Pnueli Temporal verification of reactivesystems Safety Springer 1995
[137] Herveacute Marchand Patricia Bournai Michel Le Borgne and Paul LeGuernic Synthesis of Discrete-Event Controllers Based on the SignalEnvironment Discrete Event Dynamic Systems 10(4)325ndash346 2000
[138] Herveacute Marchand and Mazen Samaan Incremental Design of aPower Transformer Station Controller Using a Controller SynthesisMethodology IEEE Trans Software Eng 26(8)729ndash741 2000
[139] B Meyer Applying ldquodesign by contractrdquo IEEE Computer 25(10)40ndash51 October 1992
[140] Bertrand Meyer Touch of Class Learning to Program Well UsingObject Technology and Design by Contract Springer SoftwareEngineering 2009
[141] MW Maier Architecting Principles for Systems of Systems SystemsEngineering 1(4)267ndash284 1998
[142] Walid A Najjar Edward A Lee and Guang R Gao Advances in thedataflow computational model Parallel Computing 25(13-14)1907ndash1929 1999
[143] Radu Negulescu Process Spaces and the Formal Verification ofAsynchronous Circuits PhD thesis University of Waterloo Canada1998
[144] Nicolas Halbwachs and Paul Caspi and Pascal Raymond and DanielPilaud The synchronous data flow programming language LustreProceedings of the IEEE 79(9)1305ndash1320 1991
[145] P Nuzzo A Sangiovanni-Vincentelli X Sun and A PuggelliMethodology for the design of analog integrated interfaces usingcontracts IEEE Sensors Journal 12(12)3329ndash3345 Dec 2012
[146] Object Management Group (OMG) Model driven architecture (MDA)FAQ [online] httpwwwomgorgmda
[147] Object Management Group (OMG) Unified Modeling Language(UML) specification [online] httpwwwomgorgspecUML
[148] Object Management Group (OMG) A UML profile for MARTE beta1 OMG Adopted Specification ptc07-08-04 OMG August 2007
[149] Object Management Group (OMG) System modeling languagespecification v11 Technical report OMG 2008
[150] Object constraint language version 20 OMG Available Specificationformal06-05-01 Object Management Group May 2006
[151] The Design Automation Standards Committee of the IEEE Com-puter Society editor 1850-2010 - IEEE Standard for PropertySpecification Language (PSL) IEEE Computer Society 2010
[152] J Hudak P Feiler D Gluch The Architecture Analysis and DesignLanguage (AADL) An Introduction Software Engineering Institute(SEI) Technical Note CMUSEI-2006-TN-011 February 2006
[153] Roberto Passerone Semantic Foundations for Heterogeneous SystemsPhD thesis Department of Electrical Engineering and Computer Sci-ences University of California Berkeley Berkeley CA 94720 May2004
[154] Roberto Passerone Jerry R Burch and Alberto L Sangiovanni-Vincentelli Refinement preserving approximations for the design andverification of heterogeneous systems Formal Methods in SystemDesign 31(1)1ndash33 August 2007
[155] Roberto Passerone Luca de Alfaro Thomas A Henzinger and AlbertoSangiovanni-Vincentelli Convertibility verification and converter syn-thesis Two faces of the same coin In Proceedings of InternationalConference on Computer Aided Design San Jose CA 2002
[156] Roberto Passerone Imene Ben Hafaiedh Susanne Graf Albert Ben-veniste Daniela Cancila Arnaud Cuccuru Seacutebastien Geacuterard FrancoisTerrier Werner Damm Alberto Ferrari Leonardo Mangeruca Bern-hard Josko Thomas Peikenkamp and Alberto Sangiovanni-VincentelliMetamodels in Europe Languages tools and applications IEEEDesign and Test of Computers 26(3)38ndash53 MayJune 2009
[157] Paul Le Guernic and Thiserry Gautier and Michel Le Borgne andClaude Le Maire Programming real-time applications with SignalProceedings of the IEEE 79(9)1321ndash1336 1991
[158] I Pill B Jobstmann R Bloem R Frank M Moulin B SterinM Roveri and S Semprini Property simulation Technical ReportProsyd D121 2005
[159] Dumitru Potop-Butucaru Benoicirct Caillaud and Albert BenvenisteConcurrency in synchronous systems Formal Methods in SystemDesign 28(2)111ndash130 2006
[160] Dumitru Potop-Butucaru Robert de Simone and Yves Sorel Neces-sary and sufficient conditions for deterministic desynchronization InChristoph M Kirsch and Reinhard Wilhelm editors EMSOFT pages124ndash133 ACM 2007
RR ndeg 8147
Contracts for System Design 64
[161] Terry Quatrani Visual modeling with Rational Rose 2000 and UML(2nd ed) Addison-Wesley Longman Ltd Essex UK UK 2000
[162] R Sudarsan and SJ Fenves and RD Sriram and F Wang A productinformation modeling framework for product lifecycle managementComputer-Aided Design 371399ndash1411 2005
[163] Jean-Baptiste Raclet Quotient de speacutecifications pour la reacuteutilisationde composants PhD thesis Ecole doctorale Matisse universiteacute deRennes 1 November 2007
[164] Jean-Baptiste Raclet Residual for Component Specifications In Procof the 4th International Workshop on Formal Aspects of ComponentSoftware (FACSrsquo07) 2007
[165] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct CaillaudAxel Legay and Roberto Passerone Modal interfaces Unifyinginterface automata and modal specifications In Proceedings of theNinth International Conference on Embedded Software (EMSOFT09)pages 87ndash96 Grenoble France October 12ndash16 2009
[166] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct CaillaudAxel Legay and Roberto Passerone A modal interface theory forcomponent-based design Fundamenta Informaticae 108(1-2)119ndash149 2011
[167] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct Caillaudand Roberto Passerone Why are modalities good for interfacetheories In Proc of the 9th International Conference on Applicationof Concurrency to System Design (ACSDrsquo09) IEEE Computer SocietyPress 2009
[168] Richard Payne and John Fitzgerald Evaluation of ArchitecturalFrameworks Supporting Contract-Based Specification Technical Re-port CS-TR-1233 Computing Science Newcastle University UK Dec2010 available from httpwwwcsnclacukpublicationstrspapers1233pdf
[169] Robert W Floyd Assigning meaning to programs In JT Schwartzeditor Proceedings of Symposium on Applied Mathematics volume 19pages 19ndash32 1967
[170] A Sangiovanni-Vincentelli S Shukla J Sztipanovits G Yang andD Mathaikutty Metamodeling An emerging representation paradigmfor system-level design Special Section on Meta-Modeling IEEEDesign and Test 26(3)54ndash69 2009
[171] Alberto Sangiovanni-Vincentelli Quo vadis sld Reasoning aboutthe trends and challenges of system level design Proc of the IEEE95(3)467ndash506 2007
[172] D Schmidt Model-driven engineering IEEE Computer pages 25ndash31February 2006
[173] German Sibay Sebastian Uchitel and Viacutector Braberman ExistentialLive Sequence Charts Revisited In ICSE 2008 30th InternationalConference on Software Engineering ACM May 2008
[174] Joseph Sifakis Component-Based Construction of HeterogeneousReal-Time Systems in Bip In Giuliana Franceschinis and KarstenWolf editors Petri Nets volume 5606 of Lecture Notes in ComputerScience page 1 Springer 2009
[175] Functional safety of electricalelectronicprogrammable electronicsafety-related systems Standard IEC 61508
[176] Eugene W Stark A proof technique for relyguarantee properties InS N Maheshwari editor FSTTCS volume 206 of Lecture Notes inComputer Science pages 369ndash391 Springer 1985
[177] Stavros Tripakis Ben Lickly Thomas A Henzinger and Edward ALee On relational interfaces In Proc of the 9th ACM amp IEEEInternational conference on Embedded software (EMSOFTrsquo09) pages67ndash76 ACM 2009
[178] Stavros Tripakis Ben Lickly Thomas A Henzinger and Edward ALee A theory of synchronous relational interfaces ACM TransProgram Lang Syst 33(4)14 2011
[179] Sebastiaacuten Uchitel and Marsha Chechik Merging partial behaviouralmodels In Proc of the 12th ACM SIGSOFT International Symposiumon Foundations of Software Engineering (SIGSOFT FSErsquo10) pages43ndash52 ACM 2004
[180] Jos Warmer and Anneke Kleppe The Object Constraint LanguageGetting Your Models Ready for MDA Addison-Wesley LongmanPublishing Co Inc Boston MA USA 2nd edition 2003
RR ndeg 8147
RESEARCH CENTRERENNES ndash BRETAGNE ATLANTIQUE
Campus universitaire de Beaulieu35042 Rennes Cedex
PublisherInriaDomaine de Voluceau - RocquencourtBP 105 - 78153 Le Chesnay Cedexinriafr
ISSN 0249-6399
- Introduction
-
- The Present System Design
- The Future CPS and SoS
- The Need for a Methodological Effort
- Contract based design
- Readers guide
-
- System Design Challenges
-
- Complexity of Systems
- Complexity of OEM-Supplier Chains
- Managing Requirements
- Managing Risks
- System-wide Optimization
-
- How Challenges have been addressed so far
-
- Complexity of Systems and System-wide Optimization
-
- Layered design
- Component-based design
- The V-model process
- Model-Based Design
- Virtual Integration
- Platform Based Design
-
- Complexity of OEM-Supplier Chains Standardization and Harmonization
-
- Standardization of design entities
- Harmonization of processes and certification
-
- Managing Requirements Traceability and Multiple Viewpoints
- Cross-company Shared Risk Management
- The Need for Contracts
-
- Contracts what why where and how
-
- Contracts
-
- Components and their Environment Contracts
-
- Contract Operators
-
- Contract Composition and System Integration
- Contract Refinement and Independent Development
- Contract Conjunction and Viewpoint Fusion
-
- Contracts in requirement engineering
- Contract Support for Design Methodologies
-
- Supporting open systems
- Managing Requirements and Fusing Viewpoints
- Design Chain Management Re-using and Independent Development
- Deployment and Mapping
-
- Bibliographical note
-
- A Mathematical Meta-theory of Contracts
-
- Components and their composition
- Contracts
- Refinement and conjunction
- Contract composition
- Quotient
- Discussion
- Observers
- Bibliographical note
-
- Panorama of concrete theories
- Panorama AssumeGuarantee contracts
-
- Dataflow AG contracts
- Capturing exceptions
- Dealing with variable alphabets
- Synchronous AG contracts
- Observers
- Discussion
- Bibliographical note
-
- Panorama Interface theories
-
- Components as io-automata
- Interface Automata with fixed alphabet
- Modal Interfaces with fixed alphabet
- Modal Interfaces with variable alphabet
- Projecting and Restricting
- Observers
- Bibliographical note
-
- Panorama Timed Interface Theories
-
- Components as Event-Clock Automata
- Modal Event-Clock Specifications
- Bibliographical note
-
- Panorama Probabilistic Interface Theories
-
- Components as Probabilistic Automata
- Simple Modal Probabilistic Interfaces
- Bibliographical note
-
- The Parking Garage an example in Requirements Engineering
-
- The contract framework
- Top level requirements
- Formalizing requirements as contracts
- Sub-contracting to suppliers
- The four ``C
-
- Consistency amp Compatibility
- Correctness
- Completeness
-
- Discussion
-
- Contracts in the context of Autosar
-
- The Autosar context
- The contract framework
- Exterior Light Management System
-
- Function and timing
- Safety
-
- Integrating Contracts in Autosar
- Summary and discussion
-
- Conclusion
-
- What contracts can do for the designer
- Status of research
- Status of practice
- The way forward
-
- References
-
RESEARCH CENTRERENNES ndash BRETAGNE ATLANTIQUE
Campus universitaire de Beaulieu35042 Rennes Cedex
Contracts for Systems Design
Albert Benvenistelowast Benoicirct Caillauddagger Dejan NickovicDagger
Roberto Passeronesect Jean-Baptiste Racletpara Philipp Reinkemeier
Alberto Sangiovanni-Vincentellilowastlowast Werner Dammdaggerdagger
Tom HenzingerDaggerDagger Kim Larsen
Project-Teams S4
Research Report ndeg 8147 mdash November 2012 mdash 64 pages
This work was funded in part by the European STREP-COMBEST project number 215543 the European projects CESAR of the ARTEMIS JointUndertaking and the European IP DANSE the Artist Design Network of Excellence number 214373 the MARCO FCRP TerraSwarm grant the iCyPhyprogram sponsored by IBM and United Technology Corporation the VKR Center of Excellence MT-LAB and the German Innovation Alliance on EmbeddedSystems SPES2020
lowast INRIA Rennes France corresp author AlbertBenvenisteinriafrdagger INRIA Rennes FranceDagger Austrian Institute of Technology (AIT)sect University of Trento Italypara IRIT-CNRS Toulouse France Offis and University of Oldenburglowastlowast University of California at Berkeleydaggerdagger Offis and University of OldenburgDaggerDagger IST Austria Klosterneuburg
Aalborg University Danmark
Abstract Systems design has become a key challenge and differentiating factor over the last decadesfor system companies Aircrafts trains cars plants distributed telecommunication military or health caresystems and more involve systems design as a critical step Complexity has caused system design timesand costs to go severely over budget so as to threaten the health of entire industrial sectors Heuristicmethods and standard practices do not seem to scale with complexity so that novel design methods andtools based on a strong theoretical foundation are sorely neededModel-based design as well as other methodologies such as layered and compositional design have beenused recently but a unified intellectual framework with a complete design flow supported by formaltools is still lacking albeit some attempts at this framework such as Platform-based Design have beensuccessfully deployedRecently an rdquoorthogonalrdquo approach has been proposed that can be applied to all methodologies proposedthus far to provide a rigorous scaffolding for verification analysis and abstractionrefinement contract-based design Several results have been obtained in this domain but a unified treatment of the topic thatcan help in putting contract-based design in perspective is still missing This paper intends to providesuch treatment where contracts are precisely defined and characterized so that they can be used in designmethodologies such as the ones mentioned above with no ambiguity In addition the paper provides animportant link between interfaces and contracts to show similarities and correspondences Examples ofthe use of contracts in design are provided as well as in depth analysis of existing literature
Key-words system design component based design contract interface
Contrats pour la conception de systegravemesReacutesumeacute Cet article fait le point sur le concept de contrat pour la conception de systegravemes Les contrats que nous proposonsportent non seulement sur des proprieacuteteacutes de typage de leurs interfaces mais incluent une description abstraite de comportementsNous proposons une meacuteta-theacuteorie ou si lrsquoon veut une theacuteorie geacuteneacuterique des contrats qui permet le deacuteveloppement seacutepareacute desous-systegravemes Nous montrons que cette meacuteta-theacuteorie se speacutecialise en lrsquoune ou lrsquoautre des theacuteories connues
Mots-cleacutes conception des systegravemes composant contrat interface
Contracts for System Design 4
CONTENTS
I Introduction 6I-A The Present System Design 6I-B The Future CPS and SoS 6I-C The Need for a Methodological Effort 6I-D Contract based design 7I-E Readerrsquos guide 7
II System Design Challenges 8II-A Complexity of Systems 8II-B Complexity of OEM-Supplier Chains 9II-C Managing Requirements 9II-D Managing Risks 10II-E System-wide Optimization 10
III How Challenges have been addressed so far 10III-A Complexity of Systems and System-
wide Optimization 10III-A1 Layered design 11III-A2 Component-based design 11III-A3 The V-model process 11III-A4 Model-Based Design 12III-A5 Virtual Integration 12III-A6 Platform Based Design 13
III-B Complexity of OEM-Supplier ChainsStandardization and Harmonization 13III-B1 Standardization of design
entities 13III-B2 Harmonization of processes
and certification 14III-C Managing Requirements Traceability
and Multiple Viewpoints 14III-D Cross-company Shared Risk Management 14III-E The Need for Contracts 15
IV Contracts what why where and how 16IV-A Contracts 16
IV-A1 Components and their Envi-ronment Contracts 16
IV-B Contract Operators 17IV-B1 Contract Composition and
System Integration 17IV-B2 Contract Refinement and In-
dependent Development 18IV-B3 Contract Conjunction and
Viewpoint Fusion 18IV-C Contracts in requirement engineering 19IV-D Contract Support for Design Method-
ologies 20IV-D1 Supporting open systems 20IV-D2 Managing Requirements and
Fusing Viewpoints 20IV-D3 Design Chain Management
Re-using and IndependentDevelopment 21
IV-D4 Deployment and Mapping 21IV-E Bibliographical note 23
V A Mathematical Meta-theory of Contracts 24V-A Components and their composition 24V-B Contracts 25V-C Refinement and conjunction 25V-D Contract composition 26V-E Quotient 27V-F Discussion 27V-G Observers 27V-H Bibliographical note 28
VI Panorama of concrete theories 29
VII Panorama AssumeGuarantee contracts 29VII-A Dataflow AG contracts 30VII-B Capturing exceptions 30VII-C Dealing with variable alphabets 31VII-D Synchronous AG contracts 32VII-E Observers 32VII-F Discussion 32VII-G Bibliographical note 32
VIII Panorama Interface theories 33VIII-A Components as io-automata 33VIII-B Interface Automata with fixed alphabet 34VIII-C Modal Interfaces with fixed alphabet 35VIII-D Modal Interfaces with variable alphabet 37VIII-E Projecting and Restricting 38VIII-F Observers 40VIII-G Bibliographical note 40
IX Panorama Timed Interface Theories 42IX-A Components as Event-Clock Automata 42IX-B Modal Event-Clock Specifications 43IX-C Bibliographical note 43
X Panorama Probabilistic Interface Theories 44X-A Components as Probabilistic Automata 44X-B Simple Modal Probabilistic Interfaces 45X-C Bibliographical note 45
XI The Parking Garage an example in Require-ments Engineering 45
XI-A The contract framework 45XI-B Top level requirements 46XI-C Formalizing requirements as contracts 46XI-D Sub-contracting to suppliers 48XI-E The four ldquoCrdquo 49
XI-E1 Consistency amp Compatibility 49XI-E2 Correctness 50XI-E3 Completeness 50
XI-F Discussion 50
RR ndeg 8147
Contracts for System Design 5
XII Contracts in the context of AUTOSAR 50XII-A The AUTOSAR context 50XII-B The contract framework 51XII-C Exterior Light Management System 51
XII-C1 Function and timing 51XII-C2 Safety 56
XII-D Integrating Contracts in AUTOSAR 58XII-E Summary and discussion 59
XIII Conclusion 59XIII-A What contracts can do for the designer 59XIII-B Status of research 59XIII-C Status of practice 59XIII-D The way forward 59
References 60
RR ndeg 8147
Contracts for System Design 6
I INTRODUCTION
A The Present System Design
System companies such as automotive avionics and con-sumer electronics companies are facing significant difficultiesdue to the exponentially raising complexity of their productscoupled with increasingly tight demands on functionalitycorrectness and time-to-market The cost of being late tomarket or of imperfections in the products is staggering aswitnessed by the recent recalls and delivery delays that systemindustries had to bear
In 2010 Toyota had to recall 10 Million cars worldwidefor reasons that ranged from the infamous sticky acceleratorpedals to steering and engine problems The last recall atthe end of August 2010 was for the engine control moduleToyota is not alone in this situation Most of the automotivemakers had one or more major recalls in the recent past(see eg httpwwwautorecallsus) involving electronics aswell as mechanical parts Boeing and Airbus Industries hadsignificant delays in the delivery of their latest planes (787and A380) For the A380 underlying causes were cited asissues in the cabling system configuration management anddesign process In particular the complexity of the cabinwiring (100000 wires and 40300 connectors) was considereda major issue (see httpenwikipediaorgwikiAirbus_A380)The delays caused the departure of both the EADS and AirbusCEOs and of the program manager for the A380 and caused anoverall earning shortfall of 48 Billion Euros Boeing originallyplanned the first flight of the 787 for August 2007 (seehttpenwikipediaorgwikiBoeing_787) but after a streamof delay announcements the actual first flight occurred onDecember 15 2009 The delays were caused by a number ofunfortunate events and design errors and caused at least a 23Billion USD write-off not counting the claim of Air India of1 Billion USD damages for delayed delivery and the revenueshortfalls
These are examples of the devastating effects that designproblems may cause The specific root causes of these prob-lems are complex and relate to a number of issues rangingfrom design processes and relationships with different depart-ments of the same company and with suppliers to incompleterequirement specification and testing
B The Future CPS and SoS
Many products and services require to take into considera-tion the interactions of computational and physical processesSystems where this interaction is tight and needs special careare called Cyber-Physical Systems (CPS) [133] The broadmajority of these new applications can be classified as ldquodis-tributed sense and control systemsrdquo that go substantially be-yond the ldquocomputerdquo or ldquocommunicaterdquo functions traditionallyassociated with information technology These applicationshave the potential to radically influence how we deal with abroad range of crucial problems facing our society today forexample national security and safety including surveillanceenergy management and distribution environment control
efficient and reliable transportation and mobility and effectiveand affordable health care A recurring property of theseapplications is that they engage all the platform componentssimultaneouslymdashfrom data and computing services on thecloud of large-scale servers data gathering from the sensoryswarm and data access on mobile devicesmdashwith significantheterogeneity These large scale systems composed of subsys-tems that are themselves systems are now called Systems ofSystems (SoS) and are heavily investigated
As the complexity of these systems increases our inabilityto rigorously model the interactions between the physical andthe cyber sides creates serious vulnerabilities Systems becomeunsafe with disastrous inexplicable failures that could not havebeen predicted The challenges in the realization and operationof these CPS and SoS are manifold and cover a broad range oflargely unsolved design and run-time problems These includemodeling and abstraction verification validation and testreliability and resiliency multi-scale technology integrationand mapping power and energy security diagnostics andrun-time management Failure to address these challengesin a cohesive and comprehensive way will most certainlydelay if not prohibit the widespread adoption of these newtechnologies
C The Need for a Methodological Effort
We believe the most promising means to address the chal-lenges in systems engineering is to employ structured andformal design methodologies that seamlessly and coherentlycombine the various dimensions of the design space (be itbehavior space or time) that provide the appropriate abstrac-tions to manage the inherent complexity and that can pro-vide correct-by-construction implementations The followingtechnology issues must be addressed when developing newapproaches to the design of complex systems CPS and SoSbull The overall design flows for heterogeneous systemsmdash
meant here both in a technical and also an organiza-tional sensemdashand the associated use of models acrosstraditional boundaries are not well developed and un-derstood Relationships between different teams inside asame company or between different stake-holders in thesupplier chain are not well supported by solid technicaldescriptions for the mutual obligations
bull System requirement capture and analysis is in largepart a heuristic process where the informal text andnatural language-based techniques in use today are facingsignificant challenges Formal requirement engineeringis in its infancy mathematical models formal analysistechniques and links to system implementation must bedeveloped
bull Dealing with variability uncertainty and life-cycle issuessuch as extensibility of a product family are not well-addressed using available systems engineering methodol-ogy and tools
bull Design-space exploration is rarely performed adequatelyyielding suboptimal designs where the architecture se-lection phase does not consider extensibility re-usability
RR ndeg 8147
Contracts for System Design 7
and fault tolerance to the extent that is needed to reducecost failure rates and time-to-market
bull The verification and validation of ldquocomplex systemsrdquoparticularly at the system integration phase where anyinteractions are complicated and extremely costly toaddress is a common need in defense automotive andother industries
The challenge is to address the entire process and not toconsider only point solutions of methodology tools andmodels that ease part of the design
D Contract based design
It is our goal to offer a new approach to the system designproblem that is rigorous and effective in dealing with theproblems and challenges described before and that at thesame time does not require a radical change in the wayindustrial designers carry out their task as it cuts across designflows of different type contract-based design
Contracts in the layman use of the term are establishedwhen an OEM must agree with its suppliers on the subsystemor component to be delivered Contracts involve a legal partbinding the different parties and a technical annex that servesas a reference regarding the entity to be delivered by thesuppliermdashin this work we focus on the technical facet ofcontracts Contracts can also be used through their technicalannex in concurrent engineering when different teams developdifferent subsystems or different aspects of a system within asame company
In this paper we argue that contracts can be actually usedalmost everywhere and at nearly all stages of system designfrom early requirements capture to embedded computinginfrastructure and detailed design involving circuits and otherhardware Contracts explicitly handle pairs of properties re-spectively representing the assumptions on the environmentand the guarantees of the system under these assumptionsIntuitively a contract is a pair
C = (AG) of Assumptions Guarantees
characterizing in a formal way 1) under which context thedesign is assumed to operate and 2) what its obligations areAssumeGuarantee reasoning has been known for quite sometime but it has been used mostly as verification mean for thedesign of software Our purpose is more ambitious contractbased design with explicit assumptions is a philosophy thatshould be followed all along the design with all kinds ofmodels whenever necessary Here the models we mean arerichmdashnot only profiles types or taxonomy of data but alsomodels describing the functions performances of variouskinds (time and energy) and safety The consideration of richcontracts as above in the industry is still in its infancy Tomake contract-based design a technique of choice for systemengineers we must developbull Mathematical foundations for contract representation and
requirement engineering that enable the design of frame-works and tools
bull A system engineering framework and associated method-ologies and tool sets that focus on system requirementmodeling contract specification and verification at mul-tiple abstraction layers The framework should addresscross-boundary and cross-organizational design activities
This paper intends to provide a unified treatment of contractswhere they are precisely defined and characterized so that theycan be used in design with no ambiguity In addition the paperprovides an important link between interfaces and contractsto show similarities and correspondences Examples of the useof contracts in design will be provided as well as in depthanalysis of existing literature
E Readerrsquos guide
The organization of the paper is explained in Table IIn Section II a review of the challenges that are faced by the
system industry is proposed followed in Section III by ananalysis of the design methodologies that have been deployedto cope with them
Section IV develops a primer on contracts by using a verysimple example requiring only elementary mathematical back-ground to be followed Its purpose is to smoothly introducethe different concepts and operations we need for a contractframeworkmdashthe restricted case considered is by no meansrepresentative of the kind of system we can address usingcontracts We then introduce a motivating example repre-sentative of requirement engineering In a third sub-sectionldquorequirementsrdquo on a theory of contracts are identified fromanalyzing what is expected from contract-based design andin particular the support for 1) the development of differentaspects or viewpoints of a system such as its function safetytiming and resource use by different teams and how to fusethese different aspects and 2) the possibility for differentsuppliers to develop independently the different subsystemssubcontracted to them This section concludes with the relatedbibliography
Section V is the cornerstone of this paper and it is a newvista on contracts The so-called ldquometa-theoryrdquo of contractsis introduced and developed in detail By meta-theory wemean the collection of concepts operations and propertiesthat any formal contract framework should offer Conceptsoperations and properties are thus stated in a fairly genericway Every concrete framework compliant with this meta-theory will inherit these generic properties The meta-theoryfocuses on assumptions and guarantees its formalizes howdifferent aspects or viewpoints of a specification can beintegrated and on which basis independent development bydifferent suppliers can be safely performed
So far the meta-theory is non effective in that it is notsaid how component and contracts are effectively representedand manipulated The subsequent series of sections propose apanorama of major concrete contract frameworks Section VIIdevelops the AssumeGuarantee contracts This framework isthe most straightforward instance of the meta-theory It dealswith pairs (AG) of assumptions and guarantees explicitlyA and G being both expressed as properties This framework
RR ndeg 8147
Contracts for System Design 8
Section methodological tutorial fundamental technical applicationSection IIchallengesSection IIIaddressing the challengesSection IVwhy contracts where and how
Section Vcontract meta-theory
Section VIIAssumeGuarantee contractsSection VIIIInterface theoriesSection IXtimedSection Xprobabilistic
Section XIrequirements engineeringSection XIIAUTOSAR
Section IIdarr
Section III Section IV
Section V Section VII mdash Section VIIIdarr darr
Section XII Section XI
Section IX mdash Section Xdarr darr
Section Section
Section IIdarr
Section III Section IV
Section V Section XI Section XII
Table IREADERrsquoS GUIDE CATEGORIZATION OF THE DIFFERENT SECTIONS (TOP) AND
DEPENDENCIES (BOTTOM LEFT IN-DEPTH READING BOTTOM-RIGHT QUICK READING)
is flexible in that it allows for different styles of descriptionof such propertiesmdashcomputational efficiency depends on thestyle adopted Section VIII develops the Interface theoriesin which assumptions and guarantees are specified by meansof a single object the interface Interface theories turn outto include the most effective frameworks They can easily beadapted to encompass timing (Section IX) and probabilistic(Section X) characteristics of systems
In Section XI a toy example in requirements engineeringis developed This example is simple but rich enough to illus-trate the very difficulties in formalizing requirements It alsoillustrates well the added value of contract based requirementsengineering First the different responsibilities (assumptionsversus obligation or guarantees) that requirement implicit referto are made explicit and captured in our contract frameworkSecond contracts offer a formal meaning for documents ofrequirements structured into chapters or viewpoints Contractsoffer formal support for checking important properties suchas consistency compatibility completeness and more Finallycontracts offer significant assistance in the process of deduc-ing from the top specification an architecture of specificationsfor the different sub-systems for independent developmentWhile our application example is a toy one is it neverthelesstoo complex for dealing with it by hand We handle it by usinga proof-of-concept tool for contract management
Finally Section XII develops a case study in the contextof AUTOSAR AUTOSAR is a recently established standardin the automobile sector This standard was developed withthe objective of allowing for better flexibility in componentreuse and OEMsupplier relations This section illustrates howcontracts can be used to break into simple pieces of reasoningthe difficult task of correct system integration
II SYSTEM DESIGN CHALLENGES
Many challenges face the system community to deliverproducts that are reliable and effective We summarize someof them below
A Complexity of Systems
The ever-expanding use of electronic embedded systems tocontrol increasingly many aspects of the real world and thetrend to interconnect more and more such systems (often fromdifferent manufacturers) into a global network are creating achallenging scenario for system designers In this scenario thethree challenges that are taking center stage are as follows
The Hardware Platform Complexity Most system com-panies rely on Components off-the-shelf (COTS) and pro-grammability to implement their applications For companieswho build ldquophysically largerdquo systems such as avionics and au-tomotive companies the complexity of the hardware platform
RR ndeg 8147
Contracts for System Design 9
Design task Tasks Tasks Tasks Tasks Tasks Tasksdelayed delayed delayed causing delay causing delay causing delayautomotive automation medical automotive automation medical
System integration 630 565 667 423 190 375test and verificationSystem architecture 296 261 333 385 429 313design and specificationSoftware application 444 304 750 269 310 250andor middlewaredevelopment and testProject management 370 283 167 538 381 375and planning
Table IIDIFFICULTIES RELATED TO SYSTEM INTEGRATION
is reflected in the number of Electronic Control Units and intheir interconnections For a top-of-the-line automobile thenumber of processors to manage and interconnect is above50 The layout of the cables that connect these processingelements with sensors and actuators is a serious concern Initialproduction of the Airbus A380 was troubled by delays in partattributed to the 530 km (330 mi) of wiring in each aircraft
The Embedded Software Complexity Given the cost andrisks associated to developing hardware solutions system com-panies are selecting hardware platforms that can be customizedby reconfiguration andor by software programmability Inparticular software is taking the lionrsquos share of the implemen-tation budgets and cost In cell phones more than 1 millionlines of code is standard today while in automobiles theestimated number of lines by 2010 is in the order of hundredsof millions and in the Boeing 787 is in the order of 20 millionlines However as this happens the complexity explosion ofthe software component causes serious concerns for the finalquality of the products and the productivity of the engineeringteams
The Integration Complexity A standard technique to dealwith complexity consists in decomposing top-down the systeminto subsystems This approach which has been customar-ily adopted by the semiconductor industry for years has alimitation as a designer or a group of designers has to fullycomprehend the entire system and to partition appropriately itsvarious parts a difficult task given the enormous complexityof todayrsquos systems
Hence the future is one of developing systems by compos-ing pieces that all or in part have already been predesignedor designed independently by other design groups or evencompanies This has been done routinely in vertical designchains for example in the avionics and automotive sectorsalbeit in a heuristic and ad hoc way The resulting lack of anoverall understanding of the interplay of the subsystems and ofthe difficulties encountered in integrating very complex partscause system integration to become a nightmare in the systemindustry as demonstrated by Table II1
In addition heterogeneity comes into play Integration of
1VDC research Track 3 Embedded Systems Market Statistics Exhibit II-13from volumes on automotiveindustrial automationmedical 2008
electronic and mechanical design tools and frameworks will beessential in the near future Integration of chemical electronicand biology tools will be essential in the further future fornano-systems Data integration and information flow amongthe companies forming the chain have to be supported Inother words it is essential that the fundamental steps of systemdesign (functional partitioning allocation on computationalresources integration and verification) be supported acrossthe entire design development cycle and across different dis-ciplines
B Complexity of OEM-Supplier Chains
The source of the above problems is clearly the increase incomplexity It is however also the difficulty of the OEMs inmanaging the integration and maintenance process with sub-systems that come from different suppliers who use differentdesign methods different software architectures and differenthardware platforms
There are also multiple challenges in defining technicalannexes to commercial contracts between OEM and suppli-ers Specifications used for procurement should be preciseunambiguous and complete However a recurrent reason forfailures causing deep iterations across supply chain boundariesrests in incomplete characterizations of the environment ofthe system to be developed by the supplier such as missinginformation about failure modes and failure rates missing in-formation on possible sources for interferences through sharedresources and missing boundary conditions This highlightsthe need to explicate assumptions on the design context inOEM-supplier commercial contracts In light of an increasedsharing of hardware resources by applications developed bymultiple suppliers a contract-based approach seems indispens-able for resolving liability issues and allowing applicationswith different criticality levels to co-exist (such as ASILlevels[175] [13] in automotive)
C Managing Requirements
We argued that the design chains should connect seamlesslyto minimize design errors and time-to-market delays Yet theboundaries among companies and between different divisionsof the same company are often not as clean as needed anddesign specs move from one company (or one division) to the
RR ndeg 8147
Contracts for System Design 10
next in non-executable and often unstable and imprecise formsthus yielding misinterpretations and consequent design errorsIn addition errors are often caught only at the final integrationstep as the specifications were incomplete and imprecisefurther nonfunctional specifications (eg timing power con-sumption size) are difficult to trace Further it is commonpractice to structure system level requirements into severalldquochaptersrdquo ldquoaspectsrdquo or ldquoviewpointsrdquo Examples include thefunctions safety timing and energy viewpoints Quite oftenthese different viewpoints are developed by different teamsusing different skills frameworks and tools Yet they are notunrelated as we already mentioned Without a clean approachto handle multiple viewpoints the only sensible way is tocollect these viewpoints into a single requirements documentwhich is then seen as a flat collection of requirements forsubsequent design Since this is clearly impracticable thecommon practice instead is to discard some of the viewpointsin a first stage eg by considering only functions and safetyDesigns are then developed based on these only viewpointsOther viewpoints are subsequently taken into account (timingenergy) thus resulting in late and costly modifications andre-designs
Requirement engineering is a discipline that aims at improv-ing this situation by paying close attention to the managementof the requirement descriptions and traceability support (egusing commercial tools such as DOORS2 in combinationwith Reqtify3) and by inserting whenever possible preciseformulation and analysis methods and tools Research in thisarea is active but we believe more needs to be done to makethis essential step a first class citizen in system design Indeedif the specification quality is low then the entire design processis marred since the very beginning The overall system productspecification is somewhat of an art today since to verify itscompleteness and its correctness there is little that it can beused to compare with
D Managing Risks
System design processes are highly concurrent distributedand typically multi-domain often involving more than onehundred sub-processes The complexity of the entire designprocess and of the relationships between players in the supplychain creates the need to elaborate risk sharing and riskmanagement plans because of the potential enormity of theimpact that design errors and supplier solidity may have onthe economics of a company Risk management has thusbecome a requirement of most of public companies as fi-nancial social and political risks are analyzed and appropriatecountermeasures have to be prepared as a requirement fromthe regulatory bodies Risk mitigation measures typically coverall phases of design processes ranging from assuring highquality initial requirements to early assessments of risks inmeeting product requirements during the concept phase toenforcing complete traceability of such requirements with
2 httpwww-01ibmcomsoftwareawdtoolsdoorsproductline3httpetc
requirements management tools to managing consistency andsynchronization across concurrent sub-processes using PLMtools4 If we will be able to change the design processalong the lines of more formal approaches better complexityhandling better requirement engineering then risks will besubstantially lower than they are today
E System-wide Optimization
We believe that since the design process is fragmentedproduct optimization is rarely carried out across more thanone company boundary and even then it is limited due tobull The lack of appropriate models encompassing both func-
tional and non-functional (Quality of Service) aspectscovering both internal use and export outside the com-pany
bull The time pressure to meet the product deadlinesbull The functional description that is over-constrained by
architectural considerations which de facto eliminate po-tentially interesting implementation alternatives
If the design process were carried out as in a unique well-integrated virtual company including all the players shownabove the overall ecosystem would greatly benefit The issuehere is to allow a reasonably efficient design space explorationby providing a framework where different architectures couldbe quickly assembled and evaluated at each layer of abstractioncorresponding to the design task being considered in the chain
III HOW CHALLENGES HAVE BEEN ADDRESSED SO FAR
In this section we present a review and a critical analysisof the design methodologies that have been deployed to copewith the challenges exposed in the previous section
A Complexity of Systems and System-wide Optimization
Multiple lines of attack have been developed by researchinstitutions and industry to cope with the exponential growth insystems complexity starting from the iterative and incrementaldevelopment several decades ago [123] Among them ofparticular interest to the development of embedded controllersare Layered design Component-based design the V-modelprocess model-based development virtual integration andPlatform-Based Design (PBD) There are two basic princi-ples followed by these methods abstractionrefinement andcompositiondecomposition Abstraction and refinement areprocesses that relate to the flow of design between differentlayers of abstraction (vertical process) while compositionand decomposition operate at the same level of abstraction(horizontal process) Layered design the V-model processand model-based development focus on the vertical processwhile component-based design deals principally with the hor-izontal process PBD combines the two aspects in a unifiedframework and hence subsumes and can be used to integrated
4 PLM Product Lifecycle Management PLM centric design is used incombination with virtual modeling and digital mockups PLM acts as a database of virtual system components PLM centric design is for exampledeployed at Dassault-Aviation httpwwwdassault-aviationcomenaviationinnovationthe-digital-companydigital-designplm-toolshtmlL=1
RR ndeg 8147
Contracts for System Design 11
the other methodologies Contracts are ideal tools to solidifyboth vertical and horizontal processes providing the theoreticalbackground to support formal methods
1) Layered design Layered design copes with complexityby focusing on those aspects of the system pertinent to supportthe design activities at the corresponding level of abstractionThis approach is particularly powerful if the details of alower layer of abstraction are encapsulated when the designis carried out at the higher layer Layered approaches are wellunderstood and standard in many application domains Asan example consider the AUTOSAR standard5 This standarddefines several abstraction layers Moving from ldquobottomrdquoto ldquotoprdquo the micro-controller abstraction layer encapsulatescompletely the specifics of underlying micro-controllers thesecond layer abstracts from the concrete configuration of theElectronic Control Unit (ECU) the employed communicationservices and the underlying operating system whereas the(highest) application layer is not aware of any aspect ofpossible target architectures and relies on purely virtual com-munication concepts in specifying communication betweenapplication components Similar abstraction levels are definedby the ARINC standard in the avionic domains
The benefits of using layered design are manifold Using theAUTOSAR layer structure as example the complete separationof the logical architecture of an application (as represented bya set of components interconnected using the so-called virtualfunction bus) and target hardware is a key aspect of AUTOSARin that it supports decoupling of the number of automotivefunctions from the number of hardware components In par-ticular it is flexible enough to mix components from differentapplications on one and the same ECU This illustrates thedouble role of abstraction layers in allowing designers to focuscompletely on the logic of the application and abstracting fromthe underlying hardware while at the same time imposing aminimal (or even no) constraint on the design space of possiblehardware architectures In particular these abstractions allowthe application design to be re-used across multiple platformsvarying in number of bus-systems andor number and class ofECUs These design layers can in addition be used to matchthe boundaries of either organizational units within a companyor to define interfaces between different organizations in thesupply chain The challenge then rests in providing the properabstractions of lower-level design entities
2) Component-based design Whereas layered designs de-compose complexity of systems ldquoverticallyrdquo component-basedapproaches reduce complexity ldquohorizontallyrdquo whereby designsare obtained by assembling strongly encapsulated design enti-ties called ldquocomponentsrdquo equipped with concise and rigorousinterface specifications Re-use can be maximized by findingthe weakest assumptions on the environment sufficient to es-tablish the guarantees on a given component implementationWhile these interface specifications are key and relevant forany system the ldquoquality attributerdquo of perceiving a subsystemas a component is typically related to two orthogonal criteria
5See httpwwwautosarorg
that of ldquosmall interfacesrdquo and that of minimally constrainingthe deployment context so as to maximize the potential for re-use ldquoSmall interfacesrdquo ie interfaces which are both smallin terms of number of interface variables or ports as wellas ldquologically smallrdquo in that protocols governing the invoca-tion of component services have compact specifications notrequiring deep levels of synchronization constitute evidenceof the success of encapsulationmdashstill small interfaces mustencompass dynamic properties of the system The secondquality attribute is naturally expressible in terms of interfacespecifications where re-use can be maximized by finding theweakest assumptions on the environment sufficient to establishthe guarantees on a given component implementation
One challenge then for component-based design of em-bedded systems is to provide interface specifications that arerich enough to cover all phases of the design cycle Thiscalls for including non-functional characteristics as part ofthe component interface specifications which is best achievedby using multiple viewpoints Current component interfacemodels in contrast are typically restricted to purely functionalcharacterization of components and thus cannot capitalize onthe benefits of virtual integration testing as outlined above
The second challenge is related to product line designwhich allows for the joint design of a family of variants of aproduct The aim is to balance the contradicting goals of striv-ing for generality versus achieving efficient component im-plementations Methods for systematically deriving ldquoquotientrdquospecifications to compensate for ldquominorrdquo differences betweenrequired and offered component guarantees by composing acomponent with a wrapper component (compensating for suchdifferences as characterized by quotient specifications) existsfor restricted classes of component models [155]
3) The V-model process A widely accepted approach todeal with complexity of systems in the defense and trans-portation domain is to structure product development processesalong variations of the V diagram originally developed fordefense applications by the German DoD6
Its characteristic V-shape splits the product developmentprocess into a design and an integration phase Specificallyfollowing product level requirement analysis subsequent stepswould first evolve a functional architecture supporting productlevel requirements Sub-functions are then re-grouped takinginto account re-use and product line requirements into alogical architecture whose modules are typically developed bydifferent subsystem suppliers The realization of such modulesoften involves mechanical hydraulic electrical and electronicsystem design Subsequent phases would then unfold thedetailed design for each of these domains such as the designof the electronic subsystem involving among others the designof electronic control units These design phases are paralleledby integration phases along the right-hand part of the Vsuch as integrating basic- and application software on theECU hardware to actually construct the electronic control unitintegrating the complete electronic subsystems integrating the
6See eg httpwwwv-model-xtde
RR ndeg 8147
Contracts for System Design 12
mechatronic subsystem to build the module and integratingmultiple modules to build the complete product Not shownbut forming an integral part of V-based development processesare testing activities where at each integration level test-suites developed during the design phases are used to verifycompliance of the integrated entity to their specification
This presentation is overly simplistic in many ways Thedesign of electronic components in complex systems suchas aircrafts inherently involves multi-site multi-domain andcross-organizational design teams reflecting eg a partition-ing of the aircraft into different subsystems (such as primaryand secondary flight systems cabin fuel and wing) differentdomains such as the interface of the electronic subsystem tohydraulic andor mechanical subsystems control-law designtelecommunications software design hardware design diag-nostics and development-depth separated design activities car-ried out at the OEM and supplier companies This partitioningof the design space (along perspectives and abstraction layers)naturally lends itself to a parallelization of design activitiesa must in order to achieve timely delivery of the overallproduct leading often into the order of hundreds of concurrentdesign processes To summarize while being popular andwidely referenced the V-model process has become a ldquosloganrdquohiding the complexity of actual design processes In realitylarge system companies develop their own processes and thenstruggle for their application both in-house and across thesupplier chain
4) Model-Based Design Model-based design (MBD) is to-day generally accepted as a key enabler to cope with complexsystem design due to its capabilities to support early require-ment validation and virtual system integration MBD-inspireddesign languages and tools such as SysML7 [149] andorAADL [152] for system level modeling Catia and Model-ica [93] for physical system modeling Matlab-Simulink [118]for control-law design and UML8 [44] [147] Scade [32]and TargetLink for detailed software design depend on de-sign layer and application class The state-of-the-art in MBDincludes automatic code-generation simulation coupled withrequirement monitoring co-simulation of heterogeneous mod-els such as UML and Matlab-Simulink model-based analy-sis including verification of compliance of requirements andspecification models model-based test-generation rapid pro-totyping and virtual integration testing as further elaboratedbelow
In MBD today non-functional aspects such as performancetiming power or safety analysis are typically addressed indedicated specialized tools using tool-specific models withthe entailed risk of incoherency between the correspond-ing models which generally interact To counteract theserisks meta-models encompassing multiple views of designentities enabling co-modeling and co-analysis of typicallyheterogeneous viewpoint specific models have been developedExamples include the MARTE UML [148] profile for real-time
7httpwwwomgorgspecSysML8httpwwwomgorgspecUML
system analysis the SPEEDS HRC metamodel [156] and theMetropolis semantic meta-model [19] [67] [16] [170] InMetropolis multiple views are accommodated via the conceptof ldquoquantitiesrdquo that annotate the functional view of a designand can be composed along with subsystems using a suitablealgebra The SPEEDS meta-model building on and extendingSysML has been demonstrated to support co-simulation andco-analysis of system models for transportation applicationsallowing co-assessment of functional real-time and safety re-quirements It forms an integral part of the meta-model-basedinter-operability concepts of the CESAR reference technologyplatform9
Meta-modeling is also at the center of the model driven(software) development (MDD) methodology MDD is basedon the concept of the model-driven architecture (MDA) whichconsists of a Platform-Independent Model (PIM) of the ap-plication plus one or more Platform-Specific Models (PSMs)and sets of interface definitions MDA tools then supportthe mapping of the PIM to the PSMs as new technologiesbecome available or implementation decisions change [146]The Vanderbilt University group [119] has evolved an em-bedded software design methodology and a set of tools basedon MDD In their approach models explicitly represent theembedded software and the environment it operates in andcapture the requirements and the design of the applicationsimultaneously using domain-specific languages (DSL) Thegeneric modeling environment (GME) [119] provides a frame-work for model transformations enabling easy exchange ofmodels between tools and offers sophisticated ways to sup-port syntactic (but not semantic) heterogeneity The KerMetametamodeling workbench [91] is similar in scope
5) Virtual Integration Rather than ldquophysicallyrdquo integratinga system from subsystems at integration stages model-baseddesign allows systems to be virtually integrated based on themodels of their subsystem and the architecture specificationof the system Such virtual integration thus allows detectingpotential integration problems up front in the early designphases Virtual system integration is often a source of het-erogeneous system models such as when realizing an aircraftfunction through the combination of mechanical hydraulicand electronic systems Heterogeneous composition of modelswith different semantics was originally addressed in Ptolemy[88] Metropolis [20] [67] [16] [48] and in the SPEEDSmeta-model of heterogeneous rich components [65] [29] [31]albeit with different approaches Virtual integration involvesmodels of the functions the computer architecture with itsextra-functional characteristics (timing and other resources)and the physical system for control Some existing frameworksoffer significant support for virtual integration Ptolemy IIMetropolis and RT-Builder Developments around Catia andModelica as well as the new offer SimScape by Simulinkprovide support for virtual integration of the physical part atan advanced level
9wwwcesarprojecteu
RR ndeg 8147
Contracts for System Design 13
6) Platform Based Design Platform-based design was in-troduced in the late 1980s to capture a design process thatcould encompass horizontal (component-based design virtualintegration) and vertical (layered and model-based design)decompositions and multiple viewpoints and in doing sosupport the supply chain as well as multi-layer optimization
The idea was to introduce a general approach that couldbe shared across industrial domain boundaries that wouldsubsume the various definition and design concepts and thatwould extend it to provide a framework to reason aboutdesign Indeed the concepts have been applied to a variety ofvery different domains from automotive to System-on-Chipfrom analog circuit design to building automation to syntheticbiology
The basic tenets of platform-based design are as followsThe design progresses in precisely defined abstraction layersat each abstraction layer functionality (what the system issupposed to do) is strictly separated from architecture (howthe functionality could be implemented) This aspect is clearlyrelated to layered design and hence it subsumes it
Each abstraction layer is defined by a design platform Adesign platform consists ofbull A set of library components This library not only con-
tains computational blocks that carry out the appropriatecomputation but also communication components that areused to interconnect the computational components
bull Models of the components that represent a characteri-zation in terms of performance and other non-functionalparameters together with the functionality it can supportNot all elements in the library are pre-existing com-ponents Some may be ldquoplace holdersrdquo to indicate theflexibility of ldquocustomizingrdquo a part of the design that isoffered to the designer In this case the models representestimates of what can be done since the components arenot available and will have to be designed At times thecharacterization is indeed a constraint for the implementa-tion of the component and it is obtained top-down duringthe refinement process typical of layered designs Thislayering of abstractions based on mathematical models istypical of model-based methods and the introduction ofnon-functional aspects of the design relates to viewpoints
bull The rules that determine how the components can beassembled and how the the functional and non-functionalcharacteristics can be computed given the ones of thecomponents to form an architectureThen a platformrepresents a family of designs that satisfies a set ofplatform-specific constraints [15] This aspect is relatedto component-based design enriched with multiple view-points
This concept of platform encapsulates the notion of re-use asa family of solutions that share a set of common features (theelements of the platform) Since we associate the notion ofplatform to a set of potential solutions to a design problem weneed to capture the process of mapping a functionality (whatthe system is supposed to do) with the platform elements thatwill be used to build a platform instance or an ldquoarchitecturerdquo
(how the system does what it is supposed to do) The strictseparation between function and architecture as well as themapping process have been highly leveraged in AUTOSARThis process is the essential step for refinement and provides amechanism to proceed towards implementation in a structuredway Designs on each platform are represented by platform-specific design models A design is obtained by a designerrsquoscreating platform instances (architectures) via composing plat-form components (process that is typical of component-baseddesign) by mapping the functionality onto the components ofthe architecture and by propagating the mapped design in thedesign flow onto subsequent abstraction layers that are dealtwith in the same way thus presenting the design process asan iterative refinement This last point dictates how to moveacross abstraction layers it is an important part of design spaceexploration and offers a way of performing optimization acrosslayers In this respect PBD supports multiple viewpoints in ageneral way
B Complexity of OEM-Supplier Chains Standardization andHarmonization
So far the main answer to the complexity of OEM-supplierchains has been standardization Standardization concerns boththe design entities and the design processes particularlythrough the mechanism of certification
1) Standardization of design entities By agreeing on (do-main specific) standard representations of design entitiesdifferent industrial domains have created their own linguafranca thus enabling a domain wide shared use of designentities based on their standardized representation Exam-ples of these standards in the automotive sector include therecently approved requirement interchange format standardRIF10 the AUTOSAR11 de-facto standard the OSEK12 operat-ing system standard standardized bus-systems such as CAN13
and Flexray14 standards for ldquocar2Xrdquo communication andstandardized representations of test supported by ASAM15Examples in the aerospace domain include ARINC stan-dards16 such as the avionics applications standard interfaceIMA RTCA17 communication standards In the automationdomain standards for interconnection of automation devicessuch as Profibus18 are complemented by standardized designlanguages for application development such as Structured Text
As standardization moves from hardware to operating sys-tem to applications and thus crosses multiple design layersthe challenge increases to incorporate all facets of designentities required to optimize the overall product while atthe same time enabling distributed development in complex
10httpwwww3org2005ruleswikiRIF_Working_Group11httpwwwautosarorg12httpwwwosek-vdxorg13httpwwwisoorgisosearchhtmqt=Controller+Area+
NetworkampsearchSubmit=Searchampsort=relamptype=simpleamppublished=true14httpwwwflexraycom15httpwwwasamnet16httpwwwaeec-amc-fsemccomstandardsindexhtml17httpwwwrtcaorg18httpwwwprofibuscom
RR ndeg 8147
Contracts for System Design 14
supply chains As an example to address the different view-points required to optimize the overall product AUTOSARextended in transitioning from release 31 to 4 its capabilityto capture timing characteristics of design entities a keyprerequisite for assessing alternate deployments with respectto their impact on timing More generally the need for overallsystem optimization calls for the standardization of all non-functional viewpoints of design entities an objective yet tobe achieved in its full generality in order to allow crosslayer optimization Within the EDA domain such richnessof design interface specifications is industrial practice Withinthe systems domain the rich component model introduced inthe Integrated Projects SPEEDS tackles this key objective incovering multiple design layers (from product requirements todeployment on target architectures) and in providing means ofassociating multiple viewpoints with each design entity it isexpressive enough to allow for cross-supply chain optimizationof product developments This approach is further elaboratedand driven towards standardization in the Artemis flagshipproject CESAR
2) Harmonization of processes and certification Harmo-nizing or even standardizing key processes (such as devel-opment processes and safety processes) provides for a fur-ther level of optimization in interactions across the supplychain As an example Airbus Directives and Procedures(ADBs) provide requirements for design processes of equip-ment manufactures Often harmonized processes across thesupply chain build on agreed maturity gates with incrementalacceptance testing to monitor progress of supplier developmenttowards final acceptance often building on incremental proto-types Shared use of Product Lifcycle Management (PLM)19
databases across the supply chain offers further potentialsfor cross-supply chain optimization of development processesAlso in domains developing safety related systems domainspecific standards clearly define the responsibilities and dutiesof companies across the supply chain to demonstrate func-tional safety such as in the ISO 2626220 for the automotivedomain IEC 6150821 for automation its derivatives CenelecEN 50128 and 5012622 for rail and Do 178 B23 for civilavionics
Yet the challenge in defining standards rests in balancingthe need for stability with the need of not blocking processinnovations As an example means for compositional con-struction of safety cases are seen as mandatory to reducecertification costs in the aerospace and rail domains Similarlythe potential of using formal verification techniques to copewith increasing system complexity is considered in the movefrom DO 178 B to DO 178 C standards
19See [162] and also footnote 420httpwwwisoorgisocatalogue_detailhtmcsnumber=4346421httpwwwiecchfunctionalsafety22httpwwwceneleceuCenelecCENELEC+in+actionWeb+Store
Standardsdefaulthtm23httpwwwdo178sitecom
C Managing Requirements Traceability and Multiple View-points
Depending on application domains up to 50 of all er-rors result from imprecise incomplete or inconsistent andthus unfeasible requirements Requirements are inherently illstructured They must address all aspects of the system andthus cannot be constrained by the lingua franca of a partic-ular domain They are fragmented in the form of large andsometimes huge DOORS files24 structured into viewpointsTwo issues have thus been identified by systems industries asessential for requirement management powerful and flexibletraceability tools to relate requirements between them and tolink them to tests for validation purposes and the developmentof domain specific ontologies as part of the PLM suiteFurther based on an assessment by the system companiesprocesses in the CESAR project25 and the German EmbeddedSystems Innovation alliance26 and building on the finding ofthe Integrated Project SPEEDS27 multiple viewpoints havebeen categorized into perspectives and aspects to provide asolid requirement and property modeling scaffold Perspectivesare viewpoints relevant to architecture modeling as carriedout by different stake-holders during the development processAspects are viewpoints that are orthogonal to the systemstructure Aspects are used to demonstrate compliance of thearchitecture to end-user concerns Example of aspects aresafety cost maintainability performance and weight Themeta-model underlying the CESAR RTP is able to maintainlinks such as the satisfy derive verify refine and allocaterelationships between design artifacts of different perspectivesand across abstraction layers
In addition to cope with the inherently unstructured prob-lem of (in)completeness of requirements industry has setup domain- and application-class specific methodologies Asparticular examples we mention learning process such asemployed by Airbus to incorporate the knowledge base ofexternal hazards from flight incidents the Code of Practiceproposed by the Prevent Project28 using guiding questions toassess the completeness of requirements in the concept phaseof the development of advanced driver assistance systemsUse-case analysis methods as advocated for UML baseddevelopment process follow the same objective All togetherrequirement engineering misses the support of formal ap-proaches for its structuring and analysis
D Cross-company Shared Risk Management
The realization of complex systems calls for design pro-cesses that mitigate risks in highly concurrent distributedand typically multi-domain engineering processes often in-volving more than one hundred sub-processes Risk mitigation
24Typical sub-systems in aeronautics would have a few thousands top-levelrequirements An aircraft can have up to several hundred thousands of them
25wwwcesarprojecteu26httpspes2020informatiktu-muenchende27httpwwwspeedseucom28Albert http
RR ndeg 8147
Contracts for System Design 15
measures typically cover all phases of design processes rang-ing from ensuring high quality initial requirements to earlyassessments of risks in realizability of product requirementsduring the concept phase to enforcing complete traceabilityof such requirements with requirements management tools tomanaging consistency and synchronization across concurrentsub-processes using PLM tools A key challenge rests inbalancing risk reduction versus development time and effortcompletely eliminating the risks stemming from concurrentengineering essentially requires a complete synchronizationalong a fine-grained milestone structure which would kill anydevelopment project due to the induced delays Another keychallenge is the ldquonot my faultrdquo syndrome in the OEM-supplierchain when errors call for costly re-design and the issue ofpenalties arises Properly assigning responsibilities to risks isstill out of reach today
E The Need for Contracts
The way system design challenges have been addressed sofar leaves huge opportunities for improvements by relying oncontract-based design In this section we briefly summarizefor each existing approach to address the design challengeshow contracts could improve the current situation
Contribution 1 Addressing Complexity of Systems andSystem-wide OptimizationWhile layered design (Section III-A1) and component baseddesign (Section III-A2) have been critical steps in breakingsystems complexity they do not by themselves provide theultimate answer When design is being performed at a consid-ered layer implicit assumptions regarding other layers (egcomputing resources) are typically invoked by the designerwithout having these explicated Hence actual properties ofthese other layers cannot be confronted against these hiddenassumptions Similarly when components or sub-systems areabstracted via their interfaces in component based design itis generally not true that such interfaces provide sufficientinformation for other components to be safely implementedbased on this sole interface Contract-based design providesthe due discipline concepts and techniques to cope with thesedifficulties
Model-based development (Section III-A4) has reached sig-nificant maturity by covering nearly all aspects of the system(physics functions computing resources) albeit not yet in afully integrated way To offer a real added value any newlyproposed technology should be rich enough for encompassingall these aspects as well Contract-based design offers in largepart this desirable feature
Virtual integration and virtual modeling (Section III-A5) isa step beyond basic model-based development by offering anintegrated view of all the above different aspects eg physics+ functions + performances Contract-based design supportsthe fusion of different systems aspects
Contract-based design is compliant with the V-model pro-cess (Section III-A3) just because it does not impose anyparticular design process Using contracts only imposes a
small set of rules that any process should accommodate seeSection IV-D for a discussion of this
Finally Platform-Based Design (PBD Section III-A6)which is being deployed in some large systems industries suchas United Technologies Corporation (UTC) is a systematicand comprehensive methodology that unifies the various de-sign methodologies that have been described in this sectionContracts offer theory and methodological support for boththe successive refinement aspect the composition aspect andthe mapping process of PBD allowing formal analysis andsynthesis processes
Contribution 2 Addressing the Complexity of OEM-Supplier ChainsThe problems raised by the complexity of OEM-SupplierChains (Section II-B) are indeed the core target of contract-based design By making the explication of implicit assump-tions mandatory contracts help assigning responsibilities toa precise stake holder for each design entity By supportingindependent development of the different sub-systems whileguaranteing smooth system integration they orthogonalize thedevelopment of complex systems Contracts are thus adequatecandidates for a technical counterpart of the legal bindingsbetween partners involved in the distributed and concurrentdevelopment of a system
Contribution 3 Managing RequirementsSo far the task of getting requirements right and managingthem well (Section III-C) has only got support for sortingthe complexity out (traceability services and ontologies whichis undoubtely necessary) However requirements can only betested on implementations and it is not clear whether properdistinctions are made when performing tests regarding thefollowing fusing the results of tests associated to differentchapters or viewpoints of a requirement document versusfusing the results of tests associated to different sub-systemstesting a requirement under the responsibility of the designerof the considered sub-system versus testing a requirementcorresponding to an assumption regarding the context of useof this sub-systemmdashsuch distinctions should be made as weshall see Also requirements are barely executable and cannotin general be simulated Requirements engineering is the otherprimary target of contract-based design the above issues areproperly handled by contracts and contracts offer improvedsupport for evidencing the satisfaction of certification con-straints
Contribution 4 Managing RisksRisk metrics and risk mitigation measures are the essentialtools in managing risks (Section III-D) By offering improvedsupport for sub-contracting and distributing design to differentteams contracts are likely to significantly reduce the ldquonot myfaultrdquo syndrome
Contribution 5 Addressing CertificationAs explained in Section III-B2 the design of critical sys-tems is subject to a number of certification standards Whilecertification steps are mostly concerned with the processesnot the designs themselves the recent move from DO 178Bto DO 178C for level A critical systems in aeronautics has
RR ndeg 8147
Contracts for System Design 16
shown for the first time the consideration of formal proofsor validations as valid evidences We believe that the samewill eventually hold for contracts In particular by providingadequate formal support for completeness consistency com-patibility and more for sets of requirements contracts wouldprovide a valuable contribution to certification
IV CONTRACTS WHAT WHY WHERE AND HOWAs we argued in the previous section there are two basic
principles followed by design methods so far developed ab-stractionrefinement and compositiondecomposition Abstrac-tion and refinement are processes that relate to the flow of de-sign between different layers of abstraction (vertical process)while composition and decomposition operate at the same levelof abstraction (horizontal process) In this section we presentbriefly contracts and the basic operations they support andthen me make the point that contracts are ideal tools to solidifyboth vertical and horizontal processes providing the theoreticalbackground to support formal methods We conclude thesection by providing a (non exhaustive) bibliography on thegeneral concept of contract
A Contracts
Here we propose a ldquoprimerrdquo on contracts using a simpleexample as the reference for their use
1) Components and their Environment Contracts We startfrom a model that consists of a universal set M of com-ponents each denoted by the symbol M A component Mis typically an open system ie it contains some inputsthat are provided by other components in the system or theexternal world and it generates some outputs This collectionof other components and the exterior world is referred to as theenvironment of the component The environment is often notcompletely known when the component is being developedAlthough components cannot constrain their environment theyare designed to be used in a particular context
In the following example we define a component M1 thatcomputes the division between two real inputs x and y andreturns the result through the real output z The underlyingassumption is that M1 will be used within a design contextthat prevents the environment from giving the input y = 0Since M1 cannot constrain its input variables we handle theexceptional input y = 0 by generating an arbitrary output
M1
variables
inputs x y
outputs z
types x y z isin Rbehaviors (y 6= 0rarr z = xy) and (y = 0rarr z = 0)
A contract contract denoted by the symbol C is a de-scription of a component with the following characteristicproperties
1) Contracts are intentionally abstract2) Contracts distinguish responsibilities of a component
from that of its environmentProperty 1) of a contract highlights the goal of handlingcomplexity of the systems Thus contracts expose enough
information about the component but not more than necessaryfor the intended purpose We can see a contract as an under-specified description of a component that can be either veryclose to the actual component or specify only a singleproperty of a componentrsquos behavior Regarding Property 2)and in contrast to components a contract explicitly makes adistinction between assumptions made about the environmentand guarantees provided mirroring different roles and respon-sibilities in the design of systems
A contract can be implemented by a number of differentcomponents and can operate in a number of different envi-ronments Hence we define a contract C at its most abstractlevel as a pair C = (EC MC ) of subsets of components thatimplement the contract and of subsets of environments inwhich the contract can operate We say that a contract C isconsistent if MC 6= empty and compatible if EC 6= empty
This definition of contracts and the implementation relationis very general and as such it is not effective In concretecontract- based design theories a contract needs to have afinite description that does not directly refer to the actualcomponents and the implementation relation needs to beeffectively computable and establish the desired link betweena contract and the underlying components that implement it
For our present simple example of static systems wepropose the following way to specify contracts
C1
variables
inputs x y
outputs z
types x y z isin Rassumptions y 6= 0
guarantees z = xy
C1 defines the set of components having as variablesinputs x y output z of type real and whose behaviorssatisfy the implication
ldquoassumptionsrArr guaranteesrdquo
ie for the above example y 6= 0rArr z = xy Intuitivelycontract C1 specifies the intended behavior of components thatimplement division It explicitly makes the assumption that theenvironment will never provide the input y = 0 and leaves thebehavior for that input undefined
This contract describes an infinite number of environmentsin which it can operate namely the set EC1
of environmentsproviding values for x and y with the condition that y 6=0 Itdescribes an infinite number of components that implementthe above specification where the infinity comes from theunderspecified case on how an implementation of C1 shouldcope with the illegal input y = 0 In particular we have thatM1 implements C1 Thus contract C1 is consistent We nowshow a variant of contract C1 that is not consistent
Cprime1
variables
inputs x y
outputs z
types x y z isin Rassumptions T
guarantees z = xyRR ndeg 8147
Contracts for System Design 17
where symbol T denotes the boolean constant ldquotruerdquo Incontrast to C1 the contract Cprime1 makes no assumption on valuesof the input y Hence every component that implements Cprime1has to compute the quotient xy for all values of y includingy = 0 which makes no sense
B Contract Operators
There are three basic contract operators that are used insupport of the design methodologies we presented previouslycomposition refinement and conjunction
1) Contract Composition and System Integration Intu-itively the composition operator supports component-baseddesign and in general horizontal processes The compositionoperator that we denote by the symbol times is a partial functionon components The composition is defined with respect to acomposability criterion where two components M and M prime
are composable if their variable types match Composabilityis a syntactic property on pairs of components that definesconditions under which the two components can interactComposition times must be both associative and commutative inorder to guarantee that different composable components maybe assembled together in any order
Consider the component M2 defined as follows
M2
variables
inputs x
outputs y
types x y isin Rbehaviors y = ex
The component M2 computes the value of the output variabley as the exponential function of the input variable x M1 andM2 are they are composable since both common variables xand y have the same type x is an input variable to both M1
and M2 and the output variable y of M2 is fed as an input toM1 It follows that their composition M1 timesM2 has a singleinput variable x and computes the output z as a function ofx that is z = xex
Now consider component M prime2 that consists of an inputvariable x and an output variable z both of type real wherez = abs(x)
M prime2
variables
inputs x
outputs z
types x z isin Rbehaviors z = abs(x)
The component M prime2 is not composable with M1 becausethe two components share the same output variable z Theircomposition is illegal as it would result in conflicting rulesfor updating z
We now lift the above concepts to contracts The compo-sition operator between two contracts denoted by otimes shallbe a partial function on contracts involving a more subtlecompatibility criterion Two contracts C and Cprime are compatibleif their variable types match and if there exists an environmentin which the two contracts properly interact The resultingcomposition C otimes Cprime should specify through its assumptions
this set of environments By doing so the resulting contractwill expose how it should be used Unlike component com-posability contract compatibility is a combined syntactic andsemantic property
Let us formalize this For C a contract let AC and GC beits assumptions and guarantees and define
GC1otimesC2 = GC1andGC2
AC1otimesC2 = max
A∣∣∣∣∣∣AandGC2rArrAC1andAandGC1rArrAC2
(1)
where ldquomaxrdquo refers to the order of predicates by implica-tion thus AC1otimesC2 is the weakest assumption such that thetwo referred implications hold Thus this overall assumptionwill ensure that when put in the context of a componentimplementing the second contract then the assumption ofthe first contract will be met and vice-versa Since the twoassumptions were ensuring consistency for each contract theoverall assumption will ensure that the resulting compositionis consistent This definition of the contract compositiontherefore meets our previously stated requirements The twocontracts C1 and C2 are called compatible if the assumptioncomputed as in (1) differs from F the ldquo falserdquo predicate
Consider contracts C2 and Cprime2 that we define as follows
C2
variables
inputs u
outputs x
types u x isin Rassumptions T
guarantees x gt u
Cprime2
variables
inputs v
outputs y
types v y isin Rassumptions T
guarantees y = minusv
C2 specifies components that for any input value u generatesome output x such that x gt u and Cprime2 specifies componentsthat generate the value of the output variable y as functiony = minusv of the input v Observe that both C2 and Cprime2 areconsistent A simple inspection shows that C1 and C2 can becomposed and their composition yields
C1 otimes C2
variables
inputs u y
outputs x z
types x y u z isin Rassumptions y 6= 0
guarantees x gt u and z = xy
C1 and Cprime2 can also be composed and their composition yields
C1 otimes Cprime2
variables
inputs v x
outputs y z
types v x y z isin Rassumptions v 6= 0
guarantees y = minusv and z = xyRR ndeg 8147
Contracts for System Design 18
Both compositions possess a non-empty assumption (observealso that they are both free of exception) reflecting that thetwo pairs (C1 C2) and (C1 Cprime2) are compatible
In our example we require that compositions C1otimes(C2otimesC3)and (C1 otimes C2) otimes C3 result in equivalent contracts as well ascompositions C1otimesC2 and C2otimesC1 thus providing support forincremental system integration
A quotient operation can be defined that is dual to thecomposition operation Given a system-wide contract C anda contract C1 that specifies pre-existing components and theirinteractions the quotient operation CC1 defines the part ofthe system-wide contract that still needs to be implementedIt formalizes the practice of ldquopatchingrdquo a design to make itbehave according to another contract
2) Contract Refinement and Independent DevelopmentIn all vertical design processes the notions of abstractionand refinement play a central role The concept of contractrefinement must ensure the following if contract Cprime refinescontract C then any implementation of Cprime should 1) implementC and 2) be able to operate in any environment for C Hencethe following definition for refinement pre-order betweencontracts we say that the contract Cprime refines the contract C ifECprime supe EC andMCprime subeMC Since is a pre-order refinementis a transitive relation For our current series of examples andusing previous notations Cprime C amounts to requiring that 1AC implies ACprime and 2 ACprimerArrGCprime implies ACrArrGC
In Figure 4 we start with the contract C1 that representsthe general system-wide requirements We decompose theserequirements into requirements of three subsystems resultingin three contracts C11 C12 and C13 with the property thatC11otimesC12otimesC13 C1 Now these three contracts can be handedto different design teams and refined further independentlyIn particular C12 is further decomposed into contracts C121
and C122 such that C121 otimes C122 C12 and similarly C13 isfurther decomposed into contracts C131 and C132 such thatC131 otimes C132 C13
For all contracts C1 C2 Cprime1 and Cprime2 if C1 is compatible withC2 and Cprime1 C1 and Cprime2 C2 then Cprime1 is compatible with Cprime2and Cprime1 otimes Cprime2 C1 otimes C2
We now give a concrete example where we start withvery abstract requirements for a component that implementsa function z = xex Consider contracts Cprimeprime1 and Cprimeprime2 that wedefine as follows
Cprimeprime1
variables
inputs y
outputs z
types y z isin Rassumptions y 6= 0
guarantees z isin R
Cprimeprime2
variables
inputs x
outputs y
types x y isin Rassumptions T
guarantees y gt 0
The contract Cprimeprime1 formalizes the most crude and abstractrequirements for a divider It requires that the denominatorvalue (input variable y) is not equal to 0 and only ensuresthat the output value of z is any real Note that the contractCprimeprime1 does not declare the nominator input variable x Thecontract Cprimeprime2 specifies components that have an input variablex and an output variable of type y The only requirement onthe behavior of Cprimeprime2 is that y is strictly greater than 0 Thecomposition Cprimeprime1 otimes Cprimeprime2 is well defined The contract C1 refinesCprimeprime1 since it allows more inputs (the nominator input variable x)and restricts the behavior of the output variable z by definingits behavior as the division xy It follows that C1 is alsocompatible with Cprimeprime2 and that C1 otimes Cprimeprime2 Cprimeprime1 otimes Cprimeprime2 Finally wehave that M1 and M2 are implementations of their respectivecontracts It follows that M1 timesM2 implements C1 otimes Cprimeprime2
3) Contract Conjunction and Viewpoint Fusion We nowintroduce the conjunction operator between contracts denotedby the symbol and Conjunction is complementary to composi-tion
1) In the early stages of design the system-level speci-fication consists of a requirements document that is aconjunction of requirements
2) Full specification of a component can be a conjunctionof multiple viewpoints each covering a specific (func-tional timing safety etc) aspect of the intended designand specified by an individual contract see Figure 4 foran illustration
3) Conjunction supports reuse of a component in differentparts of a design see Figure 5 for an illustration
We state the desired properties of the conjunction operatoras follows Let C1 and C2 be two contracts If C1 and C2 areshared refinable then C1 andC2 C1 and C1 andC2 C2 and forall contracts C if C C1 and C C2 then C C1 and C2
To illustrate the conjunction operator we consider a contractCT1 that specifies the timing behavior associated with C1 Forthis contract we introduce additional ports that allow us tospecify the arrival time of each signal
CT1
variables
inputs tx ty
outputs tz
types tx ty tz isin R+
assumptions Tguarantees tzlemax(tx ty) + 1
The contract CT1 is shared refinable with C1 Their conjunctionC1 and CT1 yields a contract that guarantees in addition to C1itself a latency with bound 1 (say in ms) for it Becausethere are no assumptions this timing contract specifies thesame latency bound also for handling the illegal input y = 0In fact the contract says more because it does not mentionthe input y it assumes any value of y is acceptable Asa result the conjunction inherits the weakest T assumptionof the timing contract and cancels the assumption of C1This however is clearly not the intent since the timingcontract is not concerned with the values of the signals andis a manifestation of the weakness of this simple contract
RR ndeg 8147
Contracts for System Design 19
framework in dealing with contracts with different alphabetsof ports and variables We will further explain this aspect andshow how to address this problem in Section VII For themoment we can temporarily fix the problem by introducing yin the interface of the contract and use it in the assumptionsas in the following contract CT2
CT2
variables
inputs y tx ty
outputs tz
types y isin R tx ty tz isin R+
assumptions y 6=0guarantees tzlemax(tx ty) + 1
Note that this timing contract does not specify any bound forhandling the illegal input y = 0 since the promise is notenforced outside the assumptions
So far this example was extremely simple In particularit was stateless Extension of this kind of AssumeGuaranteecontracts to stateful contracts will be indeed fully developedin the coming sections and particularly in Section VII
C Contracts in requirement engineering
In this section we introduce a motivating example that isrepresentative of early requirements capturemdashthe specificationof a parking garage Its full development requires technicalmaterial that we introduce later and we thus defer it toSection XI This example illustrates the following features ofcontract based requirements capture namelybull Top-level system specification is by writing a require-
ments document Different formalisms may be used fordifferent kinds of requirements Here we illustrate thisby blending textual requirements written in constrainedEnglish (possibly obtained using boilerplates) with smallsized automata
bull The document itself is structured into chapters describingvarious aspects of the system such as how gates shouldbehave how payment should proceed plus some overallrules
bull Some requirements are under the responsibility of thesystem under development they contribute to specifyingthe guarantees that the system offers Other requirementsare not under the responsibility of the system underdevelopment they contribute to defining the assumptionsregarding the context in which the system should operateas specified
bull Requirements are written in constrained English languageor by using automata
We now begin with the top-level requirements The systemunder specification is a parking garage subject to paymentby the user At its most abstract level the requirementsdocument comprises the different chapters gate payment andsupervisor see Table III The gate chapter will collect thegeneric requirements regarding entry and exit gates Thesegeneric requirements will then be specialized for entry andexit gates respectively
Focus on the ldquogaterdquo chapter It consists of the three require-ments shown on Table III Requirement Rg1 is best described
gateRg1ldquovehicles shall not pass when gate is closedrdquo see Fig 7Rg2 after vehicle_pass vehicle_pass is forbiddenRg3 after gate_open gate_open is forbidden and
after gate_close gate_close is forbiddenpaymentsupervisor
Table IIITHE TOP-LEVEL SPECIFICATION WITH CHAPTER gate EXPANDED
REQUIREMENTS WRITTEN IN italics ARE ASSUMPTIONS UNDER WHICHgate SHOULD OPERATE
0
gate_close
1gate_opengate_close
vehicle_passgate_open
Figure 1 Requirement Rg1 specified as an io-automaton Prefix ldquordquoindicates an input and prefix ldquordquo indicates an output
by means of an io-automaton shown in Figure 1mdashwe providean informal textual explanation for it between quotes Supposethat some requirement says ldquogate_open never occursrdquo Thisis translated by having no mention of gate_open in thecorresponding io-automaton To express this ldquonegativerdquo factwe must keep track of the fact that gate_open belongs tothe alphabet of actions of the io-automaton Thus when per-forming the translation the explicit list of inputs and outputsshould be explicitly given To avoid such additional notationalburden we have cheated by omitting this unless necessaryThe other two requirements are written using constrainednatural language which can be seen as a boilerplate styleof specification Prefix ldquordquo indicates an input and prefix ldquordquoindicates an output
The first two requirements are not under the responsibilityof the system since they rather concern the car driver Thus itdoes not make sense to include them as part of the guaranteesoffered by the system Should we remove them This wouldbe problematic If drivers behave the wrong way unexpectedthings can occur for sure The conclusion is that 1) we shouldkeep requirements Rg1 and Rg2 and 2) we should handlethem differently than Rg3 which is a guarantee offered by thesystem Indeed Rg1 and Rg2 are assumptions under whichthe gate operates as guaranteed We take the convention thatassumptions are written in italics
So far we have specified gate as a list of requirementsRequirement Rg1 specified as an io-automaton can be con-sidered formal Requirements Rg2 and Rg3 are formulatedin constrained natural language and are ready for subsequentformalization eg as io-automata Are we done Not yetWe need to give a formal meaning to what it means to havea collection of requirements and what it means to distinguishassumptions from guarantees Similarly we must give a formalmeaning to what it means to combine different chapters of arequirements document Intuitively all requirements must be
RR ndeg 8147
Contracts for System Design 20
met for a chapter to be satisfied and similarly all chaptersmust be satisfied for the whole specification to be correctlyimplemented Thus we propose to write the top-level specifi-cation C as the following conjunction
C = Cgate and Cpayment and Csupervisor
As we said formally defining what conjunction and is requirestechnical material that is developed later in this paper Thefollowing issues arise regarding this top-level specificationFirst of all since a conjunction operator is involved in theconstruction of C there is a risk of formulating contradictingrequirementsmdashthis is referred to as the issue of consistencySecond are we sure that the top-level specification C iscomplete ie precise enough to rule out undesirable imple-mentations One good way of checking for completeness is tobe able to execute or simulate this top-level specification CWe provide answers to all these issues in Section XI wherethis example is fully developed
request enter
ticket issue
entry gate open
entry gate closeEntryGate
vehicle enter
vehicle exit
exit ticket insert ExitGateexit gate open
exit gate close
ticket insert payment
coin insert paymentPaymentMachine exit ticket issue
Figure 2 System architecture as specified by the designer
Having the top-level specification C at hand the designerthen specifies an architecture ldquoagrave la SysMLrdquo as shown onFigure 2 Some comments are in order regarding this archi-tecture The considered instance of a parking garage consistsof one entry gate one exit gate and one payment machineCompare with the top-level specification of Table III Thelatter comprises a generic gate a payment machine and asupervisor each one with its set of requirements In contrastthe architecture of Figure 2 involves no supervisor Thesupervisor is meant to be distributed among the two gatesThe architecture of Figure 2 seems to be very loosely coupledFirst the PaymentMachine seems to be totally independent Infact the ticket that is inserted in the exit gate must coincidewith the one issued by the PaymentMachine It turns out thatthis reflects a missing assumption regarding the environmentof the system (namely the user of the parking) Then thetwo gates seem to have the shared input ldquovehicle exitrdquo astheir only interaction But this shared input is involved in
requirement Rs3 which forbids the entry if the parking isfull
The next step in the design consists in subcontractingthe development of each of the three sub-systems of thearchitecture of Figure 2 This amounts to specifying threesubcontracts CEntryGate CExitGate and CPaymentMachinesuch that
CEntryGate otimes CExitGate otimes CPaymentMachine C (2)
The symbol in (2) means that any implementation of theleft hand side is also a valid implementation of the top-level C Then the contract composition operator otimes ensuresthat each supplier can develop its sub-system based on itsown sub-contract only and still integrating the so designedsub-systems yields a correct implementation of the top-levelspecification Once the three sub-contracts are found checkingthat they satisfy (2) requires formalizing the contract compo-sition operator otimes Furthermore guessing such sub-contractsis a difficult task In our development of this example inSection XI we propose adequate answers to these issues
D Contract Support for Design Methodologies
The three operators introduced above fit naturally in anydesign methodology developed so far In particular contractcomposition and conjunction supports horizontal processesand contract refinement supports vertical processes We showhow this is so by first analyzing the use of contract conjunc-tion for requirement management then of composition andrefinement for design chain management re-use and indepen-dent development to close with conjunction composition andrefinement for deployment and mapping
1) Supporting open systems When designing componentsfor reuse their context of use is not fully known in advanceWe thus need a specification of components exposing boththe guarantees offered by the component and the assumptionson its possible context of usemdashits ldquoenvironmentrdquo This stateswhat contracts should be
2) Managing Requirements and Fusing Viewpoints Re-ferring to Section III-C complex systems involve a numberof viewpoints (or aspects) that are generally developed bydifferent teams using different skills As a result there is aneed for fusing these viewpoints in a mathematically soundway Structuring requirements or specifications is a desirableobjective at each step of the design Finally we must formal-ize some key properties that must be evidenced as part ofcertification processes
This process is illustrated in Figure 3 In this figure weshow three viewpoints the behavioral viewpoint where thefunctions are specified the timing viewpoint where timingbudgets are allocated to the different activities and the safetyviewpoint where fault propagation effect and handling arespecified Typically different viewpoints are developed bydifferent teams using different frameworks and tools Devel-opment of each viewpoint is performed under assumptionsregarding its context of use including the other viewpoints To
RR ndeg 8147
Contracts for System Design 21
VIEWPOINT VIEWPOINT VIEWPOINTBEHAVIORAL TIMING SAFETY
is a conjunctionevery contract
C =and
i Ci
CB1 CB2 CT CS1 CS2
CB1 and CB2 and CT and CS1 and CS2
Figure 3 Conjunction of requirements and viewpoints in top-level design
get the full system specification the different viewpoints mustbe fused As the notations of Figure 3 suggest conjunctionis used for fusing viewpoints thus reflecting that the systemunder design must satisfy all viewpoints Similarly eachviewpoint is itself a conjunction of requirements seen as theldquoatomicrdquo contractsmdashall requirements must be met
3) Design Chain Management Re-using and IndependentDevelopment In Figure 4 we show three successive stages ofthe design At the top level sits the overall system specificationas developed by the OEM As an example it can be obtained asthe conjunction of several viewpoints as illustrated on Figure 3
is delegated forimplementation by a supplier
is delegated forimplementation by a supplier
C11 otimes (C121 otimes C122)otimes (C131 otimes C132)
C11
C12
C13
C11
C121 C122 C131 C132
C121 otimes C122 C131 otimes C132
C11 otimes C12 otimes C13
C1
is refined by the OEM
Figure 4 Stepwise refinement
As a first design step the OEM decomposes its system intoan architecture made of three sub-systems for independentdevelopment by (possibly different) suppliers For each ofthese sub-systems a contract C1j j = 1 2 3 is developedA contract composition denoted by the symbol ldquootimesrdquo
C11 otimes C12 otimes C13
mirrors the composition of sub-systems that defines the archi-tecture For our method to support independent development
this contract composition operator must satisfy the following
if designs are independently performed for eachsub-contract C1j j = 1 2 3 then integratingthese sub-systems yields an implementation thatsatisfies the composed contract C11 otimes C12 otimes C13
(3)
This contract composition must then be qualified against thetop-level contract C1 This qualification must ensure that anydevelopment compliant with C11 otimes C12 otimes C13 should alsocomply with C1 To ensure substitutability in any legal contextcompliance concerns both how the system behaves and whatits allowed contexts of use are any legal context for C1 shouldbe also legal for C11otimesC12otimesC13 and under any legal contextthe integrated system should behave as specified by C1 This isformalized as the refinement relation denoted by the symbol
C11 otimes C12 otimes C13 C1 (4)
Overall the satisfaction of (4) guarantees the correctness ofthis first design step performed by the OEM
Obtaining the three sub-contracts C11 C12 and C13 is the artof the designer based on architectural considerations Contracttheories however offer the following services to the designerbull The formalization of parallel composition and refinement
for contracts allows the designer to firmly assess whether(4) holds for the decomposition step or not
bull In passing the compatibility of the three sub-contractsC11 C12 and C13 can be formally checked
bull Using contracts as a mean to communicate specificationsto suppliers guarantees that the information provided tothe supplier is self-contained the supplier has all theneeded information to develop its sub-system in a waythat subsequent system integration will be correct
Each supplier can then proceed with the independent devel-opment of the sub-system it is responsible for For instance asupplier may reproduce the above procedure
Alternatively this supplier can develop some sub-systemsby reusing off-the-shelf components For example contractC121 would be checked against the interface specification of apre-defined component M121 available from a library and thefollowing would have to be verified does component M121
satisfy C121 In this context shared implementations are ofinterest This is illustrated on Figure 5 where the same off-the-shelf component implements the two referred contracts
To conclude on this analysis the two notions of refinementdenoted by the symbol ldquordquo and composition of contractsdenoted by the symbol ldquootimesrdquo are key Condition (3) ensuresindependent development holds
4) Deployment and Mapping Here we address a specificbut important point related to Contribution 1 At some pointin the design of the system specifications must be realized byusing resources Resources can be pre-defined sub-systems orcomponents or they can consist of computing resources com-prising computing units and communication media (networksbusses and protocols) This methodology was advocated and
RR ndeg 8147
Contracts for System Design 22
C11
C121 C122 C131 C132
C11 otimes (C121 otimes C122)otimes (C131 otimes C132)
C121 otimes C122 C131 otimes C132
C122 and C132
Figure 5 Conjunction for component reuse
systematically exploited in Platform Based Design [171] orPLM-centric design see footnote 4 in Section II How sucha step can be captured in contract based design is explainednext
When deploying an application over a computing plat-form in addition to the functional viewpoint non-functionalviewpoints (safety timing energy and possibly other) areof importance as well The safety viewpoint is concernedwith the risk of primary faults and failures how they couldpropagate throughout the system and what the consequencesfor the resilience of the overall system would be in termsof failure probability The timing viewpoint collects timingrequirements regarding the application (requirements on la-tencies throughput jitter and schedulability) The effectivesatisfaction of safety or timing viewpoints by a considereddeployment depends on 1) the supporting execution platformand 2) the mapping of the application to this executionplatform We thus need to formalize what ldquomappingrdquo meansThe reader is referred to Figure 6 for the following discussion
M4M3
M5M6
M1
M2
M3
M1
M4
M2
M5
M6x34
xd63 xo
63
x34
C2 C1
C3
P
C
xo63
xd63
Figure 6 Mapping the application to the execution platform as C and P
Suppose one has a virtual model of the execution platform
as an architecture composed of several components Suchcomponents would in the context of Figure 6 consist of adescription of the available computing units a descriptionof the bus protocol and frame structure andor a library ofRTOS (Real-Time Operating System) services The resultingcomponents are enhanced with timing information (for thetiming viewpoint) and fault propagation information (for thesafety viewpoint) Application contracts are attached to thedifferent sub-systems or components as described on the toppart of the figure Similarly platform contracts are attachedto the different sub-systems or components of the executionplatform as described on the bottom part of the figureAccordingly we assume
C =andk
(otimesiisinIk Cik
)P =
otimesjisinJ
(and`isinLj
Pj`)
where
bull The overall platform contract P decomposes asotimes
jisinJ Pj(eg the bus and the different computing units inFigure 6) where each Pj is the conjunction of its differentviewpoints (the function what can be computed and theassociated performance how much time it takes and howmuch energy it consumes)
bull The overall application contract is the conjunction ofits different viewpoints Ci with their own architecturaldecomposition
In Figure 6 we only show a single viewpoint29 and we assumethat distant communication between C2 and C3 has alreadybeen refined to a communication medium compliant with thecommunication resources offered by the execution platform
The mapping of the application over the architecture ismodeled by the conjunction CandP defined by the following setof synchronization tuples30 depicted in red in the Figure 6
bull The wire x34 linking M3 to M4 in the application issynchronized in the deployment P with the variablex34 of the left computing unit where x34 represents theoutput of the module implementing M3 and the input ofthe module implementing M4 And similarly for the wirelinking M5 to M6
bull In the deployment the wire x63 linking M6 to M3
must traverse the bus To capture this we first refinethe application architecture by distinguishing the originxo63 of this wire from its destination xd63 In the refinedapplication architecture we assume that xo63 and xd63 arerelated by some buffer of bounded size The deploymentis then captured by synchronizing xo63 with the output xo63
of the module implementing M6 in the right computingunit and by synchronizing xd63 with the input xd63 of themodule implementing M3 in the left computing unit
29Here we assume that the different application viewpoints are developedfor the whole application and then combined by conjunctionmdashthis is just amethodological proposal we could proceed differently
30In in a synchronization tuple both occurrences and values of the differentelements are unified
RR ndeg 8147
Contracts for System Design 23
This formalizes the deployment as the conjunction
C and P =[and
k
(otimesiisinIk Cik
) ]and [otimesjisinJ(and
`isinLjPj`) ]
ensuring that C and P refines C by construction There ishowever no free lunch The formula C and P expressing de-ployment involves a conjunction and is as such a possiblesource of inconsistencies If this happens then C and P cannotbe implemented Finding an execution platform P causingno inconsistency in C and P requires a good understanding ofthe application and its needs The more advanced techniquesdeveloped in Section XI provide assistance for this
Since C and P relates application and computing platformmdashwhich sit at different layers of the designmdashwe call suchcontracts vertical contracts Contracts that are not vertical aresometimes called horizontal in that they are meant to relatecomponents sitting at a same level of the design hierarchymdashapplication level or computing platform level or ECU (Elec-tronic Computing Unit) level
Techniques of mapping application to its execution platformthat are similar to the above one are used in the RT-Buildertool 31 and in the Metropolis platform [20] [80]
E Bibliographical note
Having collected the ldquorequirementsrdquo on contract theories itis now timely to confront these to the previous work referringto or related to the term ldquocontractrdquo
It is difficult to write a comprehensive bibliography onthe general aspects of contract based design The topic ismulti faceted and has been addressed by several communitiessoftware engineering language design system engineeringand formal methods in a broad sense We report here a partialand limited overview of how this paradigm has been tackledin these different communities While we do not claim beingexhaustive we hope that the reader will find her way to thedifferent literatures
Contracts in SW engineering This part of the biblio-graphical note was inspired by the report [168] Design byContract is a software engineering technique popularized byBertrand Meyer [139] [140] following earlier ideas fromFloyd-Hoare logic [169] [113] Floyd-Hoare logic assignsmeaning to sequential imperative programs in the form oftriples of assertions PCQ consisting of a preconditionon program states and inputs a command and a postcondi-tion on program states and outputs Meyerrsquos contracts weredeveloped for Object-Oriented programming They exposethe relationships between systems in terms of preconditionsand postconditions on operations and invariants on states Acontract on an operation asserts that given a state and inputswhich satisfy the precondition the operation will terminatein a state and will return a result that satisfy the postcondi-tion and respects any required invariant properties Contractscontribute to system substitutability Systems may be replacedby alternative systems or assemblies that offer the same or
31httpwwwgeensoftcomenarticlertbuilder
substitutable functionality with weaker or equivalent precon-ditions and strongerequivalent postconditions With the aimof addressing service oriented architectures Meyerrsquos contractswere proposed a multiple layering by Beugnard et al [37]The basic layer specifies operations their inputs outputs andpossible exceptions The behavior layer describes the abstractbehavior of operations in terms of their preconditions andpostconditions The third layer synchronisation correspondsto real-time scheduling of component interaction and messagepassing The fourth quality of service (QoS) level detailsnon-functional aspects of operations The contracts proposedby Beugnard et al are subscribed to prior to service invo-cation and may also be altered at runtime thus extendingthe use of contracts to Systems of Systems [141] So farcontracts consisting of prepostconditions naturally fit imper-ative sequential programming In situations where programsmay operate concurrently interference on shared variablescan occur RelyGuarantee rules [115] were thus added tointerface contracts Rely conditions state assumptions aboutany interference on shared variables during the execution ofoperations by the systemrsquos environment Guarantee conditionsstate obligations of the operation regarding shared variables
The concepts of interface and contract were subse-quently further developed in the Model Driven Engineering(MDE) [120] [172] [131] In this context interfaces aredescribed as part of the system architecture and comprisetyped ports parameters and attributes Contracts on interfacesare typically formulated in terms of constraints on the en-tities of components using the Object Constraint Language(OCL) [150] [180] Roughly speaking an OCL statementrefers to a context for the considered statement and expressesproperties to be satisfied by this context (eg if the context isa class a property might be an attribute) Arithmetic or set-theoretic operations can be used in expressing these propertiesThis method however does not account for functional andextra-functional properties of interfaces ie for behavior andperformance To account for behavior the classical approachin MDE consists in enriching components with methods thatcan be invoked from outside andor state machines Likewiseattributes on port methods have been used to represent non-functional requirements or provisions of a component [51]The effect of a method is made precise by the actual codethat is executed when calling this method The state machinedescription and the methods together provide directly animplementation for the component mdash actually several MDErelated tools such as GME and Rational Rose automaticallygenerate executable code from this specification [21] [132][161] The notion of refinement is replaced by the concept ofclass inheritance From a contract theory point of view thisapproach has several limitations Inheritance for instance isunable to cover aspects related to behavior refinement Noris it made precise what it means to take the conjunctionof interfaces which can only be approximated by multipleinheritance or to compose them
In a continuing effort since his joint work with W Dammon Life Sequence Charts (LSC) in 2000 [64] with its Play-
RR ndeg 8147
Contracts for System Design 24
Engine implementation [107] David Harel has developed theconcept of behavioral programming [108] [106] [109] whichputs in the forefront scenarios as a program developmentparadigmmdashnot just a specification formalism In behavioralprogramming b-threads generate a flow of events via anenhanced publishsubscribe protocol Each b-thread is a pro-cedure that runs in parallel to the other b-threads When ab-thread reaches a point that requires synchronization it waitsuntil all other b-threads reach synchronization points in theirown flow At synchronization points each b-thread specifiesthree sets of events requested events the thread proposes thatthese be considered for triggering and asks to be notifiedwhen any of them occurs waited-for events the thread doesnot request these but asks to be notified when any of themis triggered and blocked events the thread currently forbidstriggering any of these events When all b-threads are at asynchronization point an event is chosen (according to somepolicy) that is requested by at least one b-thread and is notblocked by any b-thread The selected event is then triggeredby resuming all the b-threads that either requested it or arewaiting for it This mechanism was implemented on top ofJava and LSCs The execution engine uses planning and modelchecking techniques to prevent the system from falling intodeadlock where all requested events are blocked Behavioralprogramming is incremental in that new threads can be addedto an existing program without the need for making any changeto this original program new deadlocks that are created bydoing so are pruned away by the execution engine Whilebehavioral programming cannot be seen as a paradigm ofcontracts it shares with contracts the objectives of incrementaldesign and declarative style of specification
Our focusmdashcontracts for systems and CPS The frame-works of contracts developed in the area of Software En-gineering have established as useful paradigms for compo-nent based software system development In this paper wetarget the wider area of computer controlled systems morerecently referred to as Cyber-Physical systems where reactivesystems [104] [110] [100] [136] are encountered that issystems that continuously interact with some environmentas opposed to transformational systems [100] considered inObject-Oriented programming For reactive systems model-based development (MBD) is generally accepted as a keyenabler due to its capabilities to support early validationand virtual system integration MBD-inspired design lan-guages and tools include SysML [149] or AADL [152] forsystem level modeling Modelica [93] for physical systemmodeling Matlab-Simulink [118] for control-law design andScade [144] [32] and TargetLink for detailed software designUML-related standardisation efforts in this area also includethe MARTE UML32 profile for real-time systems Contracttheories for model based development were considered inthe community of formal verification They were initiallydeveloped as specification formalisms able to refuse certaininputs from the environment Dill proposed asynchronous
32 wwwomgmarteorg
trace structures with failure behaviors [81] A trace structureis a representation of a component or interface with two setsof behaviors The set of successes are those behaviors whichare acceptable and guaranteed by the component Converselythe set of failures are behaviors which drive the componentinto unacceptable states and are therefore refused This workfocuses primarily on the problem of checking refinement anddoes not explore further the potentials of the formalism froma methodological point of view The work by Dill was laterextended by Wolf in the direction of synchronous systemsNegulescu later generalizes the algebra to Process Spaceswhich abstract away the specifics of the behaviors and derivesnew composition operators [143] This particular abstractiontechnique was earlier introduced by Burch with Trace Algebrasto construct conservative approximations [47] and later gen-eralized by Passerone and Burch [154] to study generic tracestructures with failure behaviors and to formalize the problemof computing the quotient (there called mirror) [153] Thispaper aims at proposing for model based design of systemsand CPS a new vista on contracts In the next section wepropose an all encompassing meta theory of contracts
V A MATHEMATICAL META-THEORY OF CONTRACTS
In software engineering meta-models are ldquomodels of mod-elsrdquo ie formal ways of specifying a certain family ofmodels Similarly we call here meta-theory a way to specifya particular family of theories In this section we proposea meta-theory of contracts This meta-theory is summarizedin Table IV It comes as a few primitive concepts on topof which derived concepts can be built A number of keyproperties can be proved about the resulting frameworkThese properties demonstrate that contracts are a convenientparadigm to support incremental development and independentimplementability in system design The meta-theory will serveas a benchmark for our subsequent review of concrete contracttheories
The meta-theory we develop here is novel There are veryfew attempts of that kind In fact the only ones we are awareof are the recent works by Bauer et al [22] and Chen et al [59]which follow a different (and complementary) approach Thediscussion of this work is deferred to the bibliographicalsection V-H
A Components and their composition
To introduce our meta-theory we start from a universe Mof possible components each denoted by the symbol M orE and a universe of their abstractions or contracts eachdenoted by the symbol C Our meta-theory does not presumeany particular modeling style neither for components nor forcontractsmdashwe have seen in Section IV an example of a (verysimple) framework for static systems More generally someframeworks may represent components and contracts with setsof discrete time or even continuous time traces other theoriesuse logics or state-based models of various kinds and so on
We assume a composition M1 timesM2 acting on pairs ofcomponents Component composition times is partially not to-
RR ndeg 8147
Contracts for System Design 25
Concept Definition and generic properties What depends on the particulartheory of contracts
Primitive
Component Components are denoted by M they can be open or closed How components are specified
Composabilityof components A type property on pairs of components (M1M2) How this type property is defined
Compositionof components
M1timesM2 is well defined if and only if M1 and M2 are composableIt is required that times is associative and commutative The definition of the composition
Environment An environment for component M is a componentE such that EtimesM is defined and closed
Derived
Contract A contract is a pair C = (EC MC ) where MC is a subsetof components and EC a subset of legal environments
Which family C of contractscan be expressed andhow they are expressedunless otherwise specifiedquantifying is implicitly over C isin C
Consistency C is consistent iff it has at least one component MC 6= empty How consistency is checked
Compatibility C is compatible iff it has at least one environment EC 6= empty How compatibility is checked
Implementation M |=M C if and only if M isinMCE |=E C if and only if E isinEC
How implementation is checked
Refinement Cprime C iff ECprime supe EC and MCprime subeMC Property 1 holds How refinement is checked
GLB andLUBof contracts
C1andC2 = Greatest Lower Bound (GLB) for we assume GLB existC1orC2 = Least Upper Bound (LUB) for we assume LUB exist
Property 2 holds
Whether and howGLB and LUB can beexpressed and computed
Compositionof contracts
C1otimesC2 is defined if M1 |=M C1M2 |=M C2
rArr (M1M2) composable
C1otimesC2 =andC
∣∣∣∣∣∣M1 |=M C1 and M2 |=M C2 and E |=E C
dArrM1 timesM2 |=M C and EtimesM2 |=E C1 and EtimesM1 |=E C2
Assumption 1 is in force Properties 3 4 and 5 holdSay that C1 and C2 are compatible if so is C1otimesC2
How composition isexpressed and computed
Quotient C1C2 =or C | C otimes C2 C1 Property 6 holds How quotient is
expressed and computed
Table IVSummary of the meta-theory of contracts We first list primitive concepts and then derived concepts introduced by the meta-theory
tally defined Two components that can be composed arecalled composable Composability of components is meantto be a typing property In order to guarantee that differentcomposable components may be assembled together in anyorder it is required that component composition times is asso-ciative and commutative Components that exhibit no meansfor interacting with the outside world are called closed othercomponents are open An environment for a component Mis another component E composable with M and such thatM times E is closed
B Contracts
In our primer of Section IV we have highlighted the im-portance of the legal environments associated with contractsfor which an implementation will operate satisfactorily At theabstract level of the meta-theory we make this explicit next
Definition 1 A contract is a pair C = (EC MC ) where
bull MC subeM is the set of implementations of C andbull EC subeM is the set of environments of C
For any pair (EM) isin EC times MC E is an environmentfor M Hence MtimesE must be well defined and closed Acontract possessing no implementation is called inconsistentA contract possessing no environment is called incompatibleWrite
M |=M C and E |=E C
to express that M isinMC and E isin EC respectivelyIn concrete theories of contracts both components and con-tracts are described in some finite (preferably concise) wayIn turn it is not true that every set Mprime subeM of componentscan be represented as Mprime = MC for some contract C andsimilarly for sets of environments To highlight this
we assume a family C of expressible contracts (5)
Only contracts belonging to this family can be consideredThis is made explicit in Table IV
C Refinement and conjunctionTo support independent implementability the concept of
contract refinement must ensure the following if contract Cprime
RR ndeg 8147
Contracts for System Design 26
refines contract C then any implementation of Cprime should 1)implement C and 2) be able to operate in any environment forC Hence the following definition for refinement preorder between contracts Cprime refines C written Cprime C if and onlyif MCprime sube MC and ECprime supe EC As a direct consequence thefollowing property holds which justifies the use of the termldquorefinementrdquo for this relation
Property 1 (refinement)1) Any implementation of Cprime is an implementation of C
M |=M Cprime rArrM |=M C and2) Any environment of C is an environment of Cprime
E |=E C rArr E |=E CprimeThe conjunction of contracts C1 and C2 written C1 and C2 isthe greatest lower bound (GLB) of these two contracts withrespect to refinement ordermdashwe assume such a GLB existsThe intent is to define this conjunction as the intersection ofsets of implementations and the union of sets of environmentsHowever due to (5) not every set of components is thecharacteristic set of a contract The best approximation consistsin taking the greatest lower bound for the refinement relationThe following immediate properties hold
Property 2 (shared refinement)1) Any contract that refines C1 and C2 also refines C1 and C2
Any implementation of C1 and C2 is a shared implementa-tion of C1 and C2 Any environment of C1 or C2 is anenvironment of C1 and C2
2) For C sube C a subset of contractsandC is compatible if
and only if there exists a compatible C isin C
The conjunction operation formalizes the intuitive notion of aldquoset of contractsrdquo or a ldquoset of requirementsrdquo
D Contract composition
The objective of contract composition is to ensure that1) composing respective implementations of each contract
yields an implementation for the composition and2) composing an environment for the resulting composition
with an implementation for C2 yields an environment forC1 and vice-versa
These two properties are essential in supporting top-downdesign by successive decompositions and refinements of con-tracts Contract composition C1 otimes C2 is thus defined on topof component composition as indicated in Table IV with thefollowing assumption in force throughout this meta-theory
Assumption 1 The following condition holds
C1 otimes C2 isin CC1otimesC2
(Note that this assumption is non trivial since it is not true foran arbitrary set C sube C that
andCisinC C isin C) The condition
for C1 otimes C2 to be defined is that every pair (M1M2) ofrespective implementations is composable so that M1 timesM2
is well definedmdashrecall that component composability is atyping property Consequently if E is an environment forM1timesM2 E is composable with both M1 and M2 and EtimesM1
is an environment for M2 and vice-versa Referring to the
formula defining C1 otimes C2 denote by CC1otimesC2 sube C the set ofcontracts specified in the brackets The following lemma willbe instrumental
Lemma 1 Let four contracts be such that Cprime1 C1Cprime2 C2 and C1 otimes C2 is well defined Then so is Cprime1 otimes Cprime2and CCprime1otimesCprime2 supe CC1otimesC2
Proof Since C1otimesC2 is well defined it follows that every pair(M1M2) of respective implementations of these contracts is acomposable pair of components Hence Cprime1otimesCprime2 is well definedaccording to the formula of Table IV Next since Cprime1 C1 andCprime2 C2 and using Assumption 1 M1 |=M Cprime1 and M2 |=M Cprime2implies M1 |=M C1 and M2 |=M C2 similarly E timesM2 |=E C1and EtimesM1 |=E C2 implies EtimesM2 |=E Cprime1 and EtimesM1 |=E Cprime2Therefore replacing in the big brackets defining the contractcomposition C1 by Cprime1 and C2 by Cprime2 can only increase the setCC1otimesC2 2
To conform to the usage we say that C1 and C2 arecompatible contracts if their composition C1 otimes C2 is definedand compatible in the sense of Table IV The followingproperties are a direct corollary of Lemma 1
Property 3 (independent implementability) For all con-tracts C1 C2 Cprime1 and Cprime2 if
1) C1 is compatible with C22) Cprime1 C1 and Cprime2 C2 hold
then Cprime1 is compatible with Cprime2 and Cprime1 otimes Cprime2 C1 otimes C2
Thus compatible contracts can be independently refined Thisproperty holds in particular if Cprime1 and Cprime2 are singletons
Corollary 1 Compatible contracts can be independentlyimplemented
Property 3 is fundamental particularly in top-down designTop-down incremental design consists in iteratively decom-posing a system-level contract C into sub-system contractsCi i isin I for further independent development To ensure thatindependent development will not lead to integration problemsit is enough to verify that
otimesiisinI Ci C We insist that since
contracts are purposely abstract and subsystems are not manythe composition of contracts Ci will not typically result in stateexplosion33
The following property is essential as it states that contractcomposition can be performed in any order and changesin architecture (captured by changes in parenthesizing) areallowed
Property 4 (associativity and commutativity) For all con-tracts C1 C2 C3 and C4 if C1 and C2 are compatible C3 andC4 are compatible and C1otimesC2 is compatible with C3otimesC4 thenC1 is compatible with C3 C2 is compatible with C4 C1 otimes C3is compatible with C2 otimes C4 and
(C1 otimes C2)otimes (C3 otimes C4) = (C1 otimes C3)otimes (C2 otimes C4) (6)
33 This is unlike in compositional verification where timesiisinIMi |=M Pis to be checked where Mi are detailed implementations and P is aproperty In this case the composition timesiisinIMi typically gives raise to stateexplosion Techniques have thus been proposed to verify such properties inan incremental way [176] [62] [98] [1] [121]
RR ndeg 8147
Contracts for System Design 27
Proof To shorten notations write C12 instead of C1 otimesC2 andsimilarly for any subset of 1 2 3 4 By Assumption 1 andthe associativity and commutativity of component composi-tion C1234 is characterized by the following two propertieswhere index i ranges over the set 1 4
Mi |=M Ci rArr M1times timesM4 |=M C1234
E |=E C1234 rArr Etimes (timesj 6=iMj) |=E Ci(7)
Observe that (7) is fully symmetric which proves (6) Nextusing the assumptions regarding compatibility we derive theexistence of at least one environment E satisfying the premiseof the second implication of (7) Since (7) is fully symmetricthis proves the conclusions of Property 4 regarding compati-bility 2
Property 5 (distributivity) If the following contract compo-sitions are all well defined then the following holds
[(C11 and C21)otimes (C12 and C22)] [(C11 otimes C12) and (C21 otimes C22)] (8)
Proof By Lemma 1 C(C11andC21)otimes(C12andC22) supe CC11otimesC12 Taking the GLB of these two sets thus yields[(C11 and C21)otimes (C12 and C22)] (C11 otimes C12) and similarlyfor (C21 otimes C22) Thus (8) follows 2
The use of distributivity is best illustrated in the followingcontext Suppose the system under design decomposes intotwo sub-systems labeled 1 and 2 and each subsystem hastwo viewpoints associated with it labeled by another indexwith values 1 or 2 Contract (C11 and C21) is then the contractassociated with sub-system 1 and similarly for sub-system 2Thus the left hand side of (8) specifies the set of imple-mentations obtained by first implementing each sub-systemindependently and then composing these implementationsProperty 5 states that by doing so we obtain an implemen-tation of the overall contract obtained by first getting thetwo global viewpoints (C11 otimes C12) and (C21 otimes C22) andthen taking their conjunction This property supports inde-pendent implementation for specifications involving multipleviewpoints Observe that only refinement not equality holdsin (8)
E Quotient
The quotient of two contracts is defined in Table IV It isthe adjoint of the product operation otimes in that C1C2 is themost general context C in which C2 refines C1 It formalizesthe practice of ldquopatchingrdquo a component to make it behavingaccording to another specification From its definition inTable IV we deduce the following property
Property 6 (quotient) The following holds
C C1C2 hArr C otimes C2 C1
Proof Immediate from the definition 2
F Discussion
By inspecting Table IV the different notions can be classi-fied into the following two categories
bull Primitive notions that are assumed by the meta-theoryThis category comprises components component com-posability and composition
bull Derived notions comprise contract refinement conjunc-tion composition and quotient consistency and com-patibility for contracts The derived notions follow fromthe primitive ones through set theoretic non effectivedefinitions
The meta-theory offers by itself a number of fundamentalproperties that underpin incremental development and inde-pendent implementability Concrete theories will offer defini-tions for the primitive notions as well as effective means toimplement (or sometimes approximate) the derived notionsObservers and then abstract interpretation we develop nextprovide generic approaches to recover effectiveness
G Observers
Notion Observer
C = (EC MC )(bEC b
MC)
C = C1andC2 bEC = bE
C1 or bEC2 b
MC = bM
C1 and bMC2
C = C1orC2 bEC = bE
C1 and bEC2 b
MC = bM
C1 or bMC2
C = C1otimesC2bEC(E) =
bMC1 (M1) and bM
C2 (M2)
dArrbEC2 (EtimesM1) and bE
C1 (EtimesM2)
bMC(M1 timesM2) = bM
C1 (M1) and bMC2 (M2)
Table VMirroring the algebra of contracts with observers
A typical obstacle in getting finite (or more generallyeffective) representations of contracts is the occurrence ofinfinite data types and functions having infinite domains Thesecan be dealt with by using observers which originate from thebasic notion of test for programs
Definition 2 Let C be a contract An observer for Cis a pair (bE
C bMC) of non-deterministic boolean functions
M 7rarr F T called verdicts such that
bEC(M) outputs F =rArr M 6isin ECbMC(M) outputs F =rArr M 6isin MC
(9)
The functions M 7rarr bEC(M) and M 7rarr bM
C(M) being bothnon-deterministic accounts for the fact that the outcome of atest depends on the stimuli from the environment and possiblyresults from internal non-determinism of the tested componentitself Note the single-sided implication in (9) which reflectsthat tests only provide semi-decisions
Relations and operations of the meta-theory can be mirroredby relations and operations on observers as explained inTable Vmdashwe omit the formulas for the quotient as semi-effectiveness of testing makes it useless Despite GLB andLUB can be mirrored using the formulas of the table nothingcan be said about the relationship of observers for contractsbased on the fact that they are in a refinement ordering Dually
RR ndeg 8147
Contracts for System Design 28
nothing can be inferred in terms of their refinement fromsuch a relationship between the observers Still the followingweaker result holds which justifies how GLB and LUB arerepresented using observers in Table V
Lemma 2 Let (bEC b
MC) be an observer for C and let Cprime C
Then any pair (bE bM) satisfying bE ge bEC and bM le bM
C is anobserver for CprimeThe following immediate results hold regarding consistencyand compatibility
Lemma 31) If bE
C(E) outputs F for all tested environment E then Cis incompatible
2) If bMC(M) outputs F for all tested component M then C
is inconsistent
To summarize Definition 2 provides semi-decision proceduresto check whether a component or an environment are validfor a contract Lemma 3 provides semi-decision proceduresfor checking consistency and compatibility Finally Table Vindicates how operations from the contract algebra can bereflected into operations on observers
Due to the need for exercising all components or environ-ments using observers for checking consistency or compat-ibility is still non-effective For concrete theories exhibitingsome notion of ldquostrongestrdquo environment or component for theconsidered contract a reinforcement of Lemma 3 will ensureeffectiveness
In Section VI where concrete theories are reviewed weindicate for each theory how observers can be constructedand how Lemma 3 specializes
H Bibliographical note
Abstract contract theories and features of our presen-tation Our presentation here is new There is only a smallliterature providing an abstract formalization of the notion ofcontracts The only attempts we are aware of are the recentworks by Bauer et al [22] and Chen et al [59] albeit withdeeply different and complementary approaches
The publication [22] develops an axiomatization of thenotion of specification from which contracts can be derivedin a second step More precisely specifications are abstractentities that obey the following list of axioms it possesses arefinement relation that is a preorder which induces a notionof equivalence of specifications and a parallel compositionthat is associative commutative (modulo equivalence) andmonotonic with respect to refinement It is assumed thatif two specifications possess a common lower bound thenthey possess a greatest lower bound A quotient is alsoassumed which is the residuation of the parallel composi-tion From specifications contracts are introduced as pairs ofspecifications very much like AssumeGuarantee contracts wedevelop in Section VII are pairs of assertions Sets of legalenvironments and sets of implementations are associated tocontracts Finally modal contracts are defined by borrowingideas from modal specifications we discuss in Section VIIIThis abstract theory nicely complements the one we develop
here in that it shows that both specifications and contracts canbe defined as primitive entities and be used to build moreconcrete theories
The work [59] develops the concept of declarative speci-fication which consists of a tuple P = (ΣinΣout TΣ FΣ)where Σin and Σout are input and output alphabets of actionsΣ = Σin ] Σout and TΣ FΣ sube Σlowast such that FΣ sube TΣ
are sets of permissible and inconsistent traces respectivelymdashthis approach find its origins in earlier work by Dill [81]and Negulescu [143] Outputs are under the control of thecomponent whereas inputs are issued by the environmentThus after any successful interaction between the componentand the environment the environment can issue any input αeven if it will be refused by the component If α is refusedby the component after the trace t isin TΣ tα isin FΣ is aninconsistent trace capturing that a communication mismatchhas occurred An environment is called safe if it can preventa component from performing an inconsistent trace For Qto be used in place of P it is required that Q must existsafely in any environment that P can exist in safely this isthe basis on which refinement is defined Alphabet extensionis used by which input actions outside the considered alphabetare followed by an arbitrary behavior for the declarativespecification A conjunction is proposed that is the GLB forrefinement order A parallel composition is proposed whichis monotonic with respect to refinement A quotient is alsoproposed which is the residuation of parallel composition
Observers Observers being related to the wide areaof software and system testing have been widely studiedA number of existing technologies support the design ofobservers and we review some of them now
Synchronous languages [28] [100] [30] are a formalism ofchoice in dealing with observers The family of SynchronousLanguages comprises mainly the imperative language Es-terel [92] [84] and the dataflow languages Lustre [144] andSignal [157] The family has grown with several childrenoffering statecharts-like interfaces and blending dataflow andstatechart-based styles of programming such as in Scade V634Synchronous languages support only systems governed bydiscrete time not systems with continuous time dynamics(ODEs) They benefit from a solid mathematical semantics Asa consequence executing a given program always yields thesame results (results do not depend on the type of simulator)The simulated or analysed program is identical to the codefor embedding Thanks to these unique features specificationscan easily be enhanced with timing andor safety viewpointsThe RT-Builder35 tool on top of Signal is an example offramework supporting the combination of functional and tim-ing viewpoints while analyzing an application deployed overa virtual architecture (see Section IV-D4) The widely usedSimulinkStateflow36 tool by The Mathworks offers similarfeatures One slight drawback is that its mathematical seman-
34httpwwwesterel-technologiescomproductsscade-suite35httpwwwgeensoftcomenarticlertbuilder36httpwwwmathworkscomproductssimulink
RR ndeg 8147
Contracts for System Design 29
tics is less firmly defined (indeed results of executions maydiffer depending on the code executed simulation or generatedC code) On the other hand Simulink supports continuoustime dynamics in the form of systems of interconnectedODEs (Ordinary Differential Equations) thus supporting themodeling of the physical part of the system Using Simulinkpossibly enhanced with SimScape37 allows for includingphysical system models in observers eg as part of the systemenvironment The same comment holds regarding Modelica38
Actually observers have been proposed and advocated in thecontext of Lustre and Scade [101] [102] [103] Esterel [45]and Signal [137] [138] More precisely Scade advocatesexpressing tests using Scade itself Tests can then easily beevaluated at run time while executing a Scade program Toconclude observe that synchronous languages and formalismsdiscussed in this section are commercially available and widelyused
Another good candidate for expressing observers is theProperty Specification Language (PSL) PSL is an industrialstandard [151] [86] [85] for expressing functional (or behav-ioral) properties targeted mainly to digital hardware designWe believe that PSL is indeed very close to several lessestablished but more versatile formalisms based on restrictedEnglish language that are used in industrial sectors otherthan digital hardware eg in aeronautics automobile orautomation Consider the following property
ldquo For every sequence that starts with an a imme-diately followed by three occurrences of b and endswith a single occurrence of c d holds continuouslyfrom the next step after the end of the sequence untilthe subsequent occurrence of e rdquo
This property is translated into its PSL version
[]ab[3]c |=gt (d until e)
PSL is a well-suited specification language for expressingfunctional requirements involving sequential causality of ac-tions and events Although we are not aware of the usageof PSL in the particular context of contract-based design wemention the tool FoCS [2] that translates PSL into checkersthat are attached to designs The resulting checker takes theform of an observer if the PSL specification is properlypartitioned into assumption and guarantee properties More re-cently PSL was also used for the generation of transactors thatmay adapt high-level requirements expressed as transaction-level modules to the corresponding register-transfer implemen-tation [18] [17] It follows that the existing tool support forPSL makes this specification language suitable in the contract-based design using observers We note that the availabilityof formal analysis tools allows the design to be checkedexhaustivelymdashthis is of course at the price of restrictionson data types Another benefit in using PSL as an observer-based interface formalism is an existing methodology for user-guided automated property exploration built around this lan-
37httpwwwmathworkscomproductssimscape38httpswwwmodelicaorg
guage [158] [42] that is supported by the tool RATSY [43]As previously stated PSL is built on top of LTL and regularexpressions One can thus express liveness properties in PSLwhich are not suitable for online monitoring There are twoorthogonal ways to avoid this potential issue (1) restrictingthe PSL syntax to its safety fragment or (2) adapting the PSLsemantics to be interpreted over finite traces [87] A survey ofusing PSL in runtime verification can be found in [85]
Another relevant formalism for building observers consistsof the Live Sequence Charts (LSC) [64] [107] [105] LSCare a graphical specification language based on scenarios thatis an extension of Message Sequence Charts (MSC)39 Atypical LSC consists of a prechart and a main chart Thesemantics is that whenever the prechart is satisfied in a run ofthe system eventually the main chart must also be satisfiedPrecharts should not be confused with assumptions howeverthey are rather sort of ldquoprerequisitesrdquo LSCs are multi-modalin that any construct in the language can be either cold orhot with a semantics of ldquomay happenrdquo or ldquomust happenrdquorespectively If a cold element is violated (say a conditionthat is not true when reached) this is considered a legalbehavior and some appropriate action is taken Violation ofa hot element however is considered a violation of thespecification and is not allowed to happen in an executionLSC are executable The execution of a set of LSCs is calledplay out by the authors [107] Play out is useful for checkingan LSC specification against a property [66] LSC can beused as (expressive) tests to monitor the execution of a designover non-terminating runs While doing so the same rules asabove are applied except that the design controls the emissionof events and the LSC specification is used to react in caseof violation of the specification This is manifested by theabsence of rules explaining the occurrence of some event atrun-time This procedure is called play in by the authors Toconclude LSCs are well suited to express observers
VI PANORAMA OF CONCRETE THEORIES
For the coming series of sections where concrete contracttheories are reviewed the reader is referred to Table IV ofSection V where the meta-theory of contracts is developedWe will illustrate how various concrete contract theories canbe developed by specializing the meta-theory
VII PANORAMA ASSUMEGUARANTEE CONTRACTS
Our static example of Section IV provided an exampleof contract specified using Assumptions and Guarantees As-sumeGuarantee contracts (AG-contracts) Assumptions char-acterize the valid environments for the considered compo-nent whereas the Guarantees specify the commitments ofthe component itself when put in interaction with a validenvironment Various kinds of AG-contract theories can beobtained by specializing the meta-theory in different waysVariations concern how the composition of components isdefined We will review some of these specialization and relatethem to the existing literature
39httpwwwsdl-forumorgMSCindexhtm
RR ndeg 8147
Contracts for System Design 30
In general AG contract theories build on top of componentmodels that are assertions ie sets of behaviors or tracesassigning successive values to variables As we shall seedifferent kinds of frameworks for assertions can be consid-ered including asynchronous frameworks of Kahn ProcessNetworks (KPN) [117] and synchronous frameworks in whichbehaviors are sequences of successive reactions assigningvalues to the set of variables of the considered system We firstdevelop the theory for the simplest case of a fixed alphabetThen we develop the other cases
A Dataflow AG contracts
For this simplest variant all components and contractsinvolve a same alphabet Σ of variables possessing identical40
domain DWith this simplification a component M identifies with an
assertion
P sube Σ 7rarr Dlowast cupDω (10)
ie a subset of the set of all finite or infinite behaviors overalphabet Σ such a behavior associates to each symbol x isin Σa finite or infinite flow of values The flows are not mutuallysynchronized and there is no global clock or logical step Wediscuss in Section VII-D variants of this framework with moresynchronous models of behaviors For convenience we feelfree to use both set theoretic and boolean notations for therelations and operations on assertions
Two components are always composable and we definecomponent composition by the intersection of their respectiveassertions
P1timesP2 = P1andP2 (11)
Formulas (10) and (11) define a framework of asynchronouscomponents with no global clock and no notion of reac-tion Instead a component specifies a relation between thehistories of its different flows When input and output portsare considered as in Section VII-B and components are in-putoutput functions we obtain the model of Kahn ProcessNetworks [117] widely used for the mapping of synchronousprograms over distributed architectures [159] [160]
Definition 3 A contract is a pair C = (AG) of assertionscalled the assumptions and the guarantees The set EC of thelegal environments for C collects all components E such thatE sube A The set MC of all components implementing C isdefined by AtimesM sube GThus any component M such that M le G or notA is animplementation of C and MC = G or notA is the maximalimplementation Observe that two contracts C and Cprime withidentical input and output alphabets identical assumptionsand such that Gprime or notAprime = G or notA possess identical sets ofimplementations MC =MCprime According to our meta-theorysuch two contracts are equivalent Any contract C = (AG)is equivalent to a contract in saturated form (AGprime) such that
40This is only an assumption intended to simplify the notations It is by nomeans essential
Gprime supe notA or equivalently G or A = T the true assertionto exhibit Gprime just take Gprime = G or notA A saturated contractC = (AG) is consistent if and only if G 6= empty and compatibleif and only if A 6= empty
Next for C and Cprime two saturated contracts with identicalinput and output alphabets
refinement Cprime C holds iffAprimegeAGprimeleG (12)
Conjunction follows from the refinement relation for C1 andC2 two saturated contracts with identical input and outputalphabets C1 and C2 = (A1orA2 G1andG2)
Focus now on contract composition C = C1 otimes C2 for twosaturated contractsmdashthis is no loss of generality as we haveseen Contract composition instantiates through the followingformulas cf (1) in Section IV
G = G1andG2
A = max
A∣∣∣∣∣∣AandG2rArrA1
andAandG1rArrA2
(13)
which satisfies Assumption 1 of the meta-theory If further-more contracts are saturated then (13) reformulates as theformulas originally proposed in [29]
G = G1 andG2
A = (A1 andA2) or not(G1 andG2)(14)
Observe that the so obtained contract (AG) is saturatedG orA = (G1 andG2) or (A1 andA2) or not(G1 andG2) = T
No quotient operation is known for AssumeGuaranteecontracts
We finish this section by observing that the two contractsC1 and Cprime1 of Section IV-A1 satisfy Cprime1 C1 according to thetheory of this section guarantees are identical but assumptionsare relaxed
B Capturing exceptions
Referring to the primer of Section IV-A1 and its staticsystem example dividing by zero may raise an exception Forinstance a careless designer may consider instead of M1 aslight variation M prime1 of it where the behaviors are only partiallydefined
M prime1 behaviors (y 6= 0rarr z = xy)
leaving what happens if a value 0 is submitted for y unspeci-fied In practice y = 0 would raise an exception leading to anunpredictable outcome and possibly a crash unless exceptionhandling is offered as a rescue by the execution platform
In this section we show how a mild adjustment of ourtheory of AG contracts can capture exceptions and theirhandling To simplify we develop this again for the case ofa fixed alphabet Σ We only present the add-ons with respectto the previous theories the parts that remain unchanged arenot repeated
Since exceptions are undesirable events caused by the com-ponent itself and not by its inputsmdashfor our simple example the
RR ndeg 8147
Contracts for System Design 31
exception is the improper handling of the division by zeromdashweneed to include inputs and outputs as part of our frameworkfor components
A component is thus a tuple M = (ΣinΣout P ) whereΣ = Σin cup Σout is the decomposition of alphabet Σ intoits inputs and outputs and P sube (Σ 7rarr (Dlowast cupDω)) is anassertion Whenever convenient we shall denote by Σin
M QM PM etc the items defining component M Components M1
and M2 are composable if Σout1 cap Σout
2 = empty If so thenM1timesM2 = (ΣinΣout P ) is well defined with Σout =Σout
1 cup Σout2 Σin = Σminus Σout and P = P1 cap P2
Let us now focus on exceptions To capture improper re-sponse (leading to a ldquocrashrdquo) we distinguish a special elementfail isin D We assume that crash is not revertible ie inany behavior of the component any variable remains at failwhen it reaches that value Referring to the static example ofSection IV we would then set x0 = fail for any x We arenow ready to formalize what it means for a component to befree of exception
Definition 4 A component M is free of exception if1) It accepts all inputs
prΣinM
(PM ) = ΣinM 7rarr (DlowastcupDω)
2) It does not cause by itself the occurrence of fail in itsbehaviors for any behavior σ isin PM if the projectionprΣin
M(σ) of σ to the input alphabet Σin
M does not involvefail then neither does σ
Exception freeness defined in this way is such that if M1 andM2 are both composable and free of exception then M1timesM2
is also free of exception Hence we are free to restrict ouruniverse of components to exception free componentsmdashthusDefinition 4 defines our family of components AG contractsare re-defined accordingly
Definition 5 A contract is a tuple C = (ΣinΣout AG)where Σin and Σout are the input and output alphabets andA and G are assertions over Σ called the assumptions andthe guarantees The set EC of the legal environments for C areall free of exception components E such that Σin
E = ΣoutC
ΣoutE = Σin
C and PE sube A The set MC of all componentsimplementing C is defined by M is free of exception Σin
M =ΣinC and Σout
M = ΣoutC and PEtimesM sube G for every environment
E of CFocus now on the issue of consistency and compatibility forcontracts The following holds
Property 7 Let C = (ΣinΣout AG) be a contract satis-fying the following conditions
prΣinC
(G) = ΣinM 7rarr (DlowastcupDω) (15)
prΣoutC
(A) = ΣoutM 7rarr (DlowastcupDω) (16)
fail does not occur in G andA (17)
Then C is consistent and compatibleProof By condition (15) the component M = (ΣinΣout G)satisfies condition 4 of Definition 4 It may not satisfy condi-tion 2 however To achieve this we must modify in M the
behaviors not belonging to A to avoid fail to occur PreservingM on A will ensure that implementation of C is preservedTo get M prime replace any behavior σ isin G and notA by a behaviorσprime such that prΣin
C(σprime) = prΣin
C(σ) and prΣout
C(σprime) 63 fail
Component M prime obtained in this way is free of exception andimplements C showing that C is consistent Consider next thecomponent E = (ΣoutΣin A) If E is free of exception thenit is an environment for C If this is not the case then we canmodify E on AandnotG as we did for obtaining M prime This yieldsan environment Eprime for C showing that C is compatible 2
Conditions (15) and (16) express that assumptions andguarantees are both input enabled Condition (17) is the keyone Observe that now contract Cprime1 of Section IV-A1 isinconsistent since it has no implementationmdashimplementationsmust be free of exception In turn contract C1 is consistentThis is in contrast to the theory of Section VII-A whereboth contracts were considered consistent (crashes were notruled out) Indeed contract C1 of Section IV-A1 satisfies theconditions of Property 7 whereas Cprime1 does not Addressingexceptions matters
C Dealing with variable alphabets
Since contracts aim at capturing incomplete designs wecannot restrict ourselves to a fixed alphabetmdashit is not known inadvance what the actual alphabet of the complete design willbe Thus the simple variants of Sections VII-A and VII-B haveno practical relevance and we must extend them to dealingwith variable alphabets In particular components will now bepairs M = (ΣM PM ) where ΣM is the alphabet of M andPM is an assertion over ΣM Similarly contracts are triplesC = (ΣC AC GC) where assumptions AC and guarantees GCare assertions over alphabet ΣC
Key to dealing with variable alphabet this is the operationof alphabet equalization that we introduce next For P an as-sertion over alphabet Σ and Σprime sube Σ we consider its projectionprΣprime(P ) over Σprime which is simply the set of all restrictionsto Σprime of all behaviors belonging to P We will also need theinverse projection prminus1
Σprimeprime (P ) for Σprimeprime supe Σ which is the set ofall behaviors over Σprimeprime projecting to Σ as behaviors of P For(Σi Pi) i = 1 2 we call alphabet equalization of (Σ1 P1)and (Σ2 P2) the two assertions (Σprminus1
Σ (Pi)) i = 1 2 whereΣ = Σ1 cup Σ2
We also need to define alphabet equalization when thealphabet Σ decomposes as Σ = Σin ] Σout Equalizing theabove decomposition to a larger alphabet Σprimeprime supe Σ yieldsΣprimeprimeout = Σout whence Σprimeprimein = Σprimeprime Σprimeprimeout follows
Alphabet equalization serves as a preparation step to reusethe framework of Section VII-A when alphabets are variable
This being defined all operations and relations introducedin Section VII-A are extended to the case of variable alphabetsby 1) applying alphabet equalization to the involved assertionsand 2) reusing the operation or relation as introduced inSection VII-A
As pointed out in [29] this generalization yields a contracttheory that is a valid instantiation of the meta-theory (up tothe missing quotient) It is not satisfactory from the practical
RR ndeg 8147
Contracts for System Design 32
standpoint however The reason is that the conjunction oftwo contracts with disjoint alphabets yields a trivial assump-tion T which is very demandingmdashany environment must beaccommodatedmdashand does not reflect the intuition (more onthis will be discussed in Section VIII-D
To summarize Sections VII-A VII-B and VII-C togetherdefine a framework for asynchronous AssumeGuarantee con-tracts where components are of Kahn Process Network type
D Synchronous AG contracts
We obtain variants of this framework of AssumeGuaranteecontracts by changing the concrete definition of what anassertion is and possibly revisiting what the component com-position is We can redefine assertions as
P sube (Σ 7rarr D)lowast cup (Σ 7rarr D)ω (18)
Compare (18) with (10) In both cases assertions are sets ofbehaviors With reference to (10) behaviors were tuples offinite or infinite flows one for each symbol of the alphabetIn contrast in (18) behaviors are finite or infinite sequencesof reactions which are the assignment of a value to eachsymbol of the alphabet By having a distinguished symbolperp isin D to model the absence of an actual data we getthe multiple-clocked synchronous model used by synchronouslanguages [30] Definition (18) for assertions correspond to thesynchronous model of computation whereas (10) correspondsto the Kahn Process Network type of model [117] [142] Thematerial of Sections VII-A VII-B and VII-C can be adaptedto this new model of component composition thus yielding aframework of synchronous AssumeGuarantee contracts
E Observers
The construction of observers for this case is immediate Wedevelop it for the most interesting case in which exceptions arehandled see Sections VII-A and VII-B Let P be an assertionaccording to (10) P defines a verdict bP by setting
bP (σ) = T if and only if σ isin P (19)
Observers must return their verdict in some finite amount oftime Hence on-line interpretation based on Definition 3 isappropriate With this interpretation for C = (ΣinΣout AG)a contract its associated observer is obtained as follows withreference to Definition 2
bull bEC(E) is performed by drawing non-deterministically a
behavior σ of E and then evaluating bA(σ)bull bMC(M) is performed by drawing non-deterministically a
behavior σ of M and then evaluating bA(σ)rArr bM (σ)
Lemma 3 for generic observers specializes to the followingeffective semi-decision procedure
Lemma 4
1) If bA outputs F then C is incompatible2) If bA rArr bG outputs F then C is inconsistent
F Discussion
AssumeGuarantee contracts are a family of instantiationsof our meta-theory This family is flexible in that it canaccommodate different models of communication and differentmodels of exceptions AssumeGuarantee contracts are anadequate framework for use in requirements capture Indeedrequirements are naturally seen as assertions When categoriz-ing requirements into assumptions (specifying the context ofuse of the system under development) and guarantees (that thesystem offers) formalizing the resulting set of requirements asan AG contract seems very natural
Regarding exceptions the special value fail that we intro-duced to capture exceptions is not something that is given inpractice Value fail may subsume various run time errors Al-ternatively for the synchronous AssumeGuarantee contractsfail can capture the failure of a component to be input enabled(able in each reaction to accept any tuple of inputs)
In its present form the framework of AssumeGuaranteecontracts (synchronous or asynchronous) suffers from theneed to manipulate negations of assertions an operation thatis generally not effective except if the framework is restrictedto finite state automata and finite alphabets of actions Forgeneral frameworks using observers or abstract interpretationcan mitigate this in part
G Bibliographical note
By explicitly relying on the notions of Assumptions andGuarantees AG-contracts are intuitive which makes themappealing for the engineer In AG-contracts Assumptions andGuarantees are just properties The typical case is when theseproperties are languages or sets of traces which includes theclass of safety properties [122] [58] [136] [14] [61] AG-contracts were advocated by the SPEEDS project [29] Theywere further experimented in the framework of the CESARproject [63] with the additional consideration of weak andstrong assumptions The theory developed in [29] turns outto be closest to this presentation still exceptions were nothandled in [29] The presentation developed in this paperclarifies the design choices in AG-contract theories
Inspired by [126] another form for AG-contract was pro-posed by [97] [99] when designs are expressed using theBIP programming language [41] [174] To achieve separatedevelopment of components and to overcome the problemsthat certain models have with the effective computation ofthe operators the authors avoid using parallel compositionotimes of contracts Instead they replace it with the concept ofcircular reasoning which states as follows in its simplestform if design M satisfies property G under assumptionA and if design N satisfies assumption A then M times Nsatisfies G When circular reasoning is sound it is possibleto check relations between composite contracts based ontheir components only without taking expensive compositionsIn order for circular reasoning to hold the authors deviserestricted notions of refinement under context and show howto implement the relations in the contract theory for the BIP
RR ndeg 8147
Contracts for System Design 33
framework Compatibility is not addressed and this proposaldoes not consider conjunction
Regarding extensions a notion of contract for real-timeinterfaces is proposed in [40] Sets of tasks are associated tocomponents which are individually schedulable on a processorAn interface for a component is an ω-language containing alllegal schedules Schedulability of a set of components on asingle processor then corresponds to checking the emptinessof their intersection The interface language considered isexpressive enough to specify a variety of requirements likeperiodicity the absence or the presence of a jitter etc An as-sumeguarantee contract theory for interfaces is then developedwhere both assumptions and guarantees talk about boundson the frequency of task arrivals and time to completionsDependencies between tasks can also be captured Refinementand parallel product of contracts are then defined exactly asin the SPEEDS generic approach
In [145] a platform-based design methodology that usesAG analog contracts is proposed to develop reliable ab-stractions and design-independent interfaces for analog andmixed-signal integrated circuit design Horizontal and verti-cal contracts are formulated to produce implementations bycomposition and refinement that are correct by constructionThe effectiveness of the methodology is demonstrated on thedesign of an ultra-wide band receiver used in an intelligenttire system an on-vehicle wireless sensor network for activesafety applications
AG-contracts have been extended to a stochastic setting byDelahaye et al [75] [76] [77] In this work the implementa-tion relation becomes quantitative More precisely implemen-tation is measured in two ways reliability and availabilityAvailability is a measure of the time during which a systemsatisfies a given property for all possible runs of the system Incontrast reliability is a measure of the set of runs of a systemthat satisfy a given property Following the lines of the contracttheories presented earlier satisfaction is assumption-dependentin the sense that runs that do not satisfy the assumptions areconsidered to be ldquocorrectrdquo the theory supports refinementstructural composition and logical conjunction of contractsand compositional reasoning methods have been proposedwhere the stochastic or non-stochastic satisfaction levels canbe budgeted across the architecture For instance assume thatimplementation Mi satisfies contract Ci with probability αifor i = 1 2 then the composition of the two implementationsM1timesM2 satisfies the composition of the two contracts C1otimesC2
with probability at least α1 + α2 minus 1Features of our presentation This presentation of AG-
contracts is new in may respects For the first time it iscast into the meta-theory of contracts with the advantage ofclarifying the definition of refinement and parallel compositionof contractsmdashthis involved some hand waving in the originalwork [29] Also this allowed us to handle exceptions properly
VIII PANORAMA INTERFACE THEORIES
Interface theories are an interesting alternative to As-sumeGuarantee contracts They aim at providing a merged
specification of the implementations and environments associ-ated to a contract via the description of a single entity calledan interface We review some typical instances of interfacetheories with emphasis on interface automata and modalinterfaces Interface theories generally use (a mild variation of)Lynch InputOutput Automata [135] [134] as their frameworkfor components and environments As a prerequisite we thusrecall the background on InputOutput Automata io-automatafor short
A Components as io-automataAn io-automaton is a tuple M = (ΣinΣout Q q0rarr)
wherebull Σin and Σout are disjoint finite input and output alpha-
bets set Σ = Σin cup Σoutbull Q is a finite set of states and q0isinQ is the initial statebull rarr sube QtimesΣtimesQ is the transition relation as usual we
write q αminusrarr qprime to mean (q α qprime) isin rarr and qαminusrarr to
indicate the existence of a qprime such that q αminusrarr qprimeBy concatenation transition relation rarr extends to a relationrarrlowast on Q times Σlowast times Q where Σlowast is the set of all finite wordsover Σ Say that a state qprime is reachable from q if there existssome word m such that q mminusrarrlowast qprime To considerably simplifythe development of the theory we restrict ourselves to
deterministic io-automata ie such thatq
αminusrarr q1 and q αminusrarr q2 implies q2 = q1(20)
Two io-automata M1 and M2 having identical alphabet Σare composable if the usual inputoutput matching conditionholds Σout
1 capΣout2 = empty and their composition M = M1timesM2
is given by
Σin = Σin1 cap Σin
2
Σout = Σout1 cup Σout
2
Q = Q1 timesQ2 and q0 = (q10 q20)
and the transition relation rarr is given by
(q1 q2)αminusrarr (qprime1 q
prime2) iff qi
αminusrarri qprimei i = 1 2
An io-automaton is said closed whenever Σin = empty and openotherwise For Mi i = 1 2 two io-automata and two statesqi isin Qi say that q1 simulates q2 written q2leq1 if
forallα qprime2 such that q2αminusrarr2 qprime2 rArr
q1
αminusrarr1 qprime1
and qprime2leqprime1(21)
Say that
M1 simulates M2 written M2leM1 if q20leq10 (22)
Observe that simulation relation (2122) does not distinguishinputs from outputs neither it distinguishes the componentfrom its environment It is the classical simulation relationmeant for closed systems Due to condition (20) of determin-ism simulation coincides with language inclusion
Variable alphabet is again dealt with using the mechanismof alphabet equalization For M = (ΣinΣout Q q0rarr) anio-automaton and Σprime sup Σ we define
MuarrΣprime
=(Σin cup (Σprime Σ)Σout Q q0rarrprime
)RR ndeg 8147
Contracts for System Design 34
whererarrprime is obtained by adding torarr for each state and eachadded action a self-loop at this state labeled with this action
Componentsmdashand consequently environmentsmdashfor use ininterface theories will be receptive io-automata (also termedinput enabled) ie they should react by proper response toany input stimulus in any state41
M is receptive iff forallq isin Qforallα isin Σin qαminusrarr (23)
Receptiveness is stable under parallel composition
B Interface Automata with fixed alphabet
For reasons that will become clear later we restrict thepresentation of interface automata to the case of a fixedalphabet Σ We begin with the definition of Interface Automatawhich are possibly non-receptive io-automata Moreover wegive their interpretation as contracts according to the meta-theory
Definition 6 An Interface Automaton is a tuple C =(ΣinΣout Q q0rarr) where ΣinΣout Qrarr are as inio-automata
The initial state q0 however may not satisfy q0isinQ If q0isinQholds Interface Automaton C defines a contract by fixing apair (EC MC ) as followsbull The set EC of the legal environments for C collects all
components E such that1) Σin
E = Σout and ΣoutE = Σin Thus E and C seen as
io-automata are composable and E timesC is closed2) For any output action α isin Σin of environment E
such that qEαminusrarrE and any reachable state (qE q)
of E times C then (qE q)αminusrarrEtimesC holds
There exists a unique maximal environment EC isin EC inthat EC timesC simulates EtimesC in the sense of (22) for anyE isin EC EC = (ΣoutΣin Q cup gt q0rarrEC ) where(a) the restriction to Qtimes ΣtimesQ of transition relationrarrEC coincides with rarr
(b) forallq isin Q q αminusrarrEC gt holds if and only if not[qαminusrarr ]
and α isin Σout(c) gt αminusrarrEC gt holds for any α isin Σ
bull The setMC of the implementations of C collects all com-ponents M such that io-automaton C simulates ECtimesMin the sense of (22)
Condition 2) means that environment E is only willing toemit an output if it is accepted as an input by C in thecomposition E times C Regarding the existence and uniquenessof EC observe first that conditions (a) and (b) together implythat EC is receptive Also by (a) and (b) EC times C is strictlyidentical with (emptyΣ Q q0rarr) ie it is obtained from Cseen as an io-automaton by simply turning inputs to outputsConsequently Condition 2) holds and thus EC isin EC By (b)and (c) EC is maximal
The above definition of Interface Automata is heterodoxcompare with the original references [72] [5] Definition 6
41In fact receptiveness is assumed in the original notion of io-automatonby Nancy Lynch [135] [134] We use here a relaxed version of io-automatonfor reasons that will become clear later
introduces the two sets EC and MC whereas no notionof implementation or environment is formally associated toan Interface Automaton in the original definition Also thehandling of the initial state is unusual Failure of q0isinQ tohold typically arises when the set of states Q is emptyOur Definition 6 allows to cast Interface Automata in theframework of the meta-theory of Table IV
Corresponding relations and operations must be instantiatedand we do this next As a first immediate result
Lemma 5 q0 isin Q is the necessary and sufficient conditionfor C to be both consistent and compatible in the sense of themeta-theory ie EC 6= empty and MC 6= empty
Refinement and conjunction Contract refinement as de-fined in Table IV is equivalent to alternate simulation [10]defined as follows for Ci i = 1 2 two contracts say that tworespective states qi i = 1 2 are in alternate simulation writtenq2q1 if
forallα isin Σout2 qprime2 st q2
αminusrarr2 qprime2 rArr
α isin Σout
1
q1αminusrarr1 qprime1
qprime2qprime1
forallα isin Σin1 q
prime1 st q1
αminusrarr1 qprime1 rArr
α isin Σin
2
q2αminusrarr2 qprime2
qprime2qprime1
(24)
Say that C2 refines C1 written C2C1 if q20q10 The firstcondition of (24) reflects the inclusionMC2
subeMC1 whereas
the second condition of (24) reflects the opposite inclusionEC2supe EC1
Alternate simulation can be effectively checkedsee [70] for issues of computational complexity Unfortunatelyno simple formula for the conjunction of contracts is knownSee [83] for the best results in this direction
Parallel composition and quotient Contract compositionC2otimesC1 as defined in the meta-theory is effectively computedas follows for Ci two Interface Automata satisfying the con-ditions of Lemma 5 Consider as a first candidate for contractcomposition the composition C2timesC1 where Ci i = 1 2 areseen as io-automata This first guess does not work becauseof the condition involving environments in the contract compo-sition of the meta-theory More precisely by the meta-theorywe should have
E |=E C rArr [EtimesM2 |=E C1 and EtimesM1 |=E C2]
which requires forallα isin Σouti qi
αminusrarri rArr (q1 q2)αminusrarrC2timesC1
Pairs (q1 q2) not satisfying this are called illegal In words apair of states (q1 q2) is illegal when one Interface Automatonwants to submit an output whereas the other one refuses toaccept itmdashreferring to AssumeGuarantee contracts one couldinterpret this as a mismatch of assumptions and guaranteesin this pair of interfaces Illegal pairs must then be prunedaway Pruning away illegal pairs from C2timesC1 together withcorresponding incoming transitions may cause other illegalpairs to occur The latter must also be pruned away untilfixpoint occurs The result is the contract composition C2otimesC1
RR ndeg 8147
Contracts for System Design 35
As a result of this pruning it may be the case that theresulting contract has empty set of states which by Lemma 5expresses that the resulting composition of the two interfacesis inconsistent and incompatiblemdashin the original literature onInterface Automata [72] [5] it is said that the two interfacesC1 and C2 are incompatible
In [39] incremental design of deterministic Interface Au-tomata is studied Let Cdarr be the interface C with input andoutput actions interchanged Given two Interface Automata C1and C2 the greatest interface compatible with C2 such that theircomposition refines C1 is given by (C2 C1darr)darr Hence the partregarding quotient in the meta-theory is correctly addressed fordeterministic Interface Automata
Dealing with variable alphabets So far we have pre-sented the framework of interface automata for the case of afixed alphabet The clever reader may expect that dealing withvariable alphabets can be achieved by using the mechanismof alphabet equalization via inverse projections42 This is acorrect guess for contract composition It is however not clearif it is also adapted for conjunction for which no satisfactoryconstruction exists as previously indicated
In contrast alphabet equalization and conjunction are el-egantly addressed by the alternative framework of ModalInterfaces we develop now
C Modal Interfaces with fixed alphabet
Modal Interfaces inherit from both the Interface Au-tomata and the originally unrelated notion of Modal Automa-ton (or Modal Transition System) see the bibliographicalnote VIII-G As Interface Automata Modal Interfaces usereceptive io-automata as their components and environmentsThe presentation of Modal Interfaces we develop here isaligned with our meta-theory and thus differs from classicalpresentations Again we begin with the case of a fixedalphabet Σ
Definition 7 We call Modal Interface a tuple of the formC = (ΣinΣout Q q0rarr 99K) where ΣinΣout Q q0 are asin Interface Automata and rarr 99Ksube Q times Σ times Q are twotransition relations called must and may respectively
A Modal Interface C such that q0isinQ induces two (possiblynon receptive) io-automata
and Cmust = (ΣinΣout Q q0rarr)and Cmay = (ΣinΣout Q q0 99K)
A Modal Interface is deterministic if Cmay is deterministic inthe sense of 20 C defines a contract by fixing a pair (EC MC )as follows
The set EC of the legal environments for C collects allcomponents E such that
1) ΣinE = Σout and Σout
E = Σin consequently E andCmust seen as io-automata are composable and E timesCmust is closed the same holds with Cmay in lieu ofCmust
42The inverse projection of an io-automaton is simply achieved by addingin each state a self-loop for each missing symbol
2) For any α isin Σin such that qEαminusrarrE and any reachable
state (qE q) of E times Cmay (qE q)αminusrarrEtimesCmust
There exists a unique maximal environment EC isin EC in thatEC times Cmay simulates E times Cmay in the sense of (22) for anyE isin EC EC = (ΣoutΣin Q cup gt q0rarrEC ) where(a) the restriction to QtimesΣintimesQ of transition relationrarrEC
coincides with rarr the restriction to Q times Σout times Q oftransition relation rarrEC coincides with 99K
(b) for any q isin Q q αminusrarrEC gt holds if and only if not[qα99K ]
and α isin Σout(c) gt αminusrarrEC gt holds for any α isin Σ
The set MC of the implementations of C collects all compo-nents M such that
3) ECtimesCmay simulates ECtimesM in the sense of (22)[only may transitions are allowed for ECtimesM ]
4) for any reachable state (qE qM ) of ECtimesM and (qE q)of ECtimesCmay such that (qE qM )le(qE q) and any ac-tion α isin Σout
M such that q αrarr then (qE qM )αminusrarrECtimesM
[must transitions are mandatory in ECtimesM ]
The first paragraph is a verbatim of the original definition ofModal Interfaces [166] Definition 7 introduces the two setsEC and MC whereas the classical theory of Modal Interfacesconsiders and develops a different notion of model (oftenalso called ldquoimplementationrdquo which is unfortunate) As forInterface Automata in Section VIII-B the handling of initialstate q0 is heterodox Our Definition 7 allows to cast ModalInterfaces in the framework of the meta-theory
To justify the existence and uniqueness of EC observe firstthat conditions (a) and (b) together imply that EC is receptiveCondition (2) follows from (a) Maximality in the sense of(22) follows from (b) and (c)
Consistency and Compatibility We begin with consis-tency Say that state q isin Q of C is consistent if q αrarr impliesq
α99K otherwise we say that it is inconsistent Assume thatC has some inconsistent state q isin Q meaning that for someaction α q αrarr holds but q
α99K does not hold By conditions 3)
and 4) of Definition 7 for any environment E and anyimplementation M of C no state (qE qM ) of EtimesM satisfies(qE qM )leq Hence all may transitions leading to q can bedeleted from C without changing MC Performing this makesstate q unreachable in Cmay thus Condition 2 of Definition 7is relaxed and the set of environments is possibly augmentedSince we have removed may transitions some more stateshave possibly become inconsistent So we must repeat thesame procedure Since the number of states is finite thisprocedure eventually reaches a fixpoint At fixpoint the setQ of states partition as Q = Qcon ]Qincon where Qincon
collects all states that were or became inconsistent as a resultof this procedure and Qcon only collects consistent statesIn addition since the fixpoint has been reached Qincon isunreachable from Qcon As a final step we delete Qincon andcall [C] the so obtained contract The following result holds
Lemma 6
RR ndeg 8147
Contracts for System Design 36
1) Modal Interface [C] satisfies
M[C]
=MC and E[C]supe EC (25)
where the inclusion is strict unless C possesses noinconsistent state
2) [C] offers the smallest set of environments among theModal Interfaces satisfying (25)
3) C is consistent and compatible if and only if Qcon 3 q0In the sequel unless otherwise specified we will only considerModal Interfaces that are consistent and compatible
Refinement and conjunction Conjunction and refinementare instantiated in a very elegant way in the theory of ModalInterfaces Contract refinement in the sense of the meta-theoryis instantiated by the effective notion of Modal refinement weintroduce now Roughly speaking modal refinement consistsin enlarging the must relation (thus enlarging the set of legalenvironments) and restricting the may relation (thus restrictingthe set of implementations) The formalization requires the useof simulation relations
For C a Modal Interface and qisinQ a state of it introducethe following may and must sets
may(q) = α isin Σ | q α99K
must(q) = α isin Σ | q αrarr
Definition 8 (modal refinement) Let Ci i = 1 2 be twoModal Interfaces and let qi be a state of Ci for i = 1 2Say that q2 refines q1 written q2 q1 if
may2(q2) sube may1(q1)must2(q2) supe must1(q1)
and forallα isin Σ
q1
α99K1 qprime1
q2α99K2 qprime2
=rArr qprime2 qprime1
Say that C2 C1 if q20 q10
The following result relates modal refinement with contractrefinement as defined in the meta-theory It justifies the con-sideration of modal refinement Its proof follows by direct useof Definition 7 and Lemma 6
Lemma 7 For C1 and C2 two Modal Interfaces the follow-ing two properties are equivalent(i) MC2
sube MC1and EC2
supe EC1 meaning that contract C2
refines contract C1 following the meta-theory(ii) [C2] [C1] ie [C2] refines contract [C1] in the sense of
modal refinementThe conjunction of two Modal Interfaces is thus the GreatestLower Bound (GLB) with respect to refinement order Itscomputation proceeds in two steps In a first step we wildlyenforce the GLB and compute a pre-conjunction by takingunion of must sets and intersection of may sets
Definition 9 The pre-conjunction43 C1andC2 of two ModalInterfaces is only defined if Σin
1 = Σin2 and Σout
1 = Σout2
43Pre-conjunction was originally denoted by the symbol amp in [164] [167][166]
and is given by Σin = Σin1 Σout = Σout
1 Q = Q1timesQ2q0 = (q10 q20) and its two transition relations are given by
must(q1 q2) = must1(q1) cupmust2(q2)may(q1 q2) = may1(q1) capmay2(q2)
(26)
Due to (26) C1andC2 may involve inconsistent states and thusin a second step the pruning introduced in Lemma 6 must beapplied
C1 and C2 = [C1andC2] (27)
Say that the two Modal Interfaces C1 and C2 are consistent44
if C1 and C2 is consistent in the sense of Lemma 6Parallel composition and quotient For Modal Interfaces
we are able to define both parallel composition and quotient inthe sense of the meta-theory As it was the case for InterfaceAutomata parallel composition for Modal Interfaces raisescompatibility issues and thus a two-step procedure is againfollowed for its computation
Definition 10 The pre-composition C1otimesC2 of two ModalInterfaces is only defined if Σout
1 capΣout2 = empty and is given by
Σout = Σout1 cup Σout
2 Q = Q1timesQ2 q0 = (q10 q20) and itstwo transition relations are given by
must(q1 q2) = must1(q1) capmust2(q2)may(q1 q2) = may1(q1) capmay2(q2)
(28)
Say that a state (q1 q2) of C1otimesC2 is illegal if
may1(q1) cap Σin2 6sube must2(q2)
or may2(q2) cap Σin1 6sube must1(q1)
Illegal states are pruned away from C1otimesC2 as follows Removefrom Cmay
1 times Cmay2 all transitions leading to (q1 q2) As
performing this may create new illegal states the same isrepeated until fixpoint is reached As a final step we delete thestates that are not may-reachable This finally yields C1otimesC2which no more possesses illegal states
The above construction is justified by the following resultLemma 8 C1otimesC2 as defined in Definition 10 instantiates
the contract composition from the meta-theory
Proof (sketch) E is an environment for C iff for any reachablestate (qE q1 q2) of E times Cmay
1 times Cmay2 we have
rs(qE ) sube must1(q1) capmust2(q2) (29)
where rs(q) the ready set of state q is the subset of actionsα such that q αminusrarr holds Let M1 be any implementation ofC1 and consider EtimesM1 We need to prove that EtimesM1 is anenvironment for C2 ie satisfies Condition 2 of Definition 7(we must also prove the symmetric property) Let (qE q1 q2)be a reachable state of EtimesM1timesCmay
2 We must prove
rs(qE ) cap rsM1 (q1 ) cap Σ in2 sube must2(q2)
By (29) it suffices that the following property holds
rsM1(q1 ) cap Σ in
2 sube must2(q2) (30)
44This is the usual wording in the literature
RR ndeg 8147
Contracts for System Design 37
However we only know that rsM1(q1 ) sube may1 (q1 ) Hence
to guarantee (30) we must prune away illegal pairs of statesTo this end we use the same procedure as before we makestate (q1 q2) unreachable in Cmay
1 timesCmay2 by removing all may
transitions leading to that state We complete the reasoning aswe did for the study of consistency 2
Definition 11 The quotient C1C2 of two modal interfacesC1 and C2 is only defined if Σin
1 cap Σout2 = empty and is defined
according to the following two steps procedure First defineC as follows Σout = Σout
1 Σout2 Q = Q1 times Q2 q0 =
(q10 q20) and its two transition relations are given by
must(q1 q2) = must1(q1)
may(q1 q2) = not [may1(q1) cap notmust1(q1)] cupnot [must1(q1) capmust2(q2)] cupnot [may1(q1) cupmay2(q2)]
These formulas may give raise to inconsistent states and thusin a second step we set C1C2 = [C]This definition is justified by the following result [166]showing that Definition 11 instantiates the meta-theory
Lemma 9 C1 otimes C2 C if and only if C2 CC1
Now it may be that (C1C2)otimesC2 possess illegal pairs of states(Definition 10) whence the following improvement whereΣout and Σin are as in Definition 11 and may and mustrefer to the quotient C1C2
Definition 12 Let Cprime be the interface defined on the samestate structure as C1C2 with however the following modali-ties
may prime(q1 q2) = may(q1 q2) cap(may2(q2) cup Σin
)must prime(q1 q2) = must(q1 q2) cup (Σout
1 cap Σout2 capmay2(q2))
define the compatible quotient written C1C2 to be thereduction of Cprime C1C2 = [Cprime]
This construction is justified by the following result
Lemma 10 The compatible quotient C1C2 solves thefollowing problem
max
C∣∣∣∣∣∣C has no inconsistent stateC otimes C2 has no illegal pair of statesC otimes C2 C1
Proof Denote C = C1C2 the compatible quotient definedabove The proof is threefold (i) C is proved to be a solutionof the inequality CotimesC2 C1 (ii) C is proved to be compatiblewith C2 and (iii) every Cprime satisfying the two conditions aboveis proved to be a refinement of C
Remark that reachable states in (C1C2)otimesC2 are of the form(q1 q2 q2) and that for every reachable state pair (q1 q2) inC1C2 state (q1 q2 q2) is reachable in (C1C2)otimes C2
(i) Remark that may prime sube may and must prime supe must HenceC1C2 C1C2 Since the parallel composition is monotonic(C1C2)otimes C2 (C1C2)otimes C2 C1
(ii) For every state (q1 q2 q2) reachable in (C1C2)otimes C2one among the following three cases occurs
bull Assume e isin Σin1 meaning that e is an input for both C2
and C1C2 Hence state (q1 q2 q2) is not illegal becauseof e
bull Assume e isin Σout1 cap Σout
2 Therefore e is an input of thecompatible quotient Remark must prime(q1 q2) sube may2(q2)Hence state (q1 q2 q2) is not illegal because of e
bull Assume e isin Σout1 capΣin
2 meaning that e is an output of thecompatible quotient Remark may prime(q1 q2) sube must2(q2)Therefore state (q1 q2 q2) is not illegal because of e
(iii) Let Cprimeprime be a modal interface such that C1C2 Cprimeprime C1C2 We shall prove that either Cprimeprime C1C2 or that Cprimeprime is notcompatible with C2 Remark that every reachable state (q1 q2)of C1C2 is related to exactly one state qprimeprime of Cprimeprime by the twomodal refinement relations Assume that Cprimeprime is not a refinementof C1C2 meaning that there exists related states (q1 q2)and qprimeprime such that may prime(q1 q2) sube may primeprime(qprimeprime) sube may(q1 q2)and must prime(q1 q2) supe must primeprime(qprimeprime) supe must(q1 q2) and eithermay prime(q1 q2) ( may primeprime(qprimeprime) or must prime(q1 q2) ) must primeprime(qprimeprime)Remark e isin Σin
1 implies that e isin may prime(q1 q2) iff e isinmay(q1 q2) and that e isin must prime(q1 q2) iff e isin must(q1 q2)Therefore the case e isin Σin
1 does not have to be considered
1) Assume there exists e such that e isin may primeprime(qprimeprime) may prime(q1 q2) Remark this implies e isin Σout
1 cap Σin2
meaning that e is an output of the compatible quo-tient Remark also that e 6isin must2(q2) Therefore state(qprimeprime q2) is illegal in Cprimeprime otimes C2
2) Assume there exists e such that e isin must prime(q1 q2) must primeprime(qprimeprime) Remark this implies e isin Σout
1 cap Σout2
meaning that e is an input of the compatible quotientRemark also that e isin may2(q2) Therefore state (qprimeprime q2)is illegal in Cprimeprime otimes C2
2
D Modal Interfaces with variable alphabet
As a general principle every relation or operator introducedin Section VIII-C (for Modal Interfaces with a fixed alphabetΣ) is extended to the case of variable alphabets by 1) extendingand equalizing alphabets and then 2) applying the relations oroperators of Section VIII-C to the resulting Modal InterfacesFor all frameworks we studied so far alphabet extension wasperformed using inverse projections see Section VII-C Forinstance this is the procedure used in defining the compositionof io-automata extending alphabets in io-automata is byadding at each state and for each added action a self-loop labeled with this action The very reason for using thismechanism is that it is neutral for the composition in thefollowing sense it leaves the companion io-automaton freeto perform any wanted local action
So for Modal Interfaces what would be a neutral procedurefor extending alphabets Indeed considering (26) or (28)
RR ndeg 8147
Contracts for System Design 38
yields two different answers namely
for (26)
α isin may1(q1) and α isin whatever2(q2)dArr
α isin whatever(q1 q2)
for (28)
α isin must1(q1) and α isin whatever2(q2)dArr
α isin whatever(q1 q2)
where ldquowhateverrdquo denotes either may or must Consequentlyneutral alphabet extension is by adding
bull may self-loops for the conjunction andbull must self-loops for the composition
The bottom line is that we need different extension proceduresThese observations explain why alphabet extension is properlyhandled neither by Interface Automata (see the last paragraphof Section VIII-B) nor by AG-contracts (see the end ofSection VII-C) These theories do not offer enough flexibilityfor ensuring neutral extension for all relations or operators
We now list how alphabet extension must be performed foreach relation or operator for two Modal Interfaces C1 and C2(the reader is referred to [166] for justifications) Alphabetsare extended as follows where Σprime supe Σ Define the strongextension of C to Σprime written CuarrΣprime
as follows
CuarrΣprime
(Σin)uarrΣprime
= Σin cup (Σprime Σ)
(Σout)uarrΣprime
= Σout
QuarrΣprime
= Q
quarrΣprime
0 = q0
mayuarrΣprime
= may cup (Σprime Σ)
mustuarrΣprime
= must cup (Σprime Σ)
(31)
In (31) the added may and must transitions are all self-loopsThe weak extension of C written CuArrΣprime
is defined using thesame formulas with the only following modification
CuArrΣprime
=
mustuArrΣprime= must
(32)
Observe that the strong extension uses the classical inverseprojection everywhere The weak extension however proceedsdifferently with the must transitions in that it forbids the legalenvironments to submit additional actions as its outputs
Using weak and strong alphabet equalization the relationsand operations introduced in Section VIII-C extend to variablealphabets as indicated now In the following formulas (ΣΣprime)is a pair such that Σ sube Σprime and (Σ1Σ2Σ) denotes a triplesuch that Σ = Σ1 cup Σ2 and satisfying the typing constraints
Σini = Σin cap Σi and Σout
i = Σout cap Σi for i = 1 2
It is understood that contract C has alphabet Σ and so on
Theorem 1 The following relations and operators
M prime |=M C = M prime |=M CuArrΣprime
Eprime |=E C = Eprime |=E CuarrΣprime
C1 C2 = C1 CuArrΣ2
C1 and C2 = CuArrΣ1 and CuArrΣ
2
C1 otimes C2 = CuarrΣ1 otimes CuarrΣ2
C1C2 = CuArrΣ1 CuarrΣ2
(33)
instantiate the meta-theory
Proof The first two formulas just provide definitions so noproof is needed for them Their purpose is to characterizethe weakly and strongly extended Modal Interfaces in termsof their sets of environments and implementations For bothextensions allowed output actions of the implementations areaugmented whereas mandatory actions are not For the weakextension legal environments are not modified in that noadditional output action is allowed for them In contrast for thestrong extension legal environments are allowed to submit anyadditional output action These observations justify the otherformulas 2
E Projecting and Restricting
A difficult step in the management of contracts was illus-trated in Figure 4 of Section IV-D It consists in decomposinga contract C into a composition of sub-contractsotimes
iisinI Ci C (34)
where sub-contract Ci has alphabet Σi = Σini ] Σout
i As aprerequisite to (34) the designer has to guess some topologicalarchitecture by decomposing the alphabet of actions of C as
Σ =⋃iisinI Σi Σi = Σin
i ] Σouti (35)
such that composability conditions regarding inputs and out-puts hold Guessing architectural decomposition (35) relies onthe designerrsquos understanding of the system and how it shouldnaturally decomposemdashthis typically is the world of SysMLFinding decomposition (34) is however technically difficultin that it involves behaviors It is particularly difficult if Cis itself a conjunction of viewpoints or requirements whichtypically occurs in requirements engineering see Section XI
C =andkisinK Ck (36)
The algorithmic means we develop in the remaining part ofthis section will be instrumental in solving (34) They will beused in the Parking Garage example of Section XI
Projecting over a subalphabet Projecting a contract overa sub-alphabet is the first natural tool for consideration Itis the dual operation with respect to alphabet extension thatwas developed in Section VIII-D Two projections can bedefined which can be seen as under- and over-approximationsrespectively by referring to the refinement order
RR ndeg 8147
Contracts for System Design 39
Let C be a Modal Interface with alphabet Σ = Σin cup Σout
and let Σprime sub Σ be a sub-alphabet Define respectively theabstracted projection and refined projection
CdarrΣprime= min Cprime | ΣCprime = Σprime and Cprime C
CdArrΣprime= max Cprime | ΣCprime = Σprime and Cprime C
(37)
where ldquominrdquo and ldquomaxrdquo refer to refinement order for ModalInterfaces with different alphabets see (33) The projectionCdArrΣprime
(respectively CdarrΣprime) is computed via the following on-
the-fly algorithm 1) Perform ε-closure on the set of states byconsidering unobservable the actions not belonging to Σprime andthen 2) Perform determinization by giving priority to mustover may (respectively to may over must) see Table VI fordetails Step 2) of the procedure for computing CdArrΣprime
is apossible source of inconsistencies
The abstracted projection CdarrΣprimeprovides a projected view
of a system-level contract over a small subset of actionsThe abstracted projection is thus a useful tool for contractexploration and debug It is not a synthesis tool however
This is in contrast to the refined projection CdArrΣprime which
satisfies the following result For any finite set Ci | i isin Iof Modal Interfaces with respective alphabets Σi we haveassuming that the left and right hand sides are properlydefinedmdasha typing property on input and output alphabetsotimes
iisinI
[Ci and
(andkisinK C
dArrΣi
k
)]
andkisinK Ck (38)
To show this by symmetry it is enough to show (38) withthe conjunction on the right hand side replaced by any singleCk for k selected from finite set K For any i isin I we haveCdArrΣi
k Ck and thus
Cprimei =def
[Ci and
(andkisinK C
dArrΣi
k
)] Ck (39)
holds for every i from which (38) follows Unfortunately therefined projection quite often gives raise to inconsistenciesIn addition the contract composition arising in left hand sideof (38) is subject to incompatibilities Informally said thistechnique works if the sub-systems are only ldquoloosely coupledrdquoso that neither inconsistencies nor incompatibilities occur Tomitigate this problem we propose an alternative technique forturning a conjunction into a composition
Restricting to a sub-alphabet Let C be a Modal Interfacewith alphabet Σ = Σin cup Σout and let (ΣprimeinΣprimeout) be twoinput and output sub-alphabets such that Σprimeout sube Σout SetΣprime = Σprimein]Σprimeout and define the restriction of C to Σprime denotedby CdarrΣprime via the procedure shown in see Table VII comparewith Table VI Observe that the states of the restriction cor-respond to sets of states of the original Modal Interface Therestriction aims at avoiding incompatibilities when consideringthe composition as the following lemma shows
Lemma 11 If C and CdarrΣprime are both consistent then so istheir compatible quotient CCdarrΣprime see Definition 12Proof Consider two alphabets Σ supe Σprime and a consistent C onalphabet Σ such that CdarrΣprime is also consistent The only casewhere quotient produces inconsistent states is whenever there
input CΣΣprime output Cprime
let proj(OpX) =if X has not been visitedthen
1 mark X visited2 for every α isin Σprime do
21 let Y = ε-closure(Σminus Σprime next(αX))22 let m = OpmC(q α) | q isin X23 add to Cprime a transition (Xα Y ) with modality m24 proj(Op Y )
done
let project(Op C) =1 let X0 = ε-closure(Σminus Σprime q0)2 set initial state of Cprime to X0
3 proj(OpX0)4 reduce Cprime5 return Cprime
let order (cannot maymustle) =
must le may
cannot le may
in CdarrΣprime= project(or C)
CdArrΣprime= project(and C)
Table VIALGORITHM FOR COMPUTING THE PROJECTIONS (37)
input CΣinΣoutΣprimeinΣprimeout output Cprime
let order(cannot maymustlein) = cannot lein may lein must
order(cannot maymustleout) =
must le may
cannot le mayin let rest(X) =
if X has not been visitedthen
1 mark X visited2 for every α isin Σprime do
21 let Y = ε-closure(Σminus Σprime next(αX))22 let m = OpmC(q α) | q isin X
where Op = if α isin Σprimein then orin else andout
23 add to Cprime a transition (Xα Y ) with modality m24 rest(Op Y )
done
let restrict(C) =1 let X0 = ε-closure(Σminus Σprime q0)2 set initial state of Cprime to X0
3 rest(OpX0)4 reduce Cprime5 return Cprime
Table VIIALGORITHM FOR COMPUTING THE RESTRICTION CdarrΣprime
exists an action e and a state pair (qR) in CCdarrΣprime such thate has modality must in q and does not have modality mustin R We prove by contradiction that no such reachable statepair (qR) and action e exist Remark that by definition of therestriction q isin R The restriction is assumed to be in reducedform meaning that it does not contain inconsistent states Twocases have to be considered
1) Action e has modality cannot in R Several sub-caseshave to be considered depending on the IO status ofe and on the fact that the reduction of the restrictionhas turned a may modality for e into a cannot In allcases action e has modality cannot or may in q which
RR ndeg 8147
Contracts for System Design 40
contradicts the assumption2) Action e has modality may in R This implies that e also
has modality may in q which contradicts the assumptionThis finishes the proof of the lemma 2
The following holds by Lemma 10
CdarrΣprime otimes (CCdarrΣprime ) CCCdarrΣprime has no inconsistent state
(CdarrΣprime CCdarrΣprime ) has no incompatible pair of states(40)
By Lemma 11 the only property for checking is the consis-tency of CdarrΣprime This is a significant improvement comparedto the issues raised by the refined projection as explained inthe paragraph following (39) Decomposition (40) can be usedwhile sub-contracting through the following algorithm
Algorithm 1 We are given some system-level contract CThe top-level designer guesses some topological architectureaccording to (35) Then she recursively decomposes
C = C0 C0darrΣ1otimes C1
C0darrΣ1otimes C1darrΣ2
otimes C2 C0darrΣ1
otimes otimes Cnminus1darrΣn
=def C(Σ1) otimes otimes C(Σn)
(41)
which ultimately yields a refinement of C by a compatiblecomposition of local sub-contracts 2
Discussion The operations of projection and restrictionthat we introduced here can probably be made be genericat the level of the meta-theory Observe however that suchoperations explicitly refer to the notion of sub-alphabet whichdoes not exist at the level of the meta-theory In additionModal Interfaces are the only concrete theory in which variablealphabets are properly supported For these two reasons wepreferred to develop these operations for Modal Interfacesonly
F Observers
Here we develop observers for a Modal InterfaceC = (ΣinΣout Q q0rarr 99K) having no inconsistent statemeaning that rarrsube99K With this consistency assumption inforce observers are then obtained as follows with referenceto Definition 2bull Condition 2 of Definition 7 boils down to requiring thatE times Cmust simulates E Simulation testing can thus beused to check this call bE
C(E) the corresponding verdictbull To test for implementations we first construct the max-
imal environment EC and apply testing to check sim-ulation of EC times M by Cmay call bM
C1 the corre-sponding verdict Performing this requires maintainingpairs of states ((qE qM ) (qE q)) in simulation relation(qE qM )le(qE q) For any such pair of states let bM
C2 de-note the verdict answering whether (qE qM )
αminusrarrECtimesMholds each time q αminusrarr holds for any α isin Σout Theoverall verdict for implementation testing is then
bMC1(EC timesM) and bM
C2(EC timesM)
Lemma 3 for generic observers specializes to the followingeffective semi-decision procedure
Lemma 121) If bE
C outputs F then C is incompatible2) If bM
C1 and bMC2 outputs F then C is inconsistent
G Bibliographical note
As explained in [72] [56] [127] [83] [165] [166] Inter-face Theories make no explicit distinction between assump-tions and guarantees
Interface Automata variants and extensions InterfaceAutomata were proposed by de Alfaro and Henzinger [72][70] [5] [54] as a candidate theory of interfaces In thesereferences Interface Automata focused primarily on parallelcomposition and compatibility Quoting [72]
ldquoTwo interfaces can be composed and are compatibleif there is at least one environment where they canwork togetherrdquo
The idea is that the resulting composition exposes as aninterface the needed information to ensure that incompatiblepairs of states cannot be reached This can be achieved byusing the possibility for a component to refuse selectedinputs from the environment at a given state [72] [56] Incontrast to our development in Section VIII-B no sets ofenvironments and implementations are formally associated toan Interface Automaton in the original developments of theconcept A refinement relation for Interface Automata wasdefined in [72]mdashwith the same definition as oursmdashit couldnot however be expressed in terms of sets of implementationsProperties of interfaces are described in game-based logicseg ATL [9] with a theoretical high-cost complexity Theoriginal semantics of an Interface Automaton was given by atwo-player game between an input player that represents theenvironment (the moves are the input actions) and an outputplayer that represents the component itself (the moves are theoutput actions) Despite the availability of partial results [83]the framework of Interface Automata lacks support for theconjunction of interfaces in a general setting and does notoffer the flexibility of modalities Sociable Interfaces [71]combine the approach presented in the previous paragraphwith interface automata [72] [73] by enabling communicationvia shared variables and actions45 First the same actioncan appear as a label of both input and output transitionsSecondly global variables do not belong to any specificinterface and can thus be updated by multiple interfaces Con-sequently communication and synchronization can be one-to-one one-to-many many-to-one and many-to-many Symbolicalgorithms for checking the compatibility and refinement ofsociable interfaces have been implemented in TICC [3]Software Interfaces were proposed in [55] as a pushdownextension of interface automata (which are finite state) Push-down interfaces are needed to model call-return stacks ofpossibly recursive software components This paper contains
45This formalism is thus not purely synchronous and is mentioned in thissection with a slight abuse
RR ndeg 8147
Contracts for System Design 41
also a comprehensive interface description of Tiny OS46 anoperating system for sensor networks Moore machines andrelated reactive synchronous formalisms are very well suitedto embedded systems modeling Extending interface theoriesto a reactive synchronous semantics is therefore meaningfulSeveral contributions have been made in this direction startingwith Moore and Bidirectional Interfaces [56] In Moore Inter-faces each variable is either an input or an output and thisstatus does not change in time Bidirectional Interfaces offeradded flexibility by allowing variables to change IO statusdepending on the local state of the interface Communicationby shared variable is thus supported and for instance allowsdistributed protocols or shared buses to be modeled In bothformalisms two interfaces are deemed compatible wheneverno variable is an output of both interfaces at the same timeand every legal valuation of the output variables of oneinterface satisfies the input predicate of the other The mainresult of the paper is that parallel composition of compatibleinterfaces is monotonic with respect to refinement Note thatMoore and Bidirectional Interfaces force a delay of at leastone transition between causally dependent input and outputvariables exactly like Moore machines In [83] the frame-work of Synchronous Interfaces is enriched with a notion ofconjunction (called shared refinement) This development wasfurther elaborated in [78] In Moore interfaces legal values ofthe input variables and consequent legal values of the outputvariables are not causally related Synchronous Relational In-terfaces [177] [178] have been proposed to capture functionalrelations between the inputs and the outputs associated toa component More precisely inputoutput relations betweenvariables are expressed as first-order logic formulas over theinput and output variables Two types of composition are thenconsidered connection and feedback Given two relationalinterfaces C1 and C2 the first one consists in connecting someof the output variables of C1 to some of the input variablesof C2 whereas feedback composition allows one to connectan output variable of an interface to one of its own inputsThe developed theory supports refinement compatibility andalso conjunction The recent work [112] studies conditions thatneed to be imposed on interface models in order to enforceindependent implementability with respect to conjunctionFinally [53] develops the concept of simulation distancesfor interfaces thereby taking robustness issues into accountby tolerating errors Finally Web services Interfaces wereproposed in [38]
The discussion of variants and extensions related to timeresources and probability is deferred to corresponding sec-tions
Modal Interfaces variants and extensions Propertiesexpressed as sets of traces can only specify what is forbiddenUnless time is explicitly invoked in such properties it isnot possible to express mandatory behaviors for designsModalities were proposed by Kim Larsen [130] [11] [46] asa simple and elegant framework to express both allowed and
46httpwwwtinyosnet
mandatory properties Modal Specifications basically consist inassigning a modality may or must to each possible transition ofa system They have been first studied in a process-algebraiccontext [130] [125] in order to allow for loose specificationsof systems Since then they have been considered for automata[128] and formal languages [163] [164] and applied to a widerange of application domains (see [11] for a complete survey)Informally a must transition is available in every componentthat realizes the modal specification while a may transitionneeds not be A modal specification thus represents a set ofmodelsmdashunfortunately models of modal transition systems areoften call ldquoimplementationsrdquo in the literature which is unfor-tunate in our context We prefer keeping the term ldquomodelrdquoand reserve the term ldquoimplementationrdquo for the entities intro-duced in Sections VIII-B and VIII-C Modal Specificationsoffer built-in conjunction of specifications [129] [167] Theexpressiveness of Modal Specifications has been characterizedas a strict fragment of the Hennessy-Milner logic in [46]and also as a strict fragment of the mu-calculus in [89] Theformalism is rich enough to specify safety properties as well asrestricted forms of liveness properties Modal Interfaces withthe right notion of compatibility were introduced in [165][166] and the problem of alphabet equalization with weakand strong alphabet extensions was first correctly addressed inthe same references In [23] compatibility notions for ModalInterfaces with the passing of internal actions are definedContrary to the approach reviewed before a pessimistic viewof compatibility is followed in [23] ie two Modal Interfacesare only compatible if incompatibility between two interfacescan occur in any environment A verification tool called MIOWorkbench is available The quotient of Modal Specificationswas studied in [124] [164] Determinism plays a role in themodal theory Non-deterministic Modal Interfaces have pos-sibly non-deterministic io-automata as class of componentsThey are much more difficult to study than deterministic onesand corresponding computational procedures are of highercomplexity A Modal Interface is said to be deterministic if itsmay-transition relation is deterministic For nondeterministicModal Interfaces modal refinement is incomplete [128] thereare nondeterministic Modal Interfaces C1 and C2 for whichthe set of implementations of C1 is included in that of C2without C1 being a modal refinement of C2 Hence refinementaccording to the meta-theory is not exactly instantiated butonly approximated in a sound way A decision procedure forimplementation inclusion of nondeterministic Modal Interfacesdoes exist but turns out to be EXPTIME-complete [12] [25]whereas the problem is PTIME-complete if determinism isassumed [167] [26] The benefits of the determinism assump-tion in terms of complexity for various decision problemson modal specifications is underlined in [26] The ldquomergerdquoof non-deterministic Modal Specifications regarded as partialmodels has been considered in [179] This operation consistsin looking for common refinements of initial specifications andis thus similar to the conjunction operation presented hereIn [179] [90] algorithms to compute the maximal commonrefinements (which are not unique when non-determinism is
RR ndeg 8147
Contracts for System Design 42
allowed) are proposed They are implemented in the toolMTSA [82] Assumeguarantee contracts viewed as pairs ofModal Specifications were proposed in [96] It thus com-bines the flexibility offered by the clean separation betweenassumptions and guarantees and the benefits of a modalframework Several operations are then studied refinementparallel composition conjunction and priority of aspects Thislast operation composes aspects in a hierarchical order suchthat in case of inconsistency an aspects of higher priorityoverrides a lower-priority contract The synthesis of ModalInterfaces from higher-level specifications has been studiedfor the case of scenarios In [173] Existential Live SequenceCharts are translated into Modal Specifications hence provid-ing a mean to specify modal contracts Regarding extensionsAcceptance Interfaces were proposed by J-B Raclet [163][164] Informally an Acceptance Interface consists of a set ofstates with for each state a set of ready sets where a readyset is a set of possible outgoing transitions from that stateIn intuitive terms an Acceptance Interface explicitly specifiesits set of possible models Acceptance Interfaces are moreexpressive than Modal Interfaces but at the price of a pro-hibitive complexity for the various relations and operators ofthe theory Modal Interfaces have been enhanced with markedstates by Caillaud and Raclet [27] Having marked statessignificantly improves expressiveness It is possible to specifythat some state must be reachable in any implementation whileleaving the particular path for reaching it unspecified As anexample of use Modal Interfaces with marked states have beenapplied in [4] to the separate compilation of multiple clockedsynchronous programs
The discussion of variants and extensions related to timeresources and probability is deferred to corresponding sec-tions
Features of our presentation The presentation of in-terface theories in this paper is new in many aspects Forthe first time all interface theories are clearly cast in theabstract framework of contracts following our meta-theory Inparticular the association to an interface C of the two sets ECandMC is new It clarifies a number of concepts In particularthe interface theories inherit from the properties of the meta-theory without the need for specific proofs The projectionand restriction operators for Modal Interfaces are new Castinginterface theories into the meta-theory was developed for thebasic interface theories only It would be useful to extend thisto the different variants and see what the benefit would beBenoicirct Caillaud has developed the MICA tool [49] whichimplements Modal Interfaces with all the operations andservices discussed in this section
IX PANORAMA TIMED INTERFACE THEORIES
In this section we develop an instance of an interface theoryfor timed systems This section is meant to be illustrative ofour approach to concrete instances of contract theories It doesnot claim to expose the good instance Our presentation buildson top of [35] To simplify the exposure we restrict ourselves
to the case of a fixed alphabet Σ As usual now we begin withthe component model
A Components as Event-Clock Automata
Timed Automata [6] constitute the basic model for systemsdealing with time and built on top of automata In wordstimed automata are automata enhanced with clocks Predicateson clocks guard both the states (also called ldquolocationsrdquo) andthe transitions Actions are attached to transitions that resultin the resetting of some of the clocks
Event-Clock Automata [7] [8] [35] form a subclass oftimed automata where clock resets are not arbitrary eachaction α comes with a clock hα which is reset exactlywhen action α occurs The interest of this subclass is thatevent-clock automata are determinizable which facilitates thedevelopment of a (modal) theory of contracts The definitionof event-clock automata requires some prerequisites
We are given an underlying finite set H of clocks A clockvaluation is a map ν H 7rarr R+ where R+ denotes the set ofnonnegative reals The set of all clock valuations is denotedby V We denote by 0 the clock valuation assigning 0 to allclocks and by ν + t the clock obtained by augmenting ν withthe constant t For ν a valuation the valuation ν[0hα] assigns0 to hα and keeps the valuation of other clocks unchanged
Clocks can be used to define guards The class of guardsconsidered by [35] consists of finite conjunctions of expres-sions of the form h sim n where h is a clock n is an integerand sim is one of the following relations ltle=ge gt Forg a guard write ν |= g to mean that valuation ν satisfiesguard g For N an integer G(H N) denotes the set of allguards over H involving only integers n lt N + 1 and wewrite G(H) = G(Hinfin)
Definition 13 An event-clock automaton over alphabet Σis a tuple M = (ΣinΣout Q q0 Nrarr) wherebull ΣinΣout Q q0 are as for io-automata elements of Q
are called locationsbull HΣ = hα | α isin Σ is the set of clocksbull N is a finite integer and rarrsube Q times G(HΣ N) times Σ times Q
is the transition relation write qgαminusrarr qprime to mean that
(q g α qprime) isinrarr
The semantics of M is a timed transition system with infinitestate space QtimesV defined as follows transition q
gαminusrarr qprime canfire from state (q ν) isin Q times V iff ν |= g as a result of thisfiring the clock hα is reset to zero thus resulting in the newstate (qprime ν[0hα]) isin Q times V In our Timed Interface theorycomponents are event-clock automata that are
1) deterministic in the following sense
forall(q α ν) isin Qtimes Σtimes V there is at mostone transition q
gαminusrarr qprime such that ν |= g(42)
2) receptive meaning that
forallq isin Qforallα isin Σin qTαminusrarr
holds where T denotes the trivial guard ldquotruerdquo
RR ndeg 8147
Contracts for System Design 43
Instead of further developing our theory we will show how totake advantage of previously developed theories by showingthat event-clock automata are finitely encoded by means of re-gion automata that we introduce next Fix bound N A regionis an equivalence class ϑ of clock valuations ν satisfying thesame set of guards from G(H N) Denote by Θ the set of allsuch regions (bound N is understood) For ϑ isin Θ consider
τ(ϑ) = ϑprimeprime | existνprimeprime isin ϑprimeprimeexistν isin ϑexistt ge 0 st νprimeprime = ν + t
which is the set of all regions that can be obtained from ϑ byletting time elapse Finally for ϑ a region and α an actionϑdarrα is the region obtained from ϑ by resetting clock hα Usingthese notations we associate to each event-clock automatonM = (ΣinΣout Q q0 Nrarr) a Region Automaton which isthe following finite state automaton
R [M ] =(Σin timesΘΣout timesΘ QtimesΘ (q00)rArr
)(43)
where the transition relation rArr is given by
(q ϑ)ϑrdquoα
===rArr (qprime ϑprime) iff
q gαrarr qprime withϑrdquo sube τ(ϑ) cap g andϑprime = ϑrdquodarrα
(44)
Vice-versa any Region Automaton R defines a uniqueevent-clock automaton M [R] by deducing from (44) theminimal guards associated to its transitions Starting from anevent-clock automaton M M [R [M ]] is related to M by astrengthening of its guards However it holds that47
R [M [R [M ]]] = R [M ] (45)
Under the above correspondence components in theevent-clock automaton domain are mapped to components inthe io-automaton domain
B Modal Event-Clock Specifications
In this section we develop the framework of con-tracts on top of our component model of deterministicevent-clock automata To simplify we only develop the caseof a fixed alphabet Σ
Definition 14 A Modal Event-Clock Specification (MECS)is a tuple C = (ΣinΣout Q q0rarr 99K) where ΣinΣoutQ q0 are as in Interface Automata and
rarr sube 99K sube Qtimes G(HΣ)times ΣtimesQ
Using the same construction as above MECS C induces aRegion Modal Event-Clock Specification (RMECS) denoted byR [C] which is a Modal Interface according to Definition 7Accordingly R [C] defines a pair (ER[C]
MR[C]) of sets of
io-automata and we finally define
(EC MC ) =def
(M[ER[C]
]M[MR[C]
])The map C 7rarr R [C] satisfies48
R [M [R [C]]] = R [C] (46)
47It is shown in [35] that M 7rarr R [M ] forms a Galois connection48Again it is a Galois connection [35]
This allows us to lift the contract theory of RMECS (whichare Modal Interfaces) to a contract theory of MECS Whilethis is conceptually elegant it is not efficient since movingfrom MECS to RMECS (from timed models to region models)is ExpTime which is costly To cope with this difficulty theauthors of [35] have provided direct cheap formulas expressedin the MECS domain These formulas provide a partial answerto the issue of complexity In particular the following lemmaholds that was stated and proved in [35]
Lemma 13 For C1 and C2 two MECS having identical inputand output alphabets define C1andC2 symbolically with rules ofthe following form
Glbmay q1
g1α99K qprime1 and q2
g2α99K qprime2
(q1 q2)g1andg2α99K (qprime1 q
prime2)
Glbmustleft q1
g1αrarr qprime1 and q2g2α qprime2
(q1 q2)g1andg2αrarr (qprime1 q
prime2)
where denotes ad libitumrarr or 99K and with Glbmustright
defined symmetrically (see [35] for the complete set of rules)Then we have
R [C1andC2] = R [C1]andR [C2] (47)
Inconsistent states for both sides of (47) correspond A similarlemma holds for contract quotient C1C2 Unfortunately thepruning of inconsistent states cannot be performed directlyin the MECS domain and mapping to regions is mandatoryNevertheless dedicated rules to handle directly inconsistentstates exist in the symbolic versions of the different relationsand operations on MECS As a result the computation ofthe regions is only mandatory when the designer aims atcleaning its contract by pruning the inconsistencies A similarlemma holds for contract composition C1otimesC2 Again pruningincompatible pairs of states cannot be performed directly inthe MECS domain and mapping to regions is mandatory49
C Bibliographical note
This note focuses on interface types of framework Thereader is referrect to the bibliographical note of Section VII-Gfor extensions of AG-contracts addressing time
A first interface theory able to capture the timing aspectsof components is Timed Interfaces [74] Timed Interfacesallows specifying both the timing of the inputs a componentexpects from its environment and the timing of the outputsit can produce Compatibility of two timed interfaces is thendefined and refers to the existence of an environment such thattiming expectations can be met The Timed Interface theoryproposed in [68] fills a gap in the work introduced in [74]by defining a refinement operation In particular it is shownthat compatibility is preserved by refinement This theoryalso proposes a conjunction and a quotient operation and is
49Authors of [35] do not mention this fact for the following reason Theydo not consider the issue of receptiveness for components and therefore theissue of compatibility does not arise
RR ndeg 8147
Contracts for System Design 44
implemented in the tool ECDAR [69] Timed SpecificationTheories are revisited from a linear-time perspective in [60]
The first timed extension of modal transition systems waspublished in [52] It is essentially a timed (and modal) versionof the Calculus of Communicating Systems (by Milner) Basedon regions tool support for refinement checking were imple-mented and made available in the tool EPSILON [95] Anothertimed extension of Modal Specifications was proposed in [36]In this formalism transitions are equipped with a modality anda guard on the component clocks very much like in timedautomata For the subclass of modal event-clock automataan entire algebra with refinement conjunction product andquotient has been developed in [33] [34]
Resources other than time were also consideredmdashwithenergy as the main target Resource Interfaces [57] can beused to enrich a variety of interface formalisms (InterfaceAutomata [72] AssumeGuarantee Interfaces [73] etc) witha resource consumption aspect Based on a two player game-theoretic presentation of interfaces Resource Interfaces allowfor the quantitative specification of resource consumptionWith this formalism it is possible to decide whether compo-sitions of interfaces exceed a given resource usage thresholdwhile providing a service expressed either with Buumlchi condi-tions or thanks to quantitative rewards Because resource usageand rewards are explicit rather then being defined implicitlyas solutions of numerical constraints this formalism doesnot allow one to reason about the variability of resourceconsumption across a set of logically correct models
X PANORAMA PROBABILISTIC INTERFACE THEORIES
Probabilistic systems are non-deterministic systems inwhich choice is controlled by random trial Such systems areuseful for many purposes ranging from physical or biologicalsystems to security protocols intrusion detection and up tosafety and reliability analyses in system design In this sectionas another illustration of our meta-theory we develop a simpleinstance of a probabilistic interface theory Again to simplifythe exposure we restrict ourselves to the case of a fixedalphabet Σ
A Components as Probabilistic Automata
We first introduce Probabilistic Automata with inputs andoutputs also called InputOutput Markov Decision Processesand then we motivate their use in safety analysis
Definition 15 A Probabilistic Automaton with inputs andoutputs (io-PA) is a tuple M = (ΣinΣout Q q0Πrarr)wherebull Σin and Σout are disjoint finite input and output alpha-
bets such that Σin cup Σout = Σbull Q is a finite set of states and q0isinQ is the initial state
we denote by Π(Q) the finite set of all probabilities overQ also called the probabilistic states
bull rarr sube Qtimes ΣtimesΠ(Q) is the transition relation we writeq
αminusrarr π to mean (q α π) isinrarr and q αminusrarr if q αminusrarr πholds for some π
bull In addition we require M to be deterministic in thefollowing sense for any pair (q α) isin Q times Σ q αminusrarr πand q αminusrarr πprime implies π = πprime
A run σ of M starts from initial state q0 and then progressesby a sequence of steps of the form q
αminusrarr π 7rarr qprime wheresupplementary transitions π 7rarr qprime are drawn at random byselecting a successor state qprime isin Q according to probabilityπ A strategy consists in fixing a function ϕ Q rarr Σand using it to select the next action Once a strategy hasbeen fixed jumping from a probabilistic state to the next onegives raise to a time-invariant Markov Chain whose invariantprobability can be computed or statistically estimated Whenall probabilistic states are Dirac measures δqprime selecting qprime asa next state with probability one io-PA M boils down to anio-automaton Thus io-PA subsume io-automata
Two io-PA M1 and M2 are composable if Σout1 capΣout
2 = emptyTwo composable io-PA M1 and M2 compose into M = M1timesM2 as follows
(q1 q2)αminusrarrM π1 otimes π2 iff
q1
αminusrarrM1π1 and
q2αminusrarrM2
π2(48)
where otimes denotes the product of two probabilities thus makingthe two components independent Parallel composition definedin this way has all the desired properties
Similarly the concept of simulation relation is easily de-rived from that of io-automata by preserving probabilitiesfor Mi i = 1 2 two io-PA and two states qi isin Qi say that q1
simulates q2 written q2le q1 if there exists a surjective mapf Q1 7rarr Q2 such that
forallα st q2αminusrarr2 π2 existπ1 isin Π(Q1)
dArr (49) q1αminusrarr1 π1
π2(qprime2) =sumf(qprime1)=qprime2
π1(qprime1)
π1(qprime1) gt 0rArr f(qprime1) le qprime1
Observe that since we consider only deterministic io-PAthere exists at most one π2 such that q2
αminusrarr2 π2 hence thereis no need to quantify over π2 in the precondition of (49) Inprobability theory relation π2(qprime2) =
sumf(qprime1)=qprime2
π1(qprime1) writesπ2 = f(π1) Say that M1 simulates M2 written M2leM1 ifq20leq10 Simulation relation is preserved by composition IfM2leM1 then every strategy ϕ2 Q2 7rarr Σ2 defined over M2
has its counterpart into a matching strategy ϕ1 Q1 7rarr Σ1
over M1 by setting ϕ1(q1) = ϕ2(f(q1)) For i = 1 2 letΩi = QN
i be the set of all sequences of states of Qi and let(ΩiPi) i = 1 2 be the two resulting probability spaces whenmatching strategies are used for M1 and M2 Then the mapf induces a measurable map ψ = (f f ) Ω1 7rarr Ω2 suchthat
intZ(ω2)dP2(ω2) =
intZ(ψ(ω1))dP1(ω1) In particular
the probability distributions with respect to P1 and P2 of anymeasurable function depending only on the successive actionsperformed are identical
The natural use of io-PAs for safetyreliability analysis isto capture faulty situations through states Component states
RR ndeg 8147
Contracts for System Design 45
are partitioned into safe states and faulty states that can beequipped with different fault labels (names of states can dothis no semantic adaptation is needed) The probabilistic partof io-PAs naturally captures the spontaneous occurrence offaults When in a faulty state a component outputs actionsthat can either be used to model fault propagation or maybe alarms for use in system supervision Input actions in afaulty state can be used to either model denial of servicefrom other components (thus resulting in a risk of movingto a faulty state) or may be reconfiguration actions Thusspontaneous occurrence of failures with fault propagation iscaptured by this framework To summarize io-PAs offer anatural framework in which to combine functional and safetyviewpoints
B Simple Modal Probabilistic Interfaces
By following the same steps as for Modal Interfacessee Definition 7 we can define Simple Modal ProbabilisticInterfaces as pairs C = (Cmay Cmust) of io-PAs There is nonew difficulty in doing this Expressiveness of this frameworkhowever is modest whence the attribute ldquosimplerdquo When usedin the context of safetyreliability analysis Simple ModalProbabilistic Interfaces support the specification of fault ac-commodation in systems For example one can specify abouta componentbull that it does not accommodate denial of service inputs
representing fault propagation are disallowed (ldquomust notoccurrdquo)
bull that it must be prepared to possible denial of serviceinputs representing fault propagation are allowed (ldquomustbe acceptedrdquo)
bull that it never generates spontaneous failures actions lead-ing to a probabilistic state from which a faulty state can beimmediately reached are disallowed (ldquomust not occurrdquo)
bull that spontaneous failures are unavoidable actions leadingto a probabilistic state from which a faulty state can beimmediately reached are allowed (ldquomust be acceptedrdquo)
One could argue that io-PA by themselves offer a similarexpressiveness by playing with probabilities Simple ModalProbabilistic Interfaces however offer the full algebra ofcontracts which io-PA donrsquot
C Bibliographical note
This note focuses on interface types of framework Thereader is referred to the bibliographical note of Section VII-Gfor extensions of AG-contracts addressing probability
Exactly like the Interval Markov Chain (IMC) for-malism [116] they generalize Constraint Markov Chains(CMC) [50] are abstractions of a (possibly infinite) sets ofDiscrete Time Markov Chains Instead of assigning a fixedprobability to each transition transition probabilities are keptsymbolic and defined as solutions of a set of first orderformulas Variability across implementations is made possiblenot only with symbolic transition probabilities but also thanksto the labelling of each state by a set of valuations or setsof atomic propositions This allows CMCs to be composed
thanks to a conjunction and a product operators While theexistence of a residuation operator remains an open problemCMCs form an interface theory in which satisfaction andrefinement are decidable and compositions can be computedusing quantifier elimination algorithms In particular CMCswith polynomial constraints form the least class of CMCsclosed under all composition operators Abstract ProbabilisticAutomata (APA) [79] is another specification algebra withsatisfaction and refinement relations product and conjunctioncomposition operators Despite the fact that APAs generalizeCMCs by introducing a labeled modal transition relationdeterministic APAs and CMCs coincide under the mild as-sumption that states are labeled by a single valuation Forboth formalisms parallel composition is restricted to non-interacting components since alphabets of actions must bedisjoint
Our formalism of Simple Modal Probabilistic Interfaces ex-hibits the whole contract algebra Regarding limitations unlikeIMC CMC and APA this model does not allow for specifyingfamilies of transition probabilities and hence it cannot helpfor quantitative reasoning about reliability analysis
XI THE PARKING GARAGE AN EXAMPLE INREQUIREMENTS ENGINEERING
In this section we develop the parking garage exampleintroduced in Section IV-C Some of the material is repeatedfor better readability Despite being simple and small this ex-ample quickly becomes complex for reasons that are intrinsicto the formal management of requirements The MICA tooldeveloped by Benoicirct Caillaud was used to develop it [49]
Requirements are written in constrained English languageand then translated into Modal Interfacesmdashwhile the pre-sented translation is manual automatic translation can beenvisioned50 Once this is completed contracts are formallydefined and the apparatus of contracts can be used In par-ticular important properties regarding certification can beformally defined and checked eg consistency compatibilitycorrectness and completeness In addition support is providedfor turning top-level requirements into an architecture of sub-systems each one equipped with its own requirements Thelatter can then be submitted to independent suppliers forfurther development
A The contract framework
We shall use Modal Interfaces (with variable alphabet) asdeveloped in Sections VIII-C and subsequent ones There arethree main reasons for this choice
1) By offering the may and must modalities Modal Inter-faces are well suited to express mandatory and optionalbehaviors in the specification which we consider impor-tant for requirements engineering
50In fact the contract specification languages proposed in the projectsSPEEDS [29] and CESAR (httpwwwcesarprojecteu) are examples oftranslations from a constrained English language to a formal models ofcontracts similar to Modal Interfaces
RR ndeg 8147
Contracts for System Design 46
2) Being large sets of requirements structured into chaptersrequirements documents are a very fragmented style ofspecification Only Modal Interfaces offer the neededsupport for an accurate translation of concepts such asldquoset of requirementsrdquo ldquoset of chaptersrdquo together with aqualification of who is responsible for each requirement(the considered component or sub-system versus itsenvironment)
3) As we shall see at the top-level conjunction prevailsHowever as soon as the designer refines the top-levelrequirements into an architecture of sub-systems com-position enters the game Turning a conjunction of top-level requirements into a composition of sub-systemsspecifications thus becomes a central task Only ModalInterfaces provide significant assistance for this
Overall the problem considered in claim 3) can be stated asfollows The designer begins with some system-level contractC which is typically specified as a conjunction of viewpointsandor requirements The designer guesses some topologicalarchitecture by decomposing the alphabet of actions of C as
Σ =⋃iisinI Σi Σi = Σin
i ] Σouti (50)
such that composability conditions regarding inputs and out-puts hold Once this is done we expect our contract frameworkto provide help in generating a decomposition of C asotimes
iisinI Ci C (51)
where sub-contract Ci has alphabet Σi = Σini ] Σout
i Guess-ing architectural decomposition (50) relies on the designerrsquosunderstanding of the system and how it should naturallydecomposemdashthis typically is the world of SysML Findingdecomposition (51) is however technically difficult in that itinvolves behaviors The algorithmic means that were presentedin Section VIII-E provide the due answer In this ParkingGarage example we will use both the abstracted projectionand the restriction that were developed in that section
B Top level requirements
In this section we begin with the top-level requirementsThe system under specification is a parking garage subjectto payment by the user At its most abstract level the re-quirements document comprises the different chapters gatepayment and supervisor see Table VIII The gate chapterwill collect the generic requirements regarding entry and exitgates These generic requirements will then be specialized forentry and exit gates respectively
0
gate_close
1gate_opengate_close
vehicle_passgate_open
Figure 7 Requirement Rg1 specified as an io-automaton Prefix ldquordquoindicates an input and prefix ldquordquo indicates an output
gateRg1ldquovehicles shall not pass when gate is closedrdquo see Fig 7Rg2 after vehicle_pass vehicle_pass is forbiddenRg3 after gate_open gate_open is forbidden and
after gate_close gate_close is forbiddenpaymentsupervisor
Table VIIITHE TOP-LEVEL SPECIFICATION WITH CHAPTER gate EXPANDED
REQUIREMENTS WRITTEN IN italics ARE ASSUMPTIONS UNDER WHICHgate SHOULD OPERATE
Focus on the ldquogaterdquo chapter It consists of the three re-quirements shown on Table VIII Requirement Rg1 is bestdescribed by means of an io-automaton shown in Figure 7mdashwe provide an informal textual explanation for it betweenquotes51 The other two requirements are written using con-strained natural language which can be seen as a boilerplatestyle of specification Prefix ldquordquo indicates an input and prefixldquordquo indicates an output
The first two requirements are not under the responsibilityof the system since they rather concern the car driver Thus itdoes not make sense to include them as part of the guaranteesoffered by the system Should we remove them This wouldbe problematic If drivers behave the wrong way unexpectedthings can occur for sure The conclusion is that 1) we shouldkeep requirements Rg1 and Rg2 and 2) we should handlethem differently than Rg3 which is a guarantee offered by thesystem Indeed Rg1 and Rg2 are assumptions under whichthe gate operates as guaranteed In the sequel assumptions arewritten in italics
So far we have specified gate as a list of requirementsRequirement Rg1 specified as an io-automaton can be con-sidered formal Requirements Rg2 and Rg3 are formulatedin constrained natural language and are ready for subsequentformalization eg as io-automata Are we done Not yetWe need to give a formal meaning to what it means to havea collection of requirements and what it means to distinguishassumptions from guarantees The contract framework wedevelop next will provide support for this
C Formalizing requirements as contracts
We shall use Modal Interfaces (with variable alphabet) asdeveloped in Sections VIII-C and subsequent ones Thuswe first need to explain how the specification of ldquogaterdquo inTable VIII translates into Modal Interfaces
We first observe that each requirement Rgj of Table VIIIis a sentence that can be formalized as an io-automaton see
51 We take the convention that the variables of the resulting io-automatonare those mentioned in the text of the requirement Some adjustment is neededto this convention however as exemplified by Figure 7 Suppose that somerequirement says ldquogate_open never occursrdquo This is translated by havingno mention of gate_open in the corresponding io-automaton To expressthis ldquonegativerdquo fact we must keep track of the fact that gate_open belongsto the alphabet of actions of the io-automaton Thus when performing thetranslation the explicit list of inputs and outputs should be explicitly givenTo avoid such additional notational burden we have cheated by omitting thisunless necessary
RR ndeg 8147
Contracts for System Design 47
Figure 7 for such a formalization of requirement Rg1 Ac-cordingly each chapter D = gatepaymentsupervisorof Table VIII is structured as a pair
D = ((A1 Am) (G1 Gn)) (52)
where the Ais (the assumptions) and the Gjs (the guarantees)are io-automata in which all involved actions possess thesame status (input or output) throughout all Ais and Gjs Thetranslation of a specification of the form (52) into a ModalInterface is performed by applying the following two series ofrules
Rules 1 We adopt the following rules for the translation ofguarantees (in the form of io-automata) into Modal InterfacesRG
1 Unless otherwise explicitly stated transitions labeledby an output action of the considered system are givena may modality the rationale for doing this is that thedefault semantics for guarantees is ldquobest effortrdquo A mustmodality is assigned if the requirement specifies itmdashegby having a ldquomustrdquo in the sentence
RG2 Transitions labeled by an input action of the considered
system are given a must modality the rationale for doingthis is that as part of its guarantees the component mustnot refuse an input that is ldquolegallyrdquo submitted by theenvironment
RG3 Guarantees in a same requirements chapter D combine
by conjunctionApplying Rules 1 to the set of guarantees of D yields thecontract encoding these guarantees denoted by GD 2
Performing this for the single guarantee Rg3 of gate yieldsthe Modal Interface shown in Figure 8
0 1gate_opengate_close
0 1gate_opengate_close
Figure 8 Translating the guarantee Rg3 of gate as an io-automaton (top)and then as a Modal Interface Ggate (bottom) using Rules 1
Rules 2 We adopt the following rules for the translationof assumptions (in the form of io-automata) into ModalInterfacesRA
1 We exchange the status inputoutput in every assump-tion thus taking the point of view of the environment
RA2 Having done this we apply Rules 1 to the assumptions
So far this yields a draft Modal Interface A that must besatisfied by every environment
RA3 This is not enough however as we really want envi-
ronments that submit all legal stimuli To ensure this wesimply turn in A all may transitions to must transitionswhich yields A
Applying Rules 2 to the set of assumptions of D yields theModal Interface AD encoding these assumptions 2
Performing this for the assumptions Rg1 and Rg2 of gateyields the Modal Interface shown in Figure 9
1 0
gate_close
1gate_opengate_close
gate_openvehicle_pass
2 0
gate_open
1vehicle_passgate_open
3 (11)
gate_close
(10)
gate_opengate_closevehicle_pass
gate_open
4 0
gate_close
1gate_openvehicle_passgate_close
gate_open
Figure 9 Translating the assumptions of gate as a Modal Interface Agate
using Rules 2 1 translation of Rg1 2 translation of Rg2 3 the resultingconjunction 4 the final result after applying rule RA
3 and renaming the states
So far we have represented any chapter D of the require-ments document as a pair of Modal Interfaces (AD GD) withmirroring inputoutput statuses for their actionsmdashevery inputof AD is an output of GD and vice-versa It is the merit ofModal Interfaces to allow for a direct representation of thispair of assumption and guarantee in the form of a single ModalInterface by using the following formula for A and G twoModal Interfaces with mirroring inputoutput statuses for theiractions
(AG) is represented by the quotient (AotimesG)A (53)
which is the contract characterizing the components thatimplement G in the context of A see Section V-E Performingthis for the whole chapter gate yields the Modal Interfaceshown in Figure 10 Some comments are in order regardingthis Modal Interfacebull Regarding the guarantees offered by the component
Allowed outputs possess a may modality which reflectsthat Guarantees specify what the component may deliverOther actions are forbidden
bull Regarding the context of operation Legal inputs to thegate (eg vehicle_through when exiting state ldquo1rdquo) havea must modality This complies with the intuition that
RR ndeg 8147
Contracts for System Design 48
gate(x) where x isinentry exitRg1(x) ldquovehicles shall not pass when x_gate is closedrdquo see Fig 7Rg2(x) after vehicle_pass vehicle_pass is forbiddenRg3 after x_gate_open x_gate_open is forbidden and after x_gate_close x_gate_close is forbidden
paymentRp1 ldquouser inserts a coin every time a ticket is inserted and only thenrdquo Fig omittedRp2 ldquouser may insert a ticket only initially or after an exit ticket has been issuedrdquo Fig omittedRp3 ldquoexit ticket is issued after ticket is inserted and payment is made and only thenrdquo Fig omitted
supervisorRg1(entry)Rg1(exit)Rg2(entry)Rg2(exit)Rs1 initially and after entry_gate close entry_gate open is forbiddenRs2 after ticket_issued entry_gate open must be enabledRs3 ldquoat most one ticket is issued per vehicle entering the parking and tickets can be issued only if requested
and ticket is issued only if the parking is not fullrdquo see Fig 12Rs4 ldquowhen the entry gate is closed the entry gate may not open unless a ticket has been issuedrdquo Fig omittedRs5 ldquothe entry gate must open when a ticket is issuedrdquo Fig omittedRs6 ldquoexit gate must open after an exit ticket is inserted and only thenrdquo Fig omittedRs7 ldquoexit gate closes only after vehicle has exited parkingrdquo Fig omitted
Table IXREQUIREMENTS FOR THE TOP-LEVEL
0
1vehicle_pass
2gate_open
vehicle_passgate_closegate_open
gate_close3vehicle_pass
gate_close
vehicle_pass
Figure 10 Chapter gate of the top-level requirements document translatedinto a Modal Interface Cgate
the component should not refuse legal stimuli from itsenvironment Violation of the contract by its environmentoccurs when an illegal input is submitted by the environ-ment (vehicle_through when exiting state 0 or state 3) Asa consequence the whole contract gets relaxed which isreflected by the move to the special state ldquo2rdquo from whichany action is allowedmdashsuch a state is often called a ldquotoprdquostate Note that this top state resulted from computing thequotient
The same procedure applies to all chapters gate paymentand supervisor of the top-level textual specification shownin Table IX (it is an expansion of Table VIII) In particu-lar the Modal Interfaces encoding chapters payment andsupervisor of the top-level are displayed in Figures 11 to 13Figure 13 showing the contract associated to the supervisor isunreadable and the reader may wonder why we decided to putit here We indeed wanted to show that when contract designis performed formally and carefully top-level contracts rapidlybecome complex even for modest sets of requirements So theformal management of requirements and their translation intoformal contracts must be tool-assisted
Finally the whole top-level contract C is the conjunctionof the contracts representing chapters gate payment and
supervisor of the top-level requirements document
C = Cgate and Cpayment and Csupervisor (54)
Owing to the complexity of Csupervisor shown in Figure 13we do not show the Modal Interface C formalizing the fulldocument Nevertheless the latter was generated and can thenbe exploited as we develop next The above specificationonly covers the functional viewpoint of the system Otherviewpoints might be of interest as well eg regarding timingbehavior and energy consumption They would be developedwith the same method and combined to the above contract Cusing conjunction
D Sub-contracting to suppliers
In this section we apply the technique developed in Sec-tion VIII-E for generating an architecture of sub-systems withtheir associated sets of requirements Each sub-system canthen be submitted for independent development to a differentsupplier
The duty of the designer is to specify an architecture ldquoagravela SysMLrdquo as shown on Figure 14 Some comments arein order regarding this architecture The considered instanceof a parking garage consists of one entry gate one exitgate and one payment machine Compare with the top-levelspecification of Table IX The latter comprises a generic gatea payment machine and a supervisor each one with its setof requirements In contrast the architecture of Figure 14involves no supervisor The supervisor is meant to be dis-tributed among the two gates The architecture of Figure 14seems to be very loosely coupled First the PaymentMachineseems to be totally independent In fact the ticket that isinserted in the exit gate must coincide with the one issued bythe PaymentMachine It turns out that this reflects a missingassumption regarding the environment of the system (namelythe user of the parking) Then the two gates seem to have the
RR ndeg 8147
Contracts for System Design 49
0 1ticket_insert_payment 2
coin_insert_paymentticket_insert_payment
3
coin_insert_payment
ticket_insert_paymentcoin_insert_paymentexit_ticket_issue
exit_ticket_issueticket_insert_paymentcoin_insert_payment
Figure 11 Chapter payment of the top-level requirements documenttranslated into a Modal Interface Cpayment
(a0)
vehicle_exit (b0)request_enter
(a1)vehicle_enter
request_entervehicle_exit
ticket_issue
vehicle_enter
vehicle_exit(b1)
request_enter
(a2)
vehicle_enter
vehicle_exitticket_issuerequest_enter
vehicle_enter
vehicle_exit
vehicle_enter
(b2)request_enter
vehicle_exit
vehicle_enter
request_enter
Figure 12 Modal Interface for Rs3
0
entry_gate_close
1
exit_ticket_insert
7
vehicle_entervehicle_exit
44
request_enter
entry_gate_closeexit_ticket_insert
2
exit_gate_open
vehicle_entervehicle_exit
43
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
3
request_enter
vehicle_enter
75
vehicle_exit
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
4
ticket_issue
vehicle_enter
72
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
vehicle_enter
5
vehicle_exit
11
entry_gate_open
exit_gate_openexit_ticket_insertexit_gate_closeentry_gate_closevehicle_enterentry_gate_openvehicle_exitrequest_enter
ticket_issue
vehicle_entervehicle_exit
exit_ticket_insertrequest_enter
6
exit_gate_open
8
exit_gate_close
59
entry_gate_open
vehicle_enter
vehicle_exit exit_ticket_insertrequest_enter
exit_gate_open
exit_gate_close
58
entry_gate_open
vehicle_entervehicle_exit
request_enter
9
exit_ticket_insert
45
entry_gate_open
exit_gate_open
vehicle_entervehicle_exitexit_ticket_insert
request_enter
10
entry_gate_open
vehicle_exit
entry_gate_openexit_ticket_insertrequest_enter
exit_gate_open
entry_gate_close
47
ticket_issue
68
vehicle_enter
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insertrequest_enter
12
ticket_issue
69
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
49
vehicle_enter
13
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
19
request_enter
77
entry_gate_open
50
vehicle_exit
vehicle_enter
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
20
entry_gate_open
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
21
ticket_issue
34
vehicle_enter
71
entry_gate_close
vehicle_exit
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
22
vehicle_enter
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
23request_enter
84
entry_gate_open
127
vehicle_exit
vehicle_enter
exit_ticket_insertrequest_enter
exit_gate_open
24
vehicle_exit
33
entry_gate_open
vehicle_entervehicle_exit
exit_ticket_insertrequest_enter
16
exit_gate_open
17
exit_gate_close
25
entry_gate_open
vehicle_enter
vehicle_exit
exit_gate_openexit_ticket_insertrequest_enter
exit_gate_close
26
entry_gate_open
vehicle_entervehicle_exit
request_enter
18
exit_ticket_insert
114
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
80
entry_gate_open
vehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
81ticket_issue
79
entry_gate_close
99
vehicle_enter
vehicle_exit
exit_gate_open
entry_gate_open
exit_ticket_insertrequest_enter
82vehicle_enter
vehicle_entervehicle_exitexit_gate_open
exit_ticket_insert
31
request_enter
83
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
32
entry_gate_open
vehicle_exitexit_ticket_insertrequest_enter
entry_gate_open
exit_gate_open
vehicle_enter
91
entry_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
vehicle_enter
92
entry_gate_close
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
35
request_enter
101
entry_gate_close
entry_gate_open
60
vehicle_exit
vehicle_enter
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
36
vehicle_exit
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
37
exit_gate_open
125
exit_gate_close
93
entry_gate_close
entry_gate_open
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
exit_gate_open
38
vehicle_exit
exit_gate_close
94
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
39
exit_gate_open
40
exit_gate_close
entry_gate_close
entry_gate_open
vehicle_enter
ticket_issue
vehicle_exitexit_ticket_insertrequest_enter
exit_gate_open
exit_gate_close
entry_gate_open
73entry_gate_close
vehicle_entervehicle_exit
ticket_issue
request_enter
41
exit_ticket_insert
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
ticket_issue
entry_gate_open
exit_ticket_insertrequest_enter
42
exit_gate_open
entry_gate_close
entry_gate_close
ticket_issue
vehicle_enter
entry_gate_open
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
exit_gate_open vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
exit_ticket_insert
entry_gate_close
request_enterentry_gate_open
46
ticket_issue
124
vehicle_enter
vehicle_exit
entry_gate_open
request_enter
exit_ticket_insert
126
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
48
vehicle_enter
vehicle_entervehicle_exit
exit_gate_open
request_enterexit_ticket_insert
113
entry_gate_open
vehicle_exit
request_enter
exit_ticket_insertentry_gate_open
exit_gate_open
105
entry_gate_close
vehicle_enter
request_enter
vehicle_enter
exit_ticket_insert
entry_gate_openexit_gate_open
56
vehicle_exit
74entry_gate_close
vehicle_exit
exit_ticket_insertentry_gate_open
57
exit_gate_open
entry_gate_close
123
exit_gate_close
vehicle_enter
request_enter
vehicle_exit
exit_ticket_insert
entry_gate_openexit_gate_open
request_enter
76
entry_gate_close
exit_gate_close
61
vehicle_enter
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
14
ticket_issue
entry_gate_close
vehicle_enter
vehicle_exit
exit_gate_closeentry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
15
vehicle_enter
vehicle_exit
vehicle_enter
request_enter
exit_gate_openexit_ticket_insert
vehicle_exit
86
entry_gate_open
exit_gate_close
vehicle_entervehicle_exit
request_enter
entry_gate_openexit_ticket_insert
51
exit_gate_open
52
exit_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit
exit_ticket_insertexit_gate_open exit_gate_close
vehicle_entervehicle_exit
request_enter
53
exit_ticket_insert
entry_gate_open
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
54
exit_gate_open
67entry_gate_open
request_enter
vehicle_enter
vehicle_exit
exit_ticket_insertexit_gate_open
55
entry_gate_open
entry_gate_close
request_enter
vehicle_exit
exit_ticket_insert
entry_gate_openexit_gate_open
vehicle_enter
vehicle_enter
entry_gate_open
exit_ticket_insertexit_gate_open
70
request_enter
62
vehicle_exit
entry_gate_close
vehicle_enter
ticket_issue
entry_gate_open
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
entry_gate_close
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_exit
vehicle_entervehicle_exit
ticket_issue
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_close
exit_gate_open
vehicle_enter
ticket_issue
exit_gate_close
vehicle_exit exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
entry_gate_open
exit_ticket_insert
63
exit_gate_open
64exit_gate_close
entry_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit exit_ticket_insertexit_gate_open
exit_gate_close
entry_gate_close
entry_gate_close
vehicle_entervehicle_exit
request_enter
65
exit_ticket_insert
entry_gate_open
entry_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
66exit_gate_open
entry_gate_open
entry_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit
exit_ticket_insertexit_gate_open
entry_gate_close
vehicle_exit
request_enter
exit_gate_open
exit_ticket_insertentry_gate_open
vehicle_enter
vehicle_entervehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insert
78
request_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
vehicle_enter
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
vehicle_exit
exit_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
exit_gate_close
vehicle_enter
request_enter
vehicle_exit
entry_gate_closeexit_gate_openexit_ticket_insert
entry_gate_close
vehicle_exit
request_enter
exit_ticket_insert
entry_gate_open
vehicle_enter
vehicle_entervehicle_exit
exit_ticket_insert
request_enter
104entry_gate_close
112entry_gate_open
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enter
95entry_gate_close
entry_gate_openvehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
exit_ticket_insert
entry_gate_close
request_enterentry_gate_open
115
ticket_issue
98
vehicle_enter
vehicle_exit
exit_ticket_insert
entry_gate_open
request_enter
116
vehicle_enter
vehicle_entervehicle_exit
exit_ticket_insert
30
request_enter
107
entry_gate_open
vehicle_entervehicle_exit
exit_ticket_insert
request_enter97
entry_gate_open
vehicle_exit
exit_ticket_insert
request_enterentry_gate_open
vehicle_enter
96entry_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
89
request_enter
106
entry_gate_closeentry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insert
90
request_enter
100
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
entry_gate_closeexit_ticket_insertrequest_enter
exit_gate_open
vehicle_enter
entry_gate_closeexit_gate_openexit_ticket_insertrequest_enter
vehicle_exit
vehicle_entervehicle_exit
ticket_issue
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_close
exit_gate_open
vehicle_enter
ticket_issue
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
vehicle_enter
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
102
vehicle_exit
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
103
exit_gate_open
exit_gate_close
vehicle_enter
vehicle_exit
request_enterexit_ticket_insert
entry_gate_closeexit_gate_open
exit_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
request_entervehicle_enter
entry_gate_closeexit_ticket_insertentry_gate_open
exit_gate_open
request_enter
vehicle_enter
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insert
85
vehicle_exit
vehicle_exit
entry_gate_close
entry_gate_openexit_ticket_insert
exit_gate_open
request_enter
117
vehicle_enter
exit_gate_close
vehicle_exit
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insert
request_enter
87
vehicle_enter
exit_gate_close
exit_gate_close
entry_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
27
ticket_issue
vehicle_enter
vehicle_exit
exit_gate_close
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
28
vehicle_enter
vehicle_exit
vehicle_enter
exit_gate_close
exit_ticket_insertexit_gate_open
29request_enter
111
entry_gate_open
vehicle_exit
vehicle_enter
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
exit_gate_open
109
entry_gate_open
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
vehicle_enter
108
entry_gate_close
vehicle_exit
vehicle_enter
exit_gate_close
exit_gate_openexit_ticket_insert
88
request_enter
vehicle_exit
110
entry_gate_close
entry_gate_open
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
exit_gate_close
entry_gate_close
vehicle_entervehicle_exit
entry_gate_open
exit_ticket_insert
request_enter
entry_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enterentry_gate_close
vehicle_enter
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
exit_gate_close
entry_gate_close
entry_gate_open
exit_ticket_insert
exit_gate_open
vehicle_enter
request_enter
vehicle_exit
exit_gate_close
entry_gate_close
entry_gate_open
exit_ticket_insertexit_gate_open
vehicle_enter
vehicle_exit
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
exit_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enter
entry_gate_close
vehicle_exit
request_enter
vehicle_enterentry_gate_close
exit_ticket_insert
entry_gate_openexit_gate_open
exit_gate_close
vehicle_exit
request_enter
vehicle_enter
exit_ticket_insert
entry_gate_close
entry_gate_open
vehicle_exit
exit_gate_close
entry_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
128ticket_issue
vehicle_enter
vehicle_exit
exit_gate_close
exit_gate_open
entry_gate_open
exit_ticket_insertrequest_enter
129vehicle_enter
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insert
130
request_enter
122entry_gate_open
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
120
entry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
vehicle_enter
119entry_gate_close
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insert
118
request_enter
121
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_gate_close
entry_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
exit_gate_closeexit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
exit_gate_open
exit_gate_close
request_enter
exit_ticket_insertentry_gate_close
vehicle_exit
exit_gate_open
exit_gate_close
request_enter
vehicle_enter
entry_gate_close
exit_ticket_insertentry_gate_open
vehicle_entervehicle_exit
request_enter
exit_gate_open
entry_gate_open
exit_ticket_insert
exit_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
entry_gate_open
vehicle_exit
exit_ticket_insert
request_enter
vehicle_enter
entry_gate_closeentry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
vehicle_enter
exit_ticket_insertrequest_enter
entry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
entry_gate_close
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_open
Figure 13 Chapter supervisor of the top-level requirements documenttranslated into a Modal Interface Csupervisor for a capacity of two for theparking garage
shared input ldquovehicle exitrdquo as their only interaction But thisshared input is involved in requirement Rs3 which forbidsthe entry if the parking is full
In Figure 15 we show the result of applying to the ar-chitecture of Figure 14 the Algorithm 1 developed in Sec-tion VIII-E which yields by construction a refinement of thetop-level contract C by a decomposition into local contracts
C C(ΣEntryGate)otimes C(ΣExitGate)otimes C(ΣPaymentMachine)
(55)
Local contract C(ΣEntryGate) is the more complex one becauseit involves countingmdashwe have assumed a capacity of two tokeep it simple Remarkably enough the decomposition (55)involves small sub-systems compared to Csupervisor (Fig 13)and the global contract C the restriction operation is to beacknowledged for this strong reduction in size
E The four ldquoCrdquo
Requirements capture and management are important mat-ters for discussion with certification bodies These bodieswould typically assess a number of quality criteria from egthe following list elaborated by INCOSE [114] AccuracyAffordability Boundedness Class Complexity Completeness
request enter
ticket issue
entry gate open
entry gate closeEntryGate
vehicle enter
vehicle exit
exit ticket insert ExitGateexit gate open
exit gate close
ticket insert payment
coin insert paymentPaymentMachine exit ticket issue
Figure 14 System architecture as specified by the designer
0
vehicle_exit
1
request_enter
3
vehicle_enter
request_entervehicle_exit
2ticket_issue
vehicle_enter
request_entervehicle_exit
vehicle_enter
4
entry_gate_open
entry_gate_closeentry_gate_open
ticket_issuevehicle_enterrequest_entervehicle_exit
entry_gate_close
request_entervehicle_exit
5vehicle_enter
vehicle_enter
6
request_enter
15
entry_gate_close
16
vehicle_exit vehicle_enter
request_enter
7
vehicle_exit
8
entry_gate_close
entry_gate_closevehicle_enter
request_entervehicle_exit
vehicle_exit
vehicle_enter
request_enter
9ticket_issue
vehicle_exit
vehicle_enter
request_enter
10
entry_gate_open
vehicle_exit
entry_gate_closerequest_enter
11
vehicle_enter
vehicle_enter
vehicle_exit12
request_enter
14entry_gate_close
vehicle_enter
vehicle_exit
request_enter
13entry_gate_close
vehicle_enter
vehicle_exit request_enter
vehicle_enter
request_enter
vehicle_exit
vehicle_exit
vehicle_enter
request_enter
entry_gate_close
vehicle_enter
request_entervehicle_exit
0 1exit_ticket_insert
4
vehicle_exit
exit_ticket_insert
2
exit_gate_open
vehicle_exit
exit_ticket_insert
3vehicle_exitexit_gate_close
exit_ticket_insertvehicle_exit
exit_ticket_insertexit_gate_close
vehicle_exitexit_gate_open
0 1ticket_insert_payment 2
coin_insert_paymentticket_insert_payment
3
coin_insert_payment
ticket_insert_paymentcoin_insert_paymentexit_ticket_issue
exit_ticket_issueticket_insert_paymentcoin_insert_payment
Figure 15 The three restrictions of the global contract C for the three sub-systems EntryGate (top) ExitGate (mid) and PaymentMachine (bottom)
Conciseness Conformance Consistency Correctness Criti-cality Level Orthogonality Priority Risk Unambiguousnessand Verifiability In this section we focus on four quality crite-ria that are considered central by certification authorities andare relevant to contracts namely Completeness CorrectnessConsistency and Compatibility
1) Consistency amp Compatibility Consistency and compat-ibility have been formally defined in the meta-theory seeSection V and Table IV therein In particular those formaldefinitions can be formally checked Thus the question ariseswhether these formal definitions suitably reflect the commonsense meaning of these terms
According to the common meaning a set of requirementsis consistent if it is not self-contradicting The intent is thatthere is no point in trying to implement an inconsistent set ofrequirements as no such implementation is going to exist
RR ndeg 8147
Contracts for System Design 50
It turns out that the existence of implementations is theformal definition of consistency according to the meta-theoryClearly the formal definition of consistency meets its commonsense interpretation We illustrate consistency on the top-levelspecification of Table IX Referring to this table we havestrengthened Rs6 and Rs7 in some way Lack of consistencyis revealed by checking the mutual consistency of these tworequirements with the requirement Rg3 applied to the exitgate After the following scenario
exit_ticket_insertexit_gate_openexit_ticket_insert
event exit_gate_open has modality must in left-hand interfaceand modality cannot in right-hand interface
According to the common meaning an architecture of sub-systems as characterized by their respective specifications iscompatible if these sub-systems ldquomatch togetherrdquo in that theycan be composed and the resulting system can interact withthe environment as expectedmdashuse cases can be operated aswished As explained in Table IV of Section V this is theformal definition of compatibility in the meta-theory Againthe formal definition of compatibility meets its common senseinterpretation
2) Correctness Correctness can only be defined withreference to another specification We propose to translateldquocorrectnessrdquo by one of the following properties dependingon the case (see Table IV for the notations)bull ldquois a correct implementation ofrdquo written |=Mbull ldquois a correct environment ofrdquo written |=Ebull ldquorefinesrdquo written
3) Completeness Completeness raises a difficulty Al-though the term ldquocompletenessrdquo speaks for itself it cannotbe formally defined what it means to be complete for a top-level specification in the form of a set of requirements Thereason is that we lack a reference against which completenesscould be checked Hence the only way to inspect a top-level specification for completeness is to explore it manuallyThe best help for doing this is to execute the specificationThus specifications must be executable Fortunately ModalInterfaces are executable and this way undesirable behaviorscan be revealed We illustrate this on the top-level specificationof Table IX where Rs6 is changed into ldquoexit gate must openafter an exit ticket is insertedrdquo (by omitting ldquoand only thenrdquo)Lack of completeness is revealed by simulation The followingscenario can occur
exit_ticket_insertexit_gate_openvehicle_exitexit_gate_closeexit_gate_open
which allows vehicles to exit without having inserted an exitticket an unwanted behavior This reveals that the specificationwas not tight enough ie incomplete So far for completenessof the top-level specification
In contrast completeness can be formally defined whena reference C is available We propose to say that Cprime isincomplete with reference to C if
1) Cprime does not refine C but2) there exists Cprimeprime Cprime such that Cprimeprime is consistent and
compatible and refines CThe rationale for this definition is that Cprime is not precise enoughbut can be made so by adding some more requirementsNote that Cprime is incomplete with reference to C if and onlyif Cprime and C is consistent and compatible This criterion is ofparticular relevance when Cprime =
otimesiisinI Ci is an architecture of
sub-contracts where Ci is to be submitted to supplier i forindependent development
F Discussion
Requirements engineering is considered very difficult Re-quirements are typically numerous and very difficult to struc-ture Requirements concern all aspects of the system func-tion performance energy reliabilitysafety Hence systemsengineers generally use several frameworks when expressingrequirements The framework of contracts expressed as ModalInterfaces that we have proposed here improves the situationin a number of aspectsbull It encompasses a large part of the requirements52
bull It can accommodate different concrete formalisms Inour example we have blend textual requirements withrequirements specified as state machines Richer for-malisms such as Stateflow diagrams can be accom-modated in combination with abstract interpretationtechniquesmdashthis is not developed here
bull We have shown how to offer formal support to importantproperties such as the four Crsquos during the process ofcertification
bull We have proposed a correct-by-construction approach tothe difficult step of moving from the top-level specifi-cation in the form of a requirements document to anarchitecture of sub-contracts for the suppliers53
XII CONTRACTS IN THE CONTEXT OF AUTOSAR
In this section we use AUTOSAR as an industrial exampleof how to leverage contracts within an existing standard toextend it
A The AUTOSAR context
AUTOSAR54 is a world-wide development partnership in-cluding almost all players in the automotive domain electronics
52 According to figures that were given to us by industrials 70-80 of therequirements can be expressed using the style we have developed here Otherrequirements typically involve physical characteristics of the system or definethe range for some parameters
53 The framework of AssumeGuarantee contracts that is used in Section XIIdoes not offer this for two reasons First it lacks the quotient and secondlocal alphabets are not properly handled In contrast AssumeGuarantee con-tracts are very permissive in how they can be expressed In particular dataflowdiagrams (Simulink) can be used to express assumptions and guarantees
54httpwwwautosarorg
RR ndeg 8147
Contracts for System Design 51
supply chain It has been created with the purpose of de-veloping an open industry standard for automotive softwarearchitectures To achieve the technical goals of modularityscalability transferability and reusability of functions AU-TOSAR provides a common software infrastructure based onstandardized interfaces for the different layers The AUTOSARproject has focused on the objectives of location indepen-dence standardization of interfaces and portability of codeWhile these goals are undoubtedly of paramount importancetheir achievement may not be sufficient for improving thequality of software systems As for most other embeddedsystem car electronics is characterized by functional as well asnon functional properties assumptions and constraints [111]Therefore an AUTOSAR based development process benefitsfrom adding contracts as the this section will demonstrate
B The contract framework
Extensive use of SimulinkStateflow modeling is performedfor system design in the automobile sector It is thus naturalto try reusing this modeling style for defining contractsSince AG contracts of Section VII simply rely on specify-ing assertions regardless of how they are actually describedwe use AG contracts for this AUTOSAR case study SinceSimulinkStateflow diagrams are very flexible contracts canbe expressed for all viewpoints (function timing safety) Inturn reasoning on such contracts is beyond the capability ofautomatic tools Consequently checking for implementationand refinement relations will be performed manually on smallmodels In contrast the powerful contract algebra developedin the meta-theory is fully generic and does not depend onthe nature and complexity of the considered models Themodularity it offers will thus be the main help offered bycontract based design in this case study As another featureof this this study the distinction between ldquohorizontalrdquo andldquoverticalrdquo contracts is used see Section IV-D4 Finally thefollowing variation of AG contracts is used
Assertions consist of a timed extension of the weaklysynchronous model (18) namely
P sube ((Σ 7rarr D) cup R+)lowast cup ((Σ 7rarr D) cup R+)
ω (56)
meaning that the assertion proceeds by a succession of stepsconsisting of either assignment of values to variables (includ-ing the special status absent for multiple-clocked assertions)or time progress Composition is by intersection P1timesP2 =def
P1 and P2 with alphabet equalization by inverse projection asin see Section VII-C Following Section VII-B componentsare tuples M = (ΣinΣout P ) where Σ = Σin cup Σout is thedecomposition of alphabet Σ into its inputs and outputs andP is an assertion following (56) Components must be free ofexception in the sense of Definition 4
A contract is a tuple C = (ΣinΣoutAs AwG) whereΣ = Σin cup Σout is the decomposition of alphabet Σ intoits inputs and outputs As and Aw the strong and weakassumptions and G the guarantees are assertions over ΣThe set EC of the legal environments for C collects all com-ponents E such that E sube A The set MC of all components
implementing C is defined by (As andAw)timesM sube G meaningthat implementations guarantee G under the condition that theenvironment satisfies the stronger condition AsandAw In otherwords in this framework legal environments are constrainedby strong assumptions only whereas the conjunction of strongand weak assumptions is required to guarantee G Weakassumptions are useful for design iterations in case strictobligations for the context of use may not be realizable
To conclude on this framework its difference is onlymethodological since any contract with strong and weakassumptions C = (ΣinΣoutAs AwG) is equivalent to anordinary AG contract (ΣinΣoutAsG or notAw) Thus thereader is referred to Section VII Adding time to the paradigmdoes not change anything to the relations or operators definedin that section
However adding time results in decidability and complexityissues The latter problem can be fixed in part by usingobservers see Sections V-G and VII Other proofs can be car-ried on manuallymdashthis is feasible for undecidable propertieswhen the needed reasoning only involves a small part of theanalyzed system involving few locally interacting componentsThe added value of our contract framework is to supportthe combination of proofs into a validation for the overallsystem taking into account detailed design decisions capturedin system and ECU configurations
C Exterior Light Management System
To illustrate the benefits of contract-based systems engineer-ing in AUTOSAR we consider as an example an excerpt of anExterior Light Management for an automobile55 We focus onthe parts responsible for sensing driver inputs and actuatingthe rear direction indicator lights and brake lights With thisexample we show how requirements can be refined to contractsand discuss the added value of contracts for negotiationsbetween OEM and suppliers We will also illustrate the useof vertical contracts eg to specify the expected latency ofthe communication solution and computations from the timingviewpoint and a failure hypothesis in terms of reliability
1) Function and timing We begin our study by showinghow AUTOSAR models can be enhanced with contracts
System
ext_pedal
ext_lamp
ext_tssext_wls
ext_rlaext_rra
Figure 16 Virtual Functional Bus model
The Virtual Functional Bus model Figure 16 shows the Vir-tual Functional Bus (VFB) model encompassing the exteriorlights management This software composition specifies the
55A case-study from the German SPES2020 project
RR ndeg 8147
Contracts for System Design 52
interfaces exposed by the component to the sensors deliveringdriver inputs (brake pedal warn light button turn signallever) and to the actuators controlling the lights Ports witharrowheads denote an asynchronous data flow interface whichis a SenderReceiverInterface Here it is a special kind calledServiceInterface which means the data is provided by somelocal service located in the BasicSoftware stack of an ECU(Electronic Computing Unit) The requirements document ofthe system contains one timing-related requirementbull R1 If the driver presses the brake pedal the brake lights
must light not later than 25msWe formalize in Table X this requirement as a contract by
using a pattern-based contract specification language (terms inbold-face are keywords)
CR1
As whenever ext_pedal occursext_pedal does not occur during[ext_pedalext_lamp]ext_pedal occurs sporadicwith minperiod 25ms
Aw trueG delay between ext_pedal and
ext_lamp within [0ms25ms]
Table XHORIZONTAL CONTRACT OF VFB MODEL
Indicator
BrakePedalSensor PedalToLamp
TurnSwitchSensor
WarnLightsSensor
SwitchLightActuator
RearLeftActuator
RearRightActuator
BrakeLampActuator
ext_pedal
pos_pedal_out lamp_intensity ext_lamp
ext_tss
ext_wls
tss
wls
ext_rla
ext_rra
rla_signalrra_signal
emcyBrake
pos_pedal_in
Figure 17 Decomposed Virtual Functional Bus model
Decomposed VFB Software composition Figure 17 showsthe decomposed VFB model AssemblySwConnectors link theports of parts of the composition and are subject to commu-nication refinement The components used in the compositionand their functions are as followsbull BrakePedalSensor receives the position of the brake pedal
(ext_pedal) and distributes it to other components
bull PedalToLamp reads the brake pedal position (pos_pedal)and calculates requested brightness of the brake indicatorlights (lamp_intensity)
bull BrakeLampActuator reads the requested brightness of thebrake indicator lights (lamp_intensity) and actuates thebrake lamps accordingly (ext_lamp)
bull TurnSwitchSensor reads the position of the lever and for-wards it (tss)
bull WarnLightsSensor reads status of the warn blink button andforwards it (wls)
bull Indicator reads the status of the warn blink button the leverposition and cyclically toggles the left and right signals(rla_signal rra_signal)
bull Rear(Left|Right)Actuator reads its input signal ((rla|rra)_signal)and actuates the bulb (ext_(rla|rra))
bull SwitchLightActuator reads left and right signals((rla|rra)_signal) and provides feedback on the dashboard
Horizontal (functional) contracts associated to the VFBmodel For the decomposed VFB model we derive horizontalcontracts specifying the desired IO behavior of the parts Asan example for the component BrakePedalSensor we state thecontracts shown in Table XI Contract CfIOBPS
specifies that
CfIOBPS
Afs whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Afw true
Gf whenever ext_pedal occurspos_pedal_out occurs
CfSIGNALBPS
Afs whenever pos_pedal_out occurs
pos_pedal_out does not occur during[pos_pedal_outpos_pedal_in]
Afw true
Gf whenever pos_pedal_out occurspos_pedal_in occurs
Table XIA SAMPLE OF THE HORIZONTAL CONTRACTS OF THE DECOMPOSED VFB
MODEL SUPERSCRIPT f REFERS TO ldquoFUNCTIONrdquo
provided that the pedal is not ldquomultiply pressedrdquo then thepos_pedal message traverses the BrakePedalSensor and then thewire following it with some unspecified delay In particular nomessage is lost due to a miss by this block Similar contractsare stated for all blocks of the VFB model thus resultingin a set Cf
IO of contracts For all AssemblySwConnectors ofthe composition horizontal contracts are specified that aresimilar to that of CfSIGNALBPS
resulting in a set CfSIGNAL
of contracts This contract scheme guarantees a reliable datatransport by each wire of the VFB model no matter how thecommunication is refined
So far we have stated contracts for each block and eachwire of the VFB model Compose the above contracts usingcontract composition (14) ie compute
CfVFB =otimes(otimes
C | C isin CfIO)
otimes(otimesC | C isin Cf
SIGNAL) (57)
RR ndeg 8147
Contracts for System Design 53
The guarantee offered by overall contract CfVFB is the con-junction of the guarantees of the constitutive contracts Hencecontract CfVFB guarantees that messages reliably traverse theVFB model with however an unspecified delay On the otherhand contract composition (14) assumes the conjunction ofall assumptions stated for each blockmdashthe guarantee offeredby CfVFB and the strong assumption of CR1
discharge all ofthese assumptions
At this point we observe that contract CfVFB involves notiming characteristics and thus functional contract CfVFB doesnot refine the initial contract CR1 To overcome this timingcontracts are added in the next step that will complement thisfunctional contract with timing viewpoint based on expectedperformance characteristics of the computing platform
Budgeting time using contracts We now state additionalcontracts such as the ones shown in Table XII Observethat for those contracts weak assumptions are used see Sec-tion XII-B regarding the motivations for doing this Observealso that we repeated the functional strong assumption56
Again stating similar contracts for each block and wire of the
CtIOBPS
Ats whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Atw ext_pedal occurs sporadic
with minperiod 15msGt delay between ext_pedal and
pos_pedal_out within [0ms15ms]
CtSIGNALBPS
Ats whenever pos_pedal_out occurs
pos_pedal_out does not occur during[pos_pedal_outpos_pedal_in]
Atw pos_pedal_out occurs sporadic
with minperiod 2msGt delay between pos_pedal_out and
pos_pedal_in within [0ms2ms]
Table XIITIMING CONTRACT OF DECOMPOSED VFB MODEL SUPERSCRIPT t
INDICATES THAT THESE CONTRACTS DEAL WITH TIMING
VFB model yields two sets CtIO and Ct
SIGNAL of contractsand we consider
CtVFB =otimes
(otimesC | C isin Ct
IO)otimes(otimesC | C isin Ct
SIGNAL)(58)
The next step is to combine for each component (blockor wire) of the VFB model the two functional and timingviewpoints using conjunction ie to compute
CVFB =otimes(otimes[
Cf and Ct]| (Cf Ct) isin CIO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin CSIGNAL
) (59)
where CIO collects for each block the pair of functional andtiming contracts associated with it and similarly for CSIGNAL
56 If we do not do this then when taking the conjunction of functionaland timing contracts the functional strong assumption gets absorbed by thestrong assumption of the timing contract since the latter is equal to T Seethe discussion regarding AssumeGuarantee contracts with variable alphabetsat the end of Section VII-C
At this point we observe that the architecture of the VFBmodel is a directed acyclic graph
Consider the conjunction C = Cf and Ct = (AG) for eachblock or wire As an example focus on block IOBPS whichis the first block of VFB seen as a directed acyclic graphRegarding the combination of strong and weak assumptionswe have A = Afs and Atw which is weaker than As theassumption of CR1
in Table X Regarding guarantees we haveG = Gf and Gt which ensures that messages traverse thecomponent without duplication or loss and with a delay lessthan the ldquominperiodrdquo of the input signal (15ms) Also guar-antee G offered by this block is strong enough to dischargethe assumption of the next wire when performing contractcomposition Reproducing the same reasoning inductivelyalong all blocks and wires of the VFB model seen as an acyclicgraph shows that
CVFB CR1(60)
Consequently submitting the pairs of contracts (Cf Ct) asso-ciated to each component for separate development possiblyby different suppliers will ensure correct integration (providedimplementations by the suppliers are correct with respect totheir contracts) In particular the component BrakePedalSensorbelongs to the chassis domain and is implemented by adifferent supplier than the other components
Discussion The above step of our contract based designmethodology leads to the following important notices
1) So far our proof steps were all manual Our contractbased reasoning however was instrumental in ensuring thatelementary proof steps were combined correctly Reasoningbased on intuition when component composition and view-point combination both occur is very likely to lead to wrongconclusions There is a strong added value in contract basedreasoning even if elementary proof steps are manual
2) Manual reasoning can be complemented by the use ofobservers Again it is important that the use of observerswhen component composition and viewpoint combination bothoccur is performed correctly Our development in Section V-Gprovides the formal support for this For the pattern basedlanguage used here a framework for checking refinement ofcontracts using an observer based strategy is described in [94]
3) The responsibility of establishing the sub-contracts sub-mitted to the different suppliers is assigned to the OEM inaccordance with his role as integrator Components belongingto different domains of a car (engine chassis etc) are likely tooriginate from different vendorssuppliers By using our abovereasoning the OEM can decompose its contract specificationspassing them to supplier(s) For example the componentBrakePedalSensor is the only one in the VFB model that belongsto the chassis domain and other components are developed byone or more different suppliers Thus in decomposition (59)the two sets of contracts CIO and CSIGNAL are partitioned
RR ndeg 8147
Contracts for System Design 54
eg for subcontracting to two different suppliers
Csupplier1VFB =
otimes(otimes[Cf and Ct
]| (Cf Ct) isin C1
IO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin C1
SIGNAL
)Csupplier2VFB =
otimes(otimes[Cf and Ct
]| (Cf Ct) isin C2
IO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin C2
SIGNAL
)Each supplier can then safely develop its own sub-systemindependently We develop this in the next sub-section
Implementation of software components and vertical as-sumptions Each of the software components being part ofthe software system composition (cf Figure 17) is a Compo-sitionSoftwareComponents as this allows the supplier to reusealready designed components We thus consider one suchcomponent with its contract C = Cf and Ct consisting of thefunctional contract Cf in conjunction with the timing contractCt The supplier can then follow two different approaches fordeveloping this component
In a first approach the supplier reuses a composition
C =otimes
iisinI Ci (61)
of off-the-shelf components available from a library Twosituations can then occurbull The easy case is when refinement holds C C This
means that for C = (As Aw G) guarantees are strongenough and assumptions are weak enough to implyrefinement with respect to the contract C specified bythe OEM
bull A more realistic (but also more delicate) case is when thefollowing weaker relations are satisfied
C Cf (62)G sube G (63)
As and Aw supe Afs andAfw (64)
but the conditions requested on timing assumptions forrefinement C C to hold are not satisfied
As and Aw 6supe Ats andAtw (65)
Under (65) composition from library C cannot be usedas such It can however still be used as a valid imple-mentation provided that some additional missing verticalassumption regarding timing is stated such that
As and Aw supe Ats andAtw and Atw︸ ︷︷ ︸for negotiation
(66)
(66) requires a negotiation in which additional verticalassumption Atw is returned back to the OEM as an ad-ditional performance requirement for the ECU platformIf this is accepted by the OEM then development by thesupplier using off-the-shelf components from the library(61) can proceed
The alternative approach is to implement the componentEventually this results in a composition of AtomicSoftwareCom-ponents This component type has an internal behavior specifi-cation comprising so called Runnables which are the smallest
executable entities known to AUTOSAR For each runnableactivation conditions are defined by means of RTEEvents con-trolled by the RuntimeEnvironment on the corresponding ECUand data accesses referring ports of the owning component AnRTEEvent can be configured to occur either cyclically (time-triggered) or by the data arrival on some input port of theowning component (event-triggered)
Figure 18 depicts the internal behavior of componentBrakePedalSensor This component consists of a single
BrakePedalSensor
BPSRunnable
pos_pedal_out
P=10ms
ext_pedal
Figure 18 Internal behavior of BrakePedalSensor-component
CfIBBPS
Afs whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Afw true
Gf whenever ext_pedal occurspos_pedal_out occurs
CtIBBPS
Ats whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Atw ext_pedal occurs sporadic
with minperiod 10msBPSRunnableact occurs each 10msdelay between BPSRunnableact andpos_pedal_out within [0ms10ms]
Gt delay between ext_pedal andpos_pedal_out within [0ms10ms + 10ms]
CprimetIBBPS
Aprimets whenever ext_pedal occursext_pedal does not occur during[ext_pedalpos_pedal_out]
Aprimetw ext_pedal occurs sporadicwith minperiod 10msBPSRunnableact occurs each 10msdelay between BPSRunnableact andpos_pedal_out within [0ms5ms]
Gprimet delay between ext_pedal andpos_pedal_out within [0ms10ms + 5ms]
Table XIIICONTRACTS FOR INTERNAL BEHAVIOR OF
BRAKEPEDALSENSOR-COMPONENT
runnable BPSRunnable which is activated cyclically with aperiod of 10ms Upon its activation it reads the sensorvalues from the ECU abstraction component and writes the
RR ndeg 8147
Contracts for System Design 55
position of the brake pedal on its provided SenderReceiverport The timing behavior of the component owning a time-triggered runnable can be characterized by the contract shownin Table XIII top
We now focus on the second situation in which the supplierwants to reuse components from a library to implementcontract C = CfIOBPS
and CtIOBPS We consider the case where
a component BrakePedalSensor has already been implementedand characterized by C = CfIBBPS
and CtIBBPSNow observe that
relation (62) holds However G 6sube G Taking a closer lookat Atw we see it assumes a worst case response time forBPSRunnable Thus the guarantee Gt can be strengthened ifweak assumption Atw is replaced by Aprimetw ensuring a shorterresponse time The supplier would then consider the con-tract Cprime = CfIBBPS
and CprimetIBBPS where the re-adjusted contract
CprimetIBBPScorresponds to assuming Aprimetw and guaranteeing Gprimet
For that modified contract relations (62ndash65) hold Howeverstrengthening an assumption is not a refinement Thereforeapplying this modification cannot be performed by the supplieron its own but rather requires negotiation with the OEM Ifthe OEM is willing to accept the stronger assumption Aprimetwthe component from the libary can be used and the modifiedcontract of the supplier is refined Cprime Cprimesupplier1
VFB The next process steps in the AUTOSAR methodology called
System configuration and ECU configuration define the targetarchitecture (ECUs and communication network) as well asthe deployment of the application software components onthat distributed architecture Thus satisfaction of the contractsspecified for the application needs to be verified for the givenarchitecture and deployment (cf IV-D4) We develop this inthe next two sub-sections
ECU configuration and vertical contracts During thefollowing discussion we assume that for each componentimplementation a contract similar to Cprime has been specifiedand possibly an associated Aprimetw has been negotiated Observethat Aprimetw may invalidate refinement of system requirements bythe VFB contract Consider the example above Aprimetw assumesan activation of BPSRunnable each 10ms and a worst caseresponse time less than 5ms This additional weak assumptionis now part of Cprimesupplier1
VFB However it is neither dischargedby any guarantee of CprimeVFB nor by the strong assumption ofCR1 Thus we need to verify that 1 all vertical assumptionscollected during previous steps are discharged during system-and ECU configuration and 2 all guarantees are met bysoftware components and connectors For both tasks state-of-the-art verification techniques can be used
As an example focus on the vertical assumption Aprimetw ofthe BrakePedalSensor-component and consider the ECU con-figuration depicted in Figure 19 The ECU hosts the twocomponents BrakePedalSensor and PedalToLamp of the VFBmodel57 These components are integrated with a layered basicsoftware stack on an ECU That stack consists of multipleBasicSoftwareModules (BSWM) Each of these modules has aset of standardized interfaces and is implemented by a set
57To simplify we omit port emcyBrake
RTE
BrakePedal
SensorPedalToLamp
BSW
COMOSt1 t2
Complex
Device
Driver
ext_pedal
pos_pedal_out
pos_pedal_in
lamp_intensity
isr
Figure 19 Extracting platform contracts from ECU configuration
of BswModuleEntities These are analogous to the Runnables ofapplication software components and are either executed by adedicated OS task or interrupt service routine Therefore weexpect BasicSoftwareModules to be characterized by contractsin a way similar to the internal behavior of applicationcomponents (cf contracts in Table XIII) In case a BSWM hasa BswModuleEntity that is not mapped to some task or interruptservice routine that entity is an ldquoordinaryrdquo function calledwithin the context of another BswModuleEntity or Runnable Inthe example ECU configuration two BSWMs are shown
bull A ComplexDeviceDriver which has direct access to thesensor of the ECU that detects position of the brake pedal
bull An AUTOSAR COM module and a CAN interface (notshown here)
The components and BSWMs own a single runnable eachbsw entity respectively The ECU configuration maps BP-SRunnable to task t1 of the operating system (OS) and PTL-Runnable to task t2 The BswModuleEntity of the ComplexDe-viceDriver is mapped to an interrupt service routine while theentity of the COM module is simply a function for sendinga signal That function is used by the AUTOSAR runtimeenvironment (RTE) to realize the communication specified onVFB-level by means of the connectors For each task of theOS the ECU configuration specifies at least its priority andwether it is preemptable The activation of a task is specifiedby linking an alarm of the OS to that task Those alarmscan also be configured to occur cyclically For each cyclicalarm we generate a contract PALARMi
with trivial strongand weak assumptions and as guarantee the cycle time ofthe alarm The example ECU configuration contains a singlealarm whose contract is listed in Table XIV top Furthermore
PALARM1
As trueAw trueG Alarmi occurs each 10ms
PBPSRunnable
As trueAw trueG delay between BPSRunnableact and
pos_pedal_out within [1ms4ms]
Table XIVPLATFORM CONTRACTS OBAINED BY ANALYSIS OF ECU CONFIGURATION
RR ndeg 8147
Contracts for System Design 56
we can extract from the AUTOSAR model of the componentimplementation a set of execution time specifications for eachRunnable owned by the component Again the same appliesto BswModuleEntities With this information we can create atask network and obtain response times for each Runnableand BswModuleEntity (if executed by some task or interruptservice routine) using tools like SymTAS58 or chronVAL59Afterwards we generate for each Runnable and BswModuleEntity(if executed by task or ISR) a contract PRunnablei
with stongand weak assumption T and as guarantee the reponse timeinterval determined by analysis For the ECU configurationsketched in Figure 19 BPSRunnable has a response time thatlies in the interval [1ms 4ms] resulting in the contract shownin Table XIV bottom Similar contracts are stated for all tasksand alarms extracted from the ECU configurations We thencompose these contracts and the contracts of the BSWMswhich yields the contract P characterizing the executionplatform Following the approach outlined in Section IV-D4we compose the VFB contract with the platform contract andcheck for refinement ie
CprimeVFB otimes P CprimeVFB (67)
The vertical assumption Aprimetw is discharged in the compositionof the VFB and platform contracts and refinement holdsFurthermore with Aprimetw being discharged refinement of thesystem requirement holds again
CprimeVFB otimes P CR1(68)
The approach outlined here to analyze the mapping of applica-tion software components and their associated contracts on anECU network by creating contracts from ECU configurationsand results of response time analysis has been implemented ina framework That framework includes a meta-model support-ing contract-based design and enables to 1 specify contractsfor components in foreign models and 2 check for refinementbetween contracts belonging to different models [24]
Inter-ECU communication During system configurationthe leaves of the hierarchical software composition calledAtomicSoftwareComponents are mapped to ECUs of the targetarchitecture Thus we know for each connector of the VFBmodel whether it must be implemented by the communicationnetwork interconnecting the ECUs
For both intra- and inter-ECU communication the designmust be verified against the corresponding contracts of theVFB model ie the set of contracts[
Cf and Ct] ∣∣ (Cf Ct) isin CSIGNAL
(69)
Again available analysis techniques can be used Suppose asignal from the VFB model is mapped to a frame transmittedon a CAN bus The OEM can then for each such contractuse the combination of strong and weak assumptions A =Afs and Atw as specification of the minimal inter-arrival timesof subsequent occurrences of the signal Taking into account
58httpwwwsymtavisioncomsymtashtml59httpwwwinchroncomchronvalhtml
the priority of each CAN frame given by its identifier theresponse time of each signal can be computed and comparedagainst the guarantee G = Gf andGt
If the communication network whose configuration is partof the AUTOSAR system configuration is successfully verifiedagainst the contracts defined in (69) deployment of the VFBmodel on the target architecture is correct with regard tothe VFB contract and the design fulfills the initial systemrequirement CR1
Discussion The above development highlights themethodological value of contracts for system design in AU-TOSAR context at later design stages First both contractconjunction and composition are used Then modificationsthat are not refinements are pinpointed which forces thesupplier to engage on a negotiation with the OEM regardingsystem specifications Without the solid support of contractsand its rules such kind of reasoning would be error prone
2) Safety The virtual function bus (VFB) concept wasintended to enable a distributed development of software com-ponents independently from the underlying hardware architec-ture The specification of the interfaces in the 3x releases didnot support the kind of non functional property necessary todevelop safety aspects of critical systems This fact lead to thedevelopment of the previously mentioned Timing Extensionand Safety Extension to Methodology and Templates Thesafety extension directly addresses the use of contracts forthe specification of safety relevant properties driven by theneed for compliance to the upcoming ISO26262 standardThe ISO26262 not only requires comprehensive checking ofrequirements but also states explicitly the need for usingassumptions on the environment to develop a safety relevantelement on the supplier side (ldquosafety element out of contextrdquo)In particular the standard distinguishes betweenbull A functional safety concept comprising the functional
safety requirements their allocation to architectural el-ements and their interaction necessary to achieve thesafety goals This is used to demonstrate that the risksrelated to an item of a vehicle are addressed by anadequate functional architecture
bull A technical safety concept used to demonstrate that thefunctional safety concept is addressed by an adequatetechnical solution
As a simple example for this approach we take the functionalarchitecture of Figure 20 showing the decomposition of theSafeBrakeIndication function into the ldquonormalrdquo BrakeIndicationfunction and the SignalingFailureDetection safety function in casethe BrakeIndication fails The corresponding safety goal requiresthat a loss of the braking indication function shall be detectedThis is formalized as contract CS0 shown in Table XV Thiscontract states that under a given failure hypothesis (ldquonodouble failurerdquo) either the brake lamp is activated or the driveris warned by the SignalingFailureDetection function This contractis attached to the function SafeBrakeIndication
For the subfunction BrakeIndication we show in Table XVIa contract CS1 stating the correct behavior in the absence
RR ndeg 8147
Contracts for System Design 57
CS0
As trueAw Only one of Fail(BrakeIndication)
and Fail(SignalFailureDetection) occursG Whenever BreakRequest occurs then
BreakIndication or SignalFailureDetection is performed
Table XVHORIZONTAL CONTRACT REPRESENTING FUNCTIONAL SAFETY
REQUIREMENT
ltltFunctiongtgt SafeBrakeIndication
ltltFunctiongtgt BrakeIndication
ltltSafetyFunctiongtgt SignalingFailureDetection
ltltFunctionalExchangegtgt BrakeRequest
ltltFunctionalExchangegtgt Detect(BrakeIndicationFail)
Figure 20 Functional architecture including safety function
of a failure of this function For the SignalingFailureDetection
CS1
As trueAw Absence of Fail(BrakeIndication)G Whenever BrakeRequest occurs then
BrakeIndication is performed
Table XVIHORIZONTAL CONTRACT FOR FUNCTION OF BRAKING LAMP
the associated contract states that a detected failure of thesub-function BrakeIndication is correctly indicated under theassumption that the provided function itself is not impacted bya failure see Table XVII An easy manual inspection shows
CS2
As trueAw Absence of fail(SignalingFailureDetection)G Whenever detect(fail(BrakeIndication))
SignalingFailureDetection is performed
Table XVIIHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
that the composition of CS1 otimes CS2 refines CS0 ie we haveformally validated the functional safety concept
The next step consists in allocating these functions tosoftware components on the VFB and developing a simpletechnical safety concept The corresponding technical architec-ture is shown in Figure 21 For the sake of simplicity we onlyconsider corrupted data while transmitting under failure modeThe affected communication links are marked in blue in Fig-ure 21 Thus fail(BrakeIndication) is mapped to fail(pos_pedal) andfail(lamp_intensity) In the same way fail(SignalingFailureDetection)is mapped to fail(mal_indication) This mapping is not furtherelaborated in this paper
For defining the technical safety concept so-called prop-agation contracts are used Propagation contracts expresshow failures (from the environment of the component) are
BrakePedal Sensor
PedalTo Lamp
BrakeLamp Actuator
MalfunctionIndication
lamp_intensity pos_pedal
ext_pedal mal_indication
ext_lamp
ext_indication
Figure 21 Extract of Indicator System
processed by the component According to the ISO 26262 (seeFigure 22) Faults Errors and Failures are distinguished by thepatterns used for the contracts
Figure 22 The role of Faults Errors and failures
For instance the contract CS4 of Table XVIII states that theerror state of the PedalToLamp component is caused by a failurein the communication
CS4
As trueAw trueG Mode PedalToLampError is caused by
fail(pos_pedal)
Table XVIIIHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
The nominal behavior is again given by the contract with anassumption about the absence of the communication failuresee Table XIX
Similarly the error state of the BreakLampActuator iscaused by a failure on the second communication link(fail(lamp_intensity)) or by a failure propagated from the PedalTo-Lamp component see Table XX The nominal behavior of the
RR ndeg 8147
Contracts for System Design 58
CS5
As trueAw Absence of fail(pos_pedal)G Whenever pos_pedal occurs then
lamp_intensity occurs
Table XIXEXEMPLARY CONTRACT FOR NOMINAL BEHAVIOR SPECIFICATION
BrakePedalSensor and the MalfunctionIndicator is formed similarlyto CS5
CS6
As trueAw trueG Mode BreakLampActuatorError is caused by
fail(lamp_intensity) or mode PedalToLampError
Table XXHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
The composition of contracts CS4 CS7
together with thenot stated simple nominal contracts entails the contract CS8
shown on Table XXI stating the functional safety requirement
CS8
As trueAw only one of faila failb failcG Whenever ext_pedal occurs then
ext_lamp or ext_indication occurs
Table XXICONTRACT STATING THE TECHNICAL SAFETY REQUIREMENT
Contract CS8is directly related to the functional safety goal
and includes the allocation to a technical safety concept Thisway a consistency between the functional and the technicalsafety concept has been established Furthermore thanks tothe formal pattern-based specification language the refinementrelations ensure that the concepts themselves are correct
To conclude let us mention other safety related use-caseswhich benefit from contract based specification such as theautomatic generation of fault-trees or FMEA tables as well asthe safe-state management
D Integrating Contracts in AUTOSAR
An important challenge is to smoothly integrate the use ofcontracts as part of AUTOSAR methodology We advocate amigration in two steps
TodaymdashOffering a Smooth Integration of Contract-BasedSystem Engineering with AUTOSAR The metamodel under-lying the CESAR reference technology platform has beencarefully designed to support a seamless design flow fromthe derivation of high-level requirements of new automotivefunctions to the level of detailed application design defined asthe entry point in the AUTOSAR design methodology The keyfor this smooth integration has been laid by AUTOSAR itselfby enforcing a clean separation between application develop-ment on the one side and deployment to distributed target
architectures on the other side Regarding layered design thejoint scope of CESAR and AUTOSAR ranges from systems-of-systems levels for Car2X applications to the introductionof new automotive functions and down to the detailed designlevel As illustrated in the previous section such phases wouldbuild on established design processes and currently used de-sign tools where contracts and viewpoints are conservativelyadded as additional flavor to existing design methodologiesFull hand-over to AUTOSAR takes place at the detailed designstage where component contracts get implemented using theAUTOSAR component model thus providing the entry pointfor the AUTOSAR design methodology
Following the AUTOSAR flow system configurations andECU configurations describe the detailed target hardware Wecan then automatically extract from system and ECU con-figurations all information for performing real-time analysisVertical assumptions on the component level can be derivedby back-annotation from the underlying target hardware Alter-natively vertical assumptions can be seen as constraining thetarget architecture (regarding its timing characteristics) and canthus be used to constrain the design space for possible targetarchitectures Finally when deploying components to ECUscommunications of the virtual functional bus are mapped to theinter-component communications on the physical architecture
The FuturemdashIntegrating Contracts in AUTOSAR The cur-rent AUTOSAR release is expressive enough to represent real-time contracts Using the concept of timing chains both end-to-end deadlines as well as assumed response times for compo-nent execution and communication can be expressed Howeverthe current release was not designed for extensibility thereis no established notion of viewpoints and hence no anchorto easily migrate from the current setting to one supportingmultiple viewpoints As pointed out before the decision asto which viewpoints should or should not be anchored is abusiness decision However given that ISO 26262 has becomebinding we see the need for a systematic integration of thesafety viewpoint
In fact a safety extension has already been proposed forinclusion in AUTOSAR It allows to use contracts for theencapsulation of Basic SoftWare (BSW) modules applicationsoftware components entities of the hardware architecture(like ECUs and buses) and the characterization of commu-nication services Such encapsulation would for instancedistinguish between BSW modules that (1) contribute to safety(safety mechanisms) and (2) those that could potentiallyimpact systemrsquos safety (by providing their failure propagationbehavior) A typical example for (1) would be the func-tion inhibition manager that maintains function inhibitionswhenever for instance implausible outputs are generated Atypical example for (2) would be an error that occurs inthe communication services or an error that is generated incommunication HW that impacts communication services
The objective of the extension is to provide an ISO 26262compliant traceability This allows for instance to deal withcompliance between functional safety (where functions haz-ards and safety functions are collected in the functional
RR ndeg 8147
Contracts for System Design 59
model) and technical safety of the AUTOSAR architectureinstance (guaranteeing that the AUTOSAR implementationmdashusing given safety functions of the AUTOSAR architecturemdashindeed implements the identified functional safety concept)
Since timing and safety viewpoints will be supported inAUTOSAR it is at least worthwhile to consider introducingthe concepts of viewpoints systematically Doing so will easetheir activation at times when other market factors such aspower-management mandate their introduction
E Summary and discussion
We have proposed a smooth path for integrating contractsin the context of AUTOSAR at the level of detailed designWe believe that the main aspects for consideration whileintroducing contracts are the handling of time budgets andthe specification of failure modes and failure propagation incombination with the functional aspect itself Vertical contractswere instrumental in handling time budgets Such contractsrelate two different layers of the AUTOSAR framework
XIII CONCLUSION
This paper presented past and recent results as well asnovel advances in the area of contracts and their theory Byencompassing (functional and non-functional) behaviors thenotion of contract we considered here represents a significantstep beyond the one originally developed in the softwareengineering community
A What contracts can do for the designer
This paper demonstrates that contracts offer a number ofadvantages
Contracts offer a technical support to legal customer-supplier documents Concurrent developmentmdashboth withinand across companiesmdashcalls for smooth coordination andintegration of the different design activities Properly definingand specifying the different concurrent design tasks is andremains a central difficulty Obligations must therefore beagreed upon together with suspensive conditions seen aslegal documents By clearly establishing responsibilities ourformalization of contracts constitutes the technical counterpartof such legal documents Contracts are an enabling technologyfor concurrent development
Contracts offer support to certification By providing for-mal arguments that can assess and guarantee the qualityof a design throughout all design phases (including earlyrequirements capture) contracts offer support for certificationBy providing sophisticated tools in support of modularityreuse in certification is made easier
Contracts comply with formal and semi-formal approachesThe need for being ldquocompletely formalrdquo has hampered for along time formal verification in many industrial sectors inwhich flexibility and intuitive expression in documentationsimulation and testing were and remain preferred As theAUTOSAR use case of Section XII demonstrated using con-tracts makes semi-formal design safer Small analysis stepsare within the reach of human reasoning A valid system
wide analysis for both component-based and refinement-baseddesigns is typically beyond the reach of human reasoningContract based design enables it
Contracts improve requirement engineering As illustratedin the Parking Garage example of Section XI contracts areinstrumental in decoupling top-level system architecture fromthe architecture used for sub-contracting to suppliers Formalsupport is critical in choosing alternative solutions and migrat-ing between different architectures with relatively small effortOf course contracts are not the only important technologyfor requirements engineeringmdashtraceability is essential anddeveloping domain specific ontologies is also important
Contracts can be used in any design process Contractsoffer a orthogonal support for all methodologies and can beused in any flow as a supporting technology in composing andrefining designs
B Status of research
The area of contracts benefits from many advances inresearch that were not targeted to it Interface theories weredeveloped by the community of game theorymdashcomponent andenvironment are seen as two players in a game Modalitiesaimed to offer more expressive logics were born at theboundary between logics and formal verification Contractsas a philosophy originated both from software engineeringand formal verification communities with the paradigms ofPre-conditionPost-condition or AssumeGuarantee It is notuntil the 2000rsquos that the concept of contracts presented hereas a tool to support system design emerged In this evolutionvarious formalisms and theories were borrowed to developa rigorous framework This paper was intended to show thepower of a unified theoretical background for contracts the useof contracts in present methodologies and the challenges for itseffective applications in future applications The mathematicalelegance of the concepts underpinning this area providesconfidence in a sustained continuation of the research effort
C Status of practice
The use of contract-based techniques in system design isin its infancy in industry Further maturation is needed forits paradigm and concepts to become on one side clearand simple to be widely accepted by engineers in their day-to-day work and on the other side developed enough toallow for the development of tools for automatic verificationand synthesis While powerful contract-based proof-of-concepttools are being experimentedmdashsome of them were presentedin this papermdashthe robustness of the tools and the underlyingtechniques is still weak and contract-based design flows andmethodologies are not yet fully developed nor mature
D The way forward
The ability of contracts to accommodate semi-formal andformal methodologies should enable a smooth and rapid mi-gration from theory and proof-of-concepts to robust flows andmethodologies The need for jointly developing new systemswhile considering issues of intellectual property will make
RR ndeg 8147
Contracts for System Design 60
it attractive to rely on contracts in supplier chains In ouropinion contracts are primarily helpful for early stages ofsystem design and particularly requirement engineering whereformal methods are desperately needed to support distributedand concurrent development by independent actors
We have illustrated in this paper how suppliers can be givensub-contracts that are correct by construction and can be auto-matically generated from top-level specification We believehowever that the semi-assistedsemi-manual use of contractssuch as exemplified by our AUTOSAR case study is alreadya significant help useful for requirements engineering tooAltogether a contract engine (such as the MICA tool presentedin Section XI) can be used in combination with both manualreasoning and dedicated formal verification engines (eg fortargeting the timing viewpoint or the safety viewpoint) as thebasis for future development that will make contracts mainstream
REFERENCES
[1] Martiacuten Abadi and Leslie Lamport Conjoining specifications ACMTrans Program Lang Syst 17(3)507ndash534 1995
[2] Yael Abarbanel Ilan Beer Leonid Gluhovsky Sharon Keidar andYaron Wolfsthal FoCs - Automatic Generation of Simulation Checkersfrom Formal Specifications In E Emerson and A Sistla editors Com-puter Aided Verification volume 1855 of Lecture Notes in ComputerScience pages 538ndash542 Springer Berlin Heidelberg 2000
[3] B Thomas Adler Luca de Alfaro Leandro Dias da Silva MarcoFaella Axel Legay Vishwanath Raman and Pritam Roy Ticc A Toolfor Interface Compatibility and Composition In Proc of the 18thInternational Conference on Computer Aided Verification (CAVrsquo06)volume 4144 of Lecture Notes in Computer Science pages 59ndash62Springer 2006
[4] Albert Benveniste and Benoicirct Caillaud and Jean-Baptiste RacletApplication of Interface Theories to the Separate Compilation ofSynchronous Programs In IEEE Conf on Decision and Control dec2012
[5] Luca De Alfaro and Thomas A Henzinger Interface-based design InIn Engineering Theories of Software Intensive Systems proceedings ofthe Marktoberdorf Summer School Kluwer 2004
[6] Rajeev Alur and David L Dill A theory of timed automata TheoreticalComputer Science 126(2)183ndash235 1994
[7] Rajeev Alur Limor Fix and Thomas A Henzinger A determinizableclass of timed automata In David L Dill editor CAV volume 818 ofLecture Notes in Computer Science pages 1ndash13 Springer 1994
[8] Rajeev Alur Limor Fix and Thomas A Henzinger Event-clockautomata A determinizable class of timed automata Theor ComputSci 211(1-2)253ndash273 1999
[9] Rajeev Alur Thomas A Henzinger and Orna Kupferman Alternating-time temporal logic J ACM 49(5)672ndash713 2002
[10] Rajeev Alur Thomas A Henzinger Orna Kupferman and Moshe YVardi Alternating refinement relations In Proc of the 9th InternationalConference on Concurrency Theory (CONCURrsquo98) volume 1466 ofLecture Notes in Computer Science pages 163ndash178 Springer 1998
[11] Adam Antonik Michael Huth Kim G Larsen Ulrik Nyman andAndrzej Wasowski 20 Years of Modal and Mixed SpecificationsBulletin of European Association of Theoretical Computer Science1(94) 2008
[12] Adam Antonik Michael Huth Kim Guldstrand Larsen Ulrik Nymanand Andrzej Wasowski Complexity of Decision Problems for Mixedand Modal Specifications In FoSSaCS pages 112ndash126 2008
[13] Road vehicles ndash functional safety Standard ISO 26262[14] Christel Baier and Joost-Pieter Katoen Principles of Model Checking
MIT Press Cambridge 2008[15] Felice Balarin Jerry R Burch Luciano Lavagno Yosinori Watanabe
Roberto Passerone and Alberto L Sangiovanni-Vincentelli Con-straints specification at higher levels of abstraction In Proceedingsof the Sixth IEEE International High-Level Design Validation and Test
Workshop (HLDVT01) pages 129ndash133 Monterey CA November 7ndash92001 IEEE Computer Society Los Alamitos CA USA
[16] Felice Balarin Abhijit Davare Massimiliano DrsquoAngelo Douglas Dens-more Trevor Meyerowitz Roberto Passerone Alessandro Pinto Al-berto Sangiovanni-Vincentelli Alena Simalatsar Yoshinori WatanabeGuang Yang and Qi Zhu Platform-based design and frameworksMETROPOLIS and METRO II In Gabriela Nicolescu and Pieter JMosterman editors Model-Based Design for Embedded Systems chap-ter 10 page 259 CRC Press Taylor and Francis Group Boca RatonLondon New York November 2009
[17] Felice Balarin and Roberto Passerone Functional verification method-ology based on formal interface specification and transactor generationIn Proceedings of the Conference on Design Automation and Test inEurope (DATE06) pages 1013ndash1018 Munich Germany March 6ndash102006 European Design and Automation Association 3001 LeuvenBelgium
[18] Felice Balarin and Roberto Passerone Specification synthesis andsimulation of transactor processes IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 26(10)1749ndash1762October 2007
[19] Felice Balarin Roberto Passerone Alessandro Pinto and Alberto LSangiovanni-Vincentelli A formal approach to system level designMetamodels and unified design environments In Proceedings of theThird ACM and IEEE International Conference on Formal Methodsand Models for Co-Design (MEMOCODE05) pages 155ndash163 VeronaItaly July 11ndash14 2005 IEEE Computer Society Los Alamitos CAUSA
[20] Felice Balarin Yosinori Watanabe Harry Hsieh Luciano LavagnoClaudio Passerone and Alberto L Sangiovanni-Vincentelli Metropo-lis An Integrated Electronic System Design Environment IEEEComputer 36(4)45ndash52 2003
[21] Krishnakumar Balasubramanian Aniruddha Gokhale Gabor KarsaiJanos Sztipanovits and Sandeep Neema Developing applicationsusing model-driven design environments IEEE Computer 39(2)33ndash40 2006
[22] Sebastian S Bauer Alexandre David Rolf Hennicker Kim GuldstrandLarsen Axel Legay Ulrik Nyman and Andrzej Wasowski Movingfrom specifications to contracts in component-based design In Juande Lara and Andrea Zisman editors FASE volume 7212 of LectureNotes in Computer Science pages 43ndash58 Springer 2012
[23] Sebastian S Bauer Philip Mayer Andreas Schroeder and Rolf Hen-nicker On Weak Modal Compatibility Refinement and the MIOWorkbench In Proc of 16th International Conference on Tools andAlgorithms for the Construction and Analysis of Systems (TACASrsquo10)volume 6015 of Lecture Notes in Computer Science pages 175ndash189Springer 2010
[24] Andreas Baumgart Eckard Boumlde Matthias Buumlker Werner Damm Guumln-ter Ehmen Tayfun Gezgin Stefan Henkler Hardi Hungar BernhardJosko Markus Oertel Thomas Peikenkamp Philipp Reinkemeier IngoStierand and Raphael Weber Architecture Modeling Technical reportOFFIS March 2011
[25] Nikola Benes Jan Kretiacutenskyacute Kim Guldstrand Larsen and Jiriacute SrbaChecking Thorough Refinement on Modal Transition Systems IsEXPTIME-Complete In Martin Leucker and Carroll Morgan editorsICTAC volume 5684 of Lecture Notes in Computer Science pages112ndash126 Springer 2009
[26] Nikola Benes Jan Kretiacutenskyacute Kim Guldstrand Larsen and Jiriacute SrbaOn determinism in modal transition systems Theoretical ComputerScience 410(41)4026ndash4043 2009
[27] Benoicirct Caillaud and Jean-Baptiste Raclet Ensuring Reachability byDesign In Int Colloquium on Theoretical Aspects of Computing sept2012
[28] Albert Benveniste and Geacuterard Berry The synchronous approach toreactive and real-time systems Proceedings of the IEEE 79(9)1270ndash1282 1991
[29] Albert Benveniste Benoicirct Caillaud Alberto Ferrari LeonardoMangeruca Roberto Passerone and Christos Sofronis Multiple view-point contract-based specification and design In Proceedings of theSoftware Technology Concertation on Formal Methods for Componentsand Objects FMCOrsquo07 volume 5382 of Lecture Notes in ComputerScience pages 200ndash225 Springer October 2008
[30] Albert Benveniste Paul Caspi Stephen A Edwards Nicolas Halb-wachs Paul Le Guernic and Robert de Simone The SynchronousLanguages 12 years later Proceedings of the IEEE 91(1)64ndash83 2003
RR ndeg 8147
Contracts for System Design 61
[31] Luca Benvenuti Alberto Ferrari Leonardo Mangeruca EmanueleMazzi Roberto Passerone and Christos Sofronis A contract-basedformalism for the specification of heterogeneous systems In Proceed-ings of the Forum on Specification Verification and Design Languages(FDL08) pages 142ndash147 Stuttgart Germany September 23ndash25 2008
[32] Gerard Berry The effectiveness of synchronous languages for thedevelopment of safety-critical systems White paper Esterel Technolo-gies 2003
[33] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet A compositional approach on modal specifications for timedsystems In Proc of the 11th International Conference on FormalEngineering Methods (ICFEMrsquo09) volume 5885 of Lecture Notes inComputer Science pages 679ndash697 Springer 2009
[34] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet Modal event-clock specifications for timed component-baseddesign Science of Computer Programming 2011 To appear
[35] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet Modal event-clock specifications for timed component-baseddesign Science of Computer Programming 2012 to appear
[36] Nathalie Bertrand Sophie Pinchinat and Jean-Baptiste Raclet Refine-ment and consistency of timed modal specifications In Proc of the3rd International Conference on Language and Automata Theory andApplications (LATArsquo09) volume 5457 of Lecture Notes in ComputerScience pages 152ndash163 Springer 2009
[37] Antoine Beugnard Jean-Marc Jeacutezeacutequel and Noeumll Plouzeau Makingcomponents contract aware IEEE Computer 32(7)38ndash45 1999
[38] Dirk Beyer Arindam Chakrabarti and Thomas A Henzinger Webservice interfaces In Allan Ellis and Tatsuya Hagino editors WWWpages 148ndash159 ACM 2005
[39] Purandar Bhaduri and S Ramesh Interface synthesis and protocolconversion Formal Aspects of Computing 20(2)205ndash224 2008
[40] Purandar Bhaduri and Ingo Stierand A proposal for real-time interfacesin speeds In Design Automation and Test in Europe (DATErsquo10) pages441ndash446 IEEE 2010
[41] Simon Bliudze and Joseph Sifakis The Algebra of Connectors -Structuring Interaction in BIP IEEE Trans Computers 57(10)1315ndash1330 2008
[42] R Bloem and B Jobstmann Manual for property-based synthesis toolTechnical Report Prosyd D223 2006
[43] Roderick Bloem Alessandro Cimatti Karin Greimel Georg HofferekRobert Koumlnighofer Marco Roveri Viktor Schuppan and RichardSeeber RATSY - A New Requirements Analysis Tool with SynthesisIn Tayssir Touili Byron Cook and Paul Jackson editors CAV volume6174 of Lecture Notes in Computer Science pages 425ndash429 Springer2010
[44] Grady Booch James Rumbaugh and Ivar Jacobson Unified ModelingLanguage User Guide The (2nd Edition) (Addison-Wesley ObjectTechnology Series) Addison-Wesley Professional 2005
[45] Amar Bouali XEVE an Esterel Verification Environment In Alan JHu and Moshe Y Vardi editors CAV volume 1427 of Lecture Notesin Computer Science pages 500ndash504 Springer 1998
[46] Geacuterard Boudol and Kim Guldstrand Larsen Graphical versus logicalspecifications Theor Comput Sci 106(1)3ndash20 1992
[47] Jerry R Burch Trace Algebra for Automatic Verification of Real-Time Concurrent Systems PhD thesis School of Computer ScienceCarnegie Mellon University August 1992
[48] Jerry R Burch Roberto Passerone and Alberto L Sangiovanni-Vincentelli Overcoming heterophobia Modeling concurrency in het-erogeneous systems In Proceedings of the 2nd International Confer-ence on Application of Concurrency to System Design (ACSD01) pages13ndash32 Newcastle upon Tyne UK June 25ndash29 2001 IEEE ComputerSociety Los Alamitos CA USA
[49] Benoicirct Caillaud Mica A Modal Interface Compositional AnalysisLibrary October 2011 httpwwwirisafrs4toolsmica
[50] Benoicirct Caillaud Benoicirct Delahaye Kim G Larsen Axel LegayMikkel Larsen Pedersen and Andrzej Wasowski Compositional designmethodology with constraint Markov chains In Proceedings of the7th International Conference on Quantitative Evaluation of SysTems(QEST) 2010 IEEE Computer Society 2010
[51] Daniela Cancila Roberto Passerone Tullio Vardanega and MarcoPanunzio Toward correctness in the specification and handling ofnon-functional attributes of high-integrity real-time embedded systemsIEEE Transactions on Industrial Informatics 6(2)181ndash194 May 2010
[52] Karlis Cerans Jens Chr Godskesen and Kim Guldstrand LarsenTimed Modal Specification - Theory and Tools In Costas Courcou-betis editor CAV volume 697 of Lecture Notes in Computer Sciencepages 253ndash267 Springer 1993
[53] Pavol Cernyacute Martin Chmelik Thomas A Henzinger and ArjunRadhakrishna Interface simulation distances In Marco Faella andAniello Murano editors GandALF volume 96 of EPTCS pages 29ndash42 2012
[54] Arindam Chakrabarti A Framework for Compositional Design andAnalysis of Systems PhD thesis EECS Department University ofCalifornia Berkeley Dec 2007
[55] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger MarcinJurdzinski and Freddy Y C Mang Interface compatibility checkingfor software modules In Ed Brinksma and Kim Guldstrand Larseneditors CAV volume 2404 of Lecture Notes in Computer Sciencepages 428ndash441 Springer 2002
[56] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger andFreddy Y C Mang Synchronous and Bidirectional Component Inter-faces In Proc of the 14th International Conference on Computer AidedVerification (CAVrsquo02) volume 2404 of Lecture Notes in ComputerScience pages 414ndash427 Springer 2002
[57] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger andMarieumllle Stoelinga Resource Interfaces In Rajeev Alur and InsupLee editors EMSOFT volume 2855 of Lecture Notes in ComputerScience pages 117ndash133 Springer 2003
[58] Edward Y Chang Zohar Manna and Amir Pnueli Characterizationof temporal property classes In Werner Kuich editor ICALP volume623 of Lecture Notes in Computer Science pages 474ndash486 Springer1992
[59] Taolue Chen Chris Chilton Bengt Jonsson and Marta ZKwiatkowska A compositional specification theory for componentbehaviours In Helmut Seidl editor ESOP volume 7211 of LectureNotes in Computer Science pages 148ndash168 Springer 2012
[60] Chris Chilton Marta Z Kwiatkowska and Xu Wang Revisiting timedspecification theories A linear-time perspective In Marcin Jurdzinskiand Dejan Nickovic editors FORMATS volume 7595 of Lecture Notesin Computer Science pages 75ndash90 Springer 2012
[61] E Clarke O Grumberg and D Peled Model Checking MIT Press1999
[62] Edmund M Clarke David E Long and Kenneth L McMillanCompositional model checking In LICS pages 353ndash362 1989
[63] W Damm E Thaden I Stierand T Peikenkamp and H HungarUsing Contract-Based Component Specifications for Virtual Integra-tion and Architecture Design In Proceedings of the 2011 DesignAutomation and Test in Europe (DATErsquo11) March 2011 To appear
[64] Werner Damm and David Harel LSCs Breathing life into messagesequence charts Formal Methods in System Design 19(1)45ndash80 2001
[65] Werner Damm Angelika Votintseva Alexander Metzner BernhardJosko Thomas Peikenkamp and Eckard Boumlde Boosting reuse ofembedded automotive applications through rich components In Pro-ceedings of FIT 2005 - Foundations of Interface Technologies 2005
[66] Werner Damm and Bernd Westphal Live and let die LSC basedverification of UML models Sci Comput Program 55(1-3)117ndash1592005
[67] Abhijit Davare Douglas Densmore Trevor Meyerowitz AlessandroPinto Alberto Sangiovanni-Vincentelli Guang Yang and Qi Zhu Anext-generation design framework for platform-based design In DesignVerification Conference (DVCon) San Josersquo California 2007
[68] Alexandre David Kim G Larsen Axel Legay Ulrik Nyman andAndrzej Wasowski Timed IO automata A complete specificationtheory for real-time systems In Proc of the 13th ACM InternationalConference on Hybrid Systems Computation and Control (HSCCrsquo10)pages 91ndash100 ACM 2010
[69] Alexandre David Kim Guldstrand Larsen Axel Legay Ulrik Nymanand Andrzej Wasowski ECDAR An Environment for CompositionalDesign and Analysis of Real Time Systems In Proc of the 8thInternational Symposium on Automated Technology for Verificationand Analysis (ATVArsquo10) volume 6252 of Lecture Notes in ComputerScience pages 365ndash370 2010
[70] Luca de Alfaro Game Models for Open Systems In VerificationTheory and Practice volume 2772 of Lecture Notes in ComputerScience pages 269ndash289 Springer 2003
[71] Luca de Alfaro Leandro Dias da Silva Marco Faella Axel LegayPritam Roy and Maria Sorea Sociable Interfaces In Proc of
RR ndeg 8147
Contracts for System Design 62
the 5th International Workshop on Frontiers of Combining Systems(FroCosrsquo05) volume 3717 of Lecture Notes in Computer Sciencepages 81ndash105 Springer 2005
[72] Luca de Alfaro and Thomas A Henzinger Interface automata In Procof the 9th ACM SIGSOFT International Symposium on Foundations ofSoftware Engineering (FSErsquo01) pages 109ndash120 ACM Press 2001
[73] Luca de Alfaro and Thomas A Henzinger Interface theories forcomponent-based design In Thomas A Henzinger and Christoph MKirsch editors EMSOFT volume 2211 of Lecture Notes in ComputerScience pages 148ndash165 Springer 2001
[74] Luca de Alfaro Thomas A Henzinger and Marieumllle Stoelinga TimedInterfaces In Proc of the 2nd International Workshop on EmbeddedSoftware (EMSOFTrsquo02) volume 2491 of Lecture Notes in ComputerScience pages 108ndash122 Springer 2002
[75] Benoicirct Delahaye Modular Specification and Compositional Analysisof Stochastic Systems PhD thesis Universiteacute de Rennes 1 2010
[76] Benoicirct Delahaye Benoicirct Caillaud and Axel Legay ProbabilisticContracts A Compositional Reasoning Methodology for the Designof Stochastic Systems In Proc 10th International Conference onApplication of Concurrency to System Design (ACSD) Braga PortugalIEEE 2010
[77] Benoicirct Delahaye Benoicirct Caillaud and Axel Legay Probabilisticcontracts A compositional reasoning methodology for the designof systems with stochastic andor non-deterministic aspects FormalMethods in System Design 2011 To appear
[78] Benoicirct Delahaye Uli Fahrenberg Thomas A Henzinger Axel Legayand Dejan Nickovic Synchronous interface theories and time trig-gered scheduling In Holger Giese and Grigore Rosu editorsFMOODSFORTE volume 7273 of Lecture Notes in Computer Sci-ence pages 203ndash218 Springer 2012
[79] Benoicirct Delahaye Joost-Pieter Katoen Kim G Larsen Axel LegayMikkel L Pedersen Falak Sher and Andrzej Wasowski AbstractProbabilistic Automata In Ranjit Jhala and David A Schmidt editorsVMCAI volume 6538 of Lecture Notes in Computer Science pages324ndash339 Springer 2011
[80] Douglas Densmore Sanjay Rekhi and Alberto L Sangiovanni-Vincentelli Microarchitecture Development via Metropolis SuccessivePlatform Refinement In DATE pages 346ndash351 IEEE ComputerSociety 2004
[81] David L Dill Trace Theory for Automatic Hierarchical Verificationof Speed-Independent Circuits ACM Distinguished Dissertations MITPress 1989
[82] Nicolaacutes DrsquoIppolito Dario Fischbein Marsha Chechik and SebastiaacutenUchitel MTSA The Modal Transition System Analyser In Proc ofthe 23rd IEEEACM International Conference on Automated SoftwareEngineering (ASErsquo08) pages 475ndash476 IEEE 2008
[83] Laurent Doyen Thomas A Henzinger Barbara Jobstmann and TatjanaPetrov Interface theories with component reuse In Proceedings of the8th ACM amp IEEE International conference on Embedded softwareEMSOFTrsquo08 pages 79ndash88 2008
[84] Dumitru Potop-Butucaru and Stephen Edwards and Geacuterard BerryCompiling Esterel Springer V 2007 ISBN 0387706267
[85] Cindy Eisner PSL for Runtime Verification Theory and Practice InOleg Sokolsky and Serdar Tasiran editors RV volume 4839 of LectureNotes in Computer Science pages 1ndash8 Springer 2007
[86] Cindy Eisner Dana Fisman John Havlicek Michael JC GordonAnthony McIsaac and David Van Campenhout Formal Syntax andSemantics of PSL - Appendix B of Accellera LRM January 2003Technical report IBM 2003
[87] Cindy Eisner Dana Fisman John Havlicek Yoad Lustig AnthonyMcIsaac and David Van Campenhout Reasoning with temporal logicon truncated paths In Warren A Hunt Jr and Fabio Somenzi editorsCAV volume 2725 of Lecture Notes in Computer Science pages 27ndash39Springer 2003
[88] Johan Eker Joumlrn W Janneck Edward A Lee Jie Liu Xiaojun LiuJ Ludvig Stephen Neuendorffer S Sachs and Yuhong Xiong Tamingheterogeneity - the ptolemy approach Proc of the IEEE 91(1)127ndash144 2003
[89] G Feuillade Modal specifications are a syntactic fragment of the Mu-calculus Research Report RR-5612 INRIA June 2005
[90] Dario Fischbein and Sebastiaacuten Uchitel On correct and completestrong merging of partial behaviour models In Proc of the 16thACM SIGSOFT International Symposium on Foundations of SoftwareEngineering (SIGSOFT FSErsquo08) pages 297ndash307 ACM 2008
[91] F Fleurey P A Muller and J M Jzquel Weaving executabilityinto object-oriented meta-languages In Proceedgins of the 8th In-ternational Conference on Model Driven Engineering Languages andSystems (MODELS05) October 2005
[92] Freacutedeacuteric Boussinot and Robert de Simone The Esterel languageProceedings of the IEEE 79(9)1293ndash1304 1991
[93] Peter Fritzson Principles of Object-Oriented Modeling and Simulationwith Modelica 21 Wiley 2003
[94] Tayfun Gezgin Raphael Weber and Maurice Girod A RefinementChecking Technique for Contract-Based Architecture Designs InFourth International Workshop on Model Based Architecting andConstruction of Embedded Systems ACES-MBrsquo11 volume 7167 ofLecture Notes in Computer Science Springer October 2011
[95] Jens Chr Godskesen Kim Guldstrand Larsen and Arne Skou Auto-matic verification of real-time systems using Epsilon In Son T Vuongand Samuel T Chanson editors PSTV volume 1 of IFIP ConferenceProceedings pages 323ndash330 Chapman amp Hall 1994
[96] G Goumlssler and J-B Raclet Modal Contracts for Component-basedDesign In Proc of the 7th IEEE International Conference on SoftwareEngineering and Formal Methods (SEFMrsquo09) IEEE Computer SocietyPress November 2009
[97] Susanne Graf and Sophie Quinton Contracts for BIP HierarchicalInteraction Models for Compositional Verification In John Derrick andJuumlri Vain editors FORTE volume 4574 of Lecture Notes in ComputerScience pages 1ndash18 Springer 2007
[98] Orna Grumberg and David E Long Model checking and modularverification ACM Trans Program Lang Syst 16(3)843ndash871 1994
[99] Imene Ben Hafaiedh Susanne Graf and Sophie Quinton Reasoningabout Safety and Progress Using Contracts In Proc of ICFEMrsquo10volume 6447 of LNCS pages 436ndash451 Springer 2010
[100] Nicolas Halbwachs Synchronous programming of reactive systemsKluwer Academic Pub 1993
[101] Nicolas Halbwachs Fabienne Lagnier and Christophe Ratel Program-ming and Verifying Real-Time Systems by Means of the SynchronousData-Flow Language Lustre IEEE Trans Software Eng 18(9)785ndash793 1992
[102] Nicolas Halbwachs Fabienne Lagnier and Pascal Raymond Syn-chronous observers and the verification of reactive systems In MauriceNivat Charles Rattray Teodor Rus and Giuseppe Scollo editorsAMAST Workshops in Computing pages 83ndash96 Springer 1993
[103] Nicolas Halbwachs and Pascal Raymond Validation of synchronousreactive systems From formal verification to automatic testing In P SThiagarajan and Roland H C Yap editors ASIAN volume 1742 ofLecture Notes in Computer Science pages 1ndash12 Springer 1999
[104] David Harel Statecharts A visual formalism for complex systemsSci Comput Program 8(3)231ndash274 1987
[105] David Harel Hillel Kugler Shahar Maoz and Itai Segall Acceleratingsmart play-out In Jan van Leeuwen Anca Muscholl David PelegJaroslav Pokornyacute and Bernhard Rumpe editors SOFSEM volume5901 of Lecture Notes in Computer Science pages 477ndash488 Springer2010
[106] David Harel Robby Lampert Assaf Marron and Gera Weiss Model-checking behavioral programs In Samarjit Chakraborty Ahmed Jer-raya Sanjoy K Baruah and Sebastian Fischmeister editors EMSOFTpages 279ndash288 ACM 2011
[107] David Harel and Rami Marelly Come Letrsquos Play Scenario-BasedProgramming Using LSCs and the Play-Engine Springer-Verlag 2003httpwwwwisdomweizmannacil~harelComeLetsPlaypdf
[108] David Harel Assaf Marron and Gera Weiss Behavioral programmingCommun ACM 55(7)90ndash100 2012
[109] David Harel Assaf Marron Guy Wiener and Gera Weiss Behavioralprogramming decentralized control and multiple time scales InCristina Videira Lopes editor SPLASH Workshops pages 171ndash182ACM 2011
[110] David Harel and Amir Pnueli On the development of reactive systemsIn K R Apt editor Logic and Models for Verification and Specificationof Concurrent Systems volume F13 of NATO ASI Series pages 477ndash498 Springer-Verlag 1985
[111] H Heinecke W Damm B Josko A Metzner H KopetzA Sangiovanni-Vincentelli and M Di Natale Software Componentsfor Reliable Automotive Systems In Design Automation and Test inEurope 2008 DATE rsquo08 pages 549ndash554 march 2008
[112] Thomas A Henzinger and Dejan Nickovic Independent imple-mentability of viewpoints In Radu Calinescu and David Garlan edi-
RR ndeg 8147
Contracts for System Design 63
tors Monterey Workshop volume 7539 of Lecture Notes in ComputerScience pages 380ndash395 Springer 2012
[113] C A R Hoare An axiomatic basis for computer programmingCommun ACM 12(10)576ndash580 1969
[114] INCOSE Incose systems engineering handbook 2010 httpwwwincoseorgProductsPubsproductssehandbookaspx
[115] Cliff B Jones Specification and design of (parallel) programs In IFIPCongress pages 321ndash332 1983
[116] B Jonsson and K G Larsen Specification and refinement ofprobabilistic processes In Logic in Computer Science (LICS) pages266ndash277 IEEE Computer 1991
[117] Gilles Kahn The Semantics of Simple Language for Parallel Program-ming In IFIP Congress pages 471ndash475 1974
[118] S Karris Introduction to Simulink with Engineering ApplicationsOrchard Publications 2006
[119] G Karsai J Sztipanovits A Ledeczi and T Bapty Model-integrated development of embedded software Proceedings of theIEEE 91(1)145ndash164 January 2003
[120] Gabor Karsai Janos Sztipanovitz Akos Ledczi and Ted Bapty Model-integrated development of embedded software Proceedings of theIEEE 91(1) January 2003
[121] Orna Kupferman and Moshe Y Vardi Modular model checking InWillem P de Roever Hans Langmaack and Amir Pnueli editorsCOMPOS volume 1536 of Lecture Notes in Computer Science pages381ndash401 Springer 1997
[122] Leslie Lamport Proving the correctness of multiprocess programsIEEE Trans Software Eng 3(2)125ndash143 1977
[123] C Larman and VR Basili Iterative and incremental developments abrief history Computer 36(6)47ndash56 June 2003
[124] Kim G Larsen and L Xinxin Equation solving using modal transitionsystems In Proceedings of the 5th Annual IEEE Symp on Logic inComputer Science LICSrsquo90 pages 108ndash117 IEEE Computer SocietyPress 1990
[125] Kim Guldstrand Larsen Modal specifications In Automatic Verifica-tion Methods for Finite State Systems volume 407 of Lecture Notes inComputer Science pages 232ndash246 Springer 1989
[126] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski In-terface InputOutput Automata In Jayadev Misra Tobias Nipkowand Emil Sekerinski editors FM volume 4085 of Lecture Notes inComputer Science pages 82ndash97 Springer 2006
[127] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski ModalIO Automata for Interface and Product Line Theories In ProgrammingLanguages and Systems 16th European Symposium on ProgrammingESOPrsquo07 volume 4421 of Lecture Notes in Computer Science pages64ndash79 Springer 2007
[128] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski OnModal Refinement and Consistency In Proc of the 18th InternationalConference on Concurrency Theory (CONCURrsquo07) pages 105ndash119Springer 2007
[129] Kim Guldstrand Larsen Bernhard Steffen and Carsten Weise A con-straint oriented proof methodology based on modal transition systemsIn Proc of the 1st International Workshop on Tools and Algorithmsfor Construction and Analysis of Systems (TACASrsquo95) volume 1019of Lecture Notes in Computer Science pages 17ndash40 Springer 1995
[130] Kim Guldstrand Larsen and Bent Thomsen A Modal Process LogicIn Proceedings of the Third Annual Symposium on Logic in ComputerScience (LICSrsquo88) pages 203ndash210 IEEE 1988
[131] A Ledeczi A Bakay M Maroti P Volgyesi G Nordstrom J Sprin-kle and G Karsai Composing domain-specific design environmentsIEEE Computer 34(11)44 ndash51 November 2001
[132] Akos Ledeczi Miklos Maroti Arpad Bakay Gabor Karsai JasonGarrett Charles Thomason Greg Nordstrom Jonathan Sprinkle andPeter Volgyesi The generic modeling environment In Proceedingsof the IEEE International Workshop on Intelligent Signal Processing(WISP2001) Budapest Hungary May 24ndash25 2001
[133] Edward A Lee Cyber physical systems Design challenges TechnicalReport UCBEECS-2008-8 EECS Department University of Califor-nia Berkeley Jan 2008
[134] Nancy A Lynch Inputoutput automata Basic timed hybrid proba-bilistic dynamic In Roberto M Amadio and Denis Lugiez editorsCONCUR volume 2761 of Lecture Notes in Computer Science pages187ndash188 Springer 2003
[135] Nancy A Lynch and Eugene W Stark A proof of the kahn principlefor inputoutput automata Inf Comput 82(1)81ndash92 1989
[136] Zohar Manna and Amir Pnueli Temporal verification of reactivesystems Safety Springer 1995
[137] Herveacute Marchand Patricia Bournai Michel Le Borgne and Paul LeGuernic Synthesis of Discrete-Event Controllers Based on the SignalEnvironment Discrete Event Dynamic Systems 10(4)325ndash346 2000
[138] Herveacute Marchand and Mazen Samaan Incremental Design of aPower Transformer Station Controller Using a Controller SynthesisMethodology IEEE Trans Software Eng 26(8)729ndash741 2000
[139] B Meyer Applying ldquodesign by contractrdquo IEEE Computer 25(10)40ndash51 October 1992
[140] Bertrand Meyer Touch of Class Learning to Program Well UsingObject Technology and Design by Contract Springer SoftwareEngineering 2009
[141] MW Maier Architecting Principles for Systems of Systems SystemsEngineering 1(4)267ndash284 1998
[142] Walid A Najjar Edward A Lee and Guang R Gao Advances in thedataflow computational model Parallel Computing 25(13-14)1907ndash1929 1999
[143] Radu Negulescu Process Spaces and the Formal Verification ofAsynchronous Circuits PhD thesis University of Waterloo Canada1998
[144] Nicolas Halbwachs and Paul Caspi and Pascal Raymond and DanielPilaud The synchronous data flow programming language LustreProceedings of the IEEE 79(9)1305ndash1320 1991
[145] P Nuzzo A Sangiovanni-Vincentelli X Sun and A PuggelliMethodology for the design of analog integrated interfaces usingcontracts IEEE Sensors Journal 12(12)3329ndash3345 Dec 2012
[146] Object Management Group (OMG) Model driven architecture (MDA)FAQ [online] httpwwwomgorgmda
[147] Object Management Group (OMG) Unified Modeling Language(UML) specification [online] httpwwwomgorgspecUML
[148] Object Management Group (OMG) A UML profile for MARTE beta1 OMG Adopted Specification ptc07-08-04 OMG August 2007
[149] Object Management Group (OMG) System modeling languagespecification v11 Technical report OMG 2008
[150] Object constraint language version 20 OMG Available Specificationformal06-05-01 Object Management Group May 2006
[151] The Design Automation Standards Committee of the IEEE Com-puter Society editor 1850-2010 - IEEE Standard for PropertySpecification Language (PSL) IEEE Computer Society 2010
[152] J Hudak P Feiler D Gluch The Architecture Analysis and DesignLanguage (AADL) An Introduction Software Engineering Institute(SEI) Technical Note CMUSEI-2006-TN-011 February 2006
[153] Roberto Passerone Semantic Foundations for Heterogeneous SystemsPhD thesis Department of Electrical Engineering and Computer Sci-ences University of California Berkeley Berkeley CA 94720 May2004
[154] Roberto Passerone Jerry R Burch and Alberto L Sangiovanni-Vincentelli Refinement preserving approximations for the design andverification of heterogeneous systems Formal Methods in SystemDesign 31(1)1ndash33 August 2007
[155] Roberto Passerone Luca de Alfaro Thomas A Henzinger and AlbertoSangiovanni-Vincentelli Convertibility verification and converter syn-thesis Two faces of the same coin In Proceedings of InternationalConference on Computer Aided Design San Jose CA 2002
[156] Roberto Passerone Imene Ben Hafaiedh Susanne Graf Albert Ben-veniste Daniela Cancila Arnaud Cuccuru Seacutebastien Geacuterard FrancoisTerrier Werner Damm Alberto Ferrari Leonardo Mangeruca Bern-hard Josko Thomas Peikenkamp and Alberto Sangiovanni-VincentelliMetamodels in Europe Languages tools and applications IEEEDesign and Test of Computers 26(3)38ndash53 MayJune 2009
[157] Paul Le Guernic and Thiserry Gautier and Michel Le Borgne andClaude Le Maire Programming real-time applications with SignalProceedings of the IEEE 79(9)1321ndash1336 1991
[158] I Pill B Jobstmann R Bloem R Frank M Moulin B SterinM Roveri and S Semprini Property simulation Technical ReportProsyd D121 2005
[159] Dumitru Potop-Butucaru Benoicirct Caillaud and Albert BenvenisteConcurrency in synchronous systems Formal Methods in SystemDesign 28(2)111ndash130 2006
[160] Dumitru Potop-Butucaru Robert de Simone and Yves Sorel Neces-sary and sufficient conditions for deterministic desynchronization InChristoph M Kirsch and Reinhard Wilhelm editors EMSOFT pages124ndash133 ACM 2007
RR ndeg 8147
Contracts for System Design 64
[161] Terry Quatrani Visual modeling with Rational Rose 2000 and UML(2nd ed) Addison-Wesley Longman Ltd Essex UK UK 2000
[162] R Sudarsan and SJ Fenves and RD Sriram and F Wang A productinformation modeling framework for product lifecycle managementComputer-Aided Design 371399ndash1411 2005
[163] Jean-Baptiste Raclet Quotient de speacutecifications pour la reacuteutilisationde composants PhD thesis Ecole doctorale Matisse universiteacute deRennes 1 November 2007
[164] Jean-Baptiste Raclet Residual for Component Specifications In Procof the 4th International Workshop on Formal Aspects of ComponentSoftware (FACSrsquo07) 2007
[165] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct CaillaudAxel Legay and Roberto Passerone Modal interfaces Unifyinginterface automata and modal specifications In Proceedings of theNinth International Conference on Embedded Software (EMSOFT09)pages 87ndash96 Grenoble France October 12ndash16 2009
[166] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct CaillaudAxel Legay and Roberto Passerone A modal interface theory forcomponent-based design Fundamenta Informaticae 108(1-2)119ndash149 2011
[167] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct Caillaudand Roberto Passerone Why are modalities good for interfacetheories In Proc of the 9th International Conference on Applicationof Concurrency to System Design (ACSDrsquo09) IEEE Computer SocietyPress 2009
[168] Richard Payne and John Fitzgerald Evaluation of ArchitecturalFrameworks Supporting Contract-Based Specification Technical Re-port CS-TR-1233 Computing Science Newcastle University UK Dec2010 available from httpwwwcsnclacukpublicationstrspapers1233pdf
[169] Robert W Floyd Assigning meaning to programs In JT Schwartzeditor Proceedings of Symposium on Applied Mathematics volume 19pages 19ndash32 1967
[170] A Sangiovanni-Vincentelli S Shukla J Sztipanovits G Yang andD Mathaikutty Metamodeling An emerging representation paradigmfor system-level design Special Section on Meta-Modeling IEEEDesign and Test 26(3)54ndash69 2009
[171] Alberto Sangiovanni-Vincentelli Quo vadis sld Reasoning aboutthe trends and challenges of system level design Proc of the IEEE95(3)467ndash506 2007
[172] D Schmidt Model-driven engineering IEEE Computer pages 25ndash31February 2006
[173] German Sibay Sebastian Uchitel and Viacutector Braberman ExistentialLive Sequence Charts Revisited In ICSE 2008 30th InternationalConference on Software Engineering ACM May 2008
[174] Joseph Sifakis Component-Based Construction of HeterogeneousReal-Time Systems in Bip In Giuliana Franceschinis and KarstenWolf editors Petri Nets volume 5606 of Lecture Notes in ComputerScience page 1 Springer 2009
[175] Functional safety of electricalelectronicprogrammable electronicsafety-related systems Standard IEC 61508
[176] Eugene W Stark A proof technique for relyguarantee properties InS N Maheshwari editor FSTTCS volume 206 of Lecture Notes inComputer Science pages 369ndash391 Springer 1985
[177] Stavros Tripakis Ben Lickly Thomas A Henzinger and Edward ALee On relational interfaces In Proc of the 9th ACM amp IEEEInternational conference on Embedded software (EMSOFTrsquo09) pages67ndash76 ACM 2009
[178] Stavros Tripakis Ben Lickly Thomas A Henzinger and Edward ALee A theory of synchronous relational interfaces ACM TransProgram Lang Syst 33(4)14 2011
[179] Sebastiaacuten Uchitel and Marsha Chechik Merging partial behaviouralmodels In Proc of the 12th ACM SIGSOFT International Symposiumon Foundations of Software Engineering (SIGSOFT FSErsquo10) pages43ndash52 ACM 2004
[180] Jos Warmer and Anneke Kleppe The Object Constraint LanguageGetting Your Models Ready for MDA Addison-Wesley LongmanPublishing Co Inc Boston MA USA 2nd edition 2003
RR ndeg 8147
RESEARCH CENTRERENNES ndash BRETAGNE ATLANTIQUE
Campus universitaire de Beaulieu35042 Rennes Cedex
PublisherInriaDomaine de Voluceau - RocquencourtBP 105 - 78153 Le Chesnay Cedexinriafr
ISSN 0249-6399
- Introduction
-
- The Present System Design
- The Future CPS and SoS
- The Need for a Methodological Effort
- Contract based design
- Readers guide
-
- System Design Challenges
-
- Complexity of Systems
- Complexity of OEM-Supplier Chains
- Managing Requirements
- Managing Risks
- System-wide Optimization
-
- How Challenges have been addressed so far
-
- Complexity of Systems and System-wide Optimization
-
- Layered design
- Component-based design
- The V-model process
- Model-Based Design
- Virtual Integration
- Platform Based Design
-
- Complexity of OEM-Supplier Chains Standardization and Harmonization
-
- Standardization of design entities
- Harmonization of processes and certification
-
- Managing Requirements Traceability and Multiple Viewpoints
- Cross-company Shared Risk Management
- The Need for Contracts
-
- Contracts what why where and how
-
- Contracts
-
- Components and their Environment Contracts
-
- Contract Operators
-
- Contract Composition and System Integration
- Contract Refinement and Independent Development
- Contract Conjunction and Viewpoint Fusion
-
- Contracts in requirement engineering
- Contract Support for Design Methodologies
-
- Supporting open systems
- Managing Requirements and Fusing Viewpoints
- Design Chain Management Re-using and Independent Development
- Deployment and Mapping
-
- Bibliographical note
-
- A Mathematical Meta-theory of Contracts
-
- Components and their composition
- Contracts
- Refinement and conjunction
- Contract composition
- Quotient
- Discussion
- Observers
- Bibliographical note
-
- Panorama of concrete theories
- Panorama AssumeGuarantee contracts
-
- Dataflow AG contracts
- Capturing exceptions
- Dealing with variable alphabets
- Synchronous AG contracts
- Observers
- Discussion
- Bibliographical note
-
- Panorama Interface theories
-
- Components as io-automata
- Interface Automata with fixed alphabet
- Modal Interfaces with fixed alphabet
- Modal Interfaces with variable alphabet
- Projecting and Restricting
- Observers
- Bibliographical note
-
- Panorama Timed Interface Theories
-
- Components as Event-Clock Automata
- Modal Event-Clock Specifications
- Bibliographical note
-
- Panorama Probabilistic Interface Theories
-
- Components as Probabilistic Automata
- Simple Modal Probabilistic Interfaces
- Bibliographical note
-
- The Parking Garage an example in Requirements Engineering
-
- The contract framework
- Top level requirements
- Formalizing requirements as contracts
- Sub-contracting to suppliers
- The four ``C
-
- Consistency amp Compatibility
- Correctness
- Completeness
-
- Discussion
-
- Contracts in the context of Autosar
-
- The Autosar context
- The contract framework
- Exterior Light Management System
-
- Function and timing
- Safety
-
- Integrating Contracts in Autosar
- Summary and discussion
-
- Conclusion
-
- What contracts can do for the designer
- Status of research
- Status of practice
- The way forward
-
- References
-
Abstract Systems design has become a key challenge and differentiating factor over the last decadesfor system companies Aircrafts trains cars plants distributed telecommunication military or health caresystems and more involve systems design as a critical step Complexity has caused system design timesand costs to go severely over budget so as to threaten the health of entire industrial sectors Heuristicmethods and standard practices do not seem to scale with complexity so that novel design methods andtools based on a strong theoretical foundation are sorely neededModel-based design as well as other methodologies such as layered and compositional design have beenused recently but a unified intellectual framework with a complete design flow supported by formaltools is still lacking albeit some attempts at this framework such as Platform-based Design have beensuccessfully deployedRecently an rdquoorthogonalrdquo approach has been proposed that can be applied to all methodologies proposedthus far to provide a rigorous scaffolding for verification analysis and abstractionrefinement contract-based design Several results have been obtained in this domain but a unified treatment of the topic thatcan help in putting contract-based design in perspective is still missing This paper intends to providesuch treatment where contracts are precisely defined and characterized so that they can be used in designmethodologies such as the ones mentioned above with no ambiguity In addition the paper provides animportant link between interfaces and contracts to show similarities and correspondences Examples ofthe use of contracts in design are provided as well as in depth analysis of existing literature
Key-words system design component based design contract interface
Contrats pour la conception de systegravemesReacutesumeacute Cet article fait le point sur le concept de contrat pour la conception de systegravemes Les contrats que nous proposonsportent non seulement sur des proprieacuteteacutes de typage de leurs interfaces mais incluent une description abstraite de comportementsNous proposons une meacuteta-theacuteorie ou si lrsquoon veut une theacuteorie geacuteneacuterique des contrats qui permet le deacuteveloppement seacutepareacute desous-systegravemes Nous montrons que cette meacuteta-theacuteorie se speacutecialise en lrsquoune ou lrsquoautre des theacuteories connues
Mots-cleacutes conception des systegravemes composant contrat interface
Contracts for System Design 4
CONTENTS
I Introduction 6I-A The Present System Design 6I-B The Future CPS and SoS 6I-C The Need for a Methodological Effort 6I-D Contract based design 7I-E Readerrsquos guide 7
II System Design Challenges 8II-A Complexity of Systems 8II-B Complexity of OEM-Supplier Chains 9II-C Managing Requirements 9II-D Managing Risks 10II-E System-wide Optimization 10
III How Challenges have been addressed so far 10III-A Complexity of Systems and System-
wide Optimization 10III-A1 Layered design 11III-A2 Component-based design 11III-A3 The V-model process 11III-A4 Model-Based Design 12III-A5 Virtual Integration 12III-A6 Platform Based Design 13
III-B Complexity of OEM-Supplier ChainsStandardization and Harmonization 13III-B1 Standardization of design
entities 13III-B2 Harmonization of processes
and certification 14III-C Managing Requirements Traceability
and Multiple Viewpoints 14III-D Cross-company Shared Risk Management 14III-E The Need for Contracts 15
IV Contracts what why where and how 16IV-A Contracts 16
IV-A1 Components and their Envi-ronment Contracts 16
IV-B Contract Operators 17IV-B1 Contract Composition and
System Integration 17IV-B2 Contract Refinement and In-
dependent Development 18IV-B3 Contract Conjunction and
Viewpoint Fusion 18IV-C Contracts in requirement engineering 19IV-D Contract Support for Design Method-
ologies 20IV-D1 Supporting open systems 20IV-D2 Managing Requirements and
Fusing Viewpoints 20IV-D3 Design Chain Management
Re-using and IndependentDevelopment 21
IV-D4 Deployment and Mapping 21IV-E Bibliographical note 23
V A Mathematical Meta-theory of Contracts 24V-A Components and their composition 24V-B Contracts 25V-C Refinement and conjunction 25V-D Contract composition 26V-E Quotient 27V-F Discussion 27V-G Observers 27V-H Bibliographical note 28
VI Panorama of concrete theories 29
VII Panorama AssumeGuarantee contracts 29VII-A Dataflow AG contracts 30VII-B Capturing exceptions 30VII-C Dealing with variable alphabets 31VII-D Synchronous AG contracts 32VII-E Observers 32VII-F Discussion 32VII-G Bibliographical note 32
VIII Panorama Interface theories 33VIII-A Components as io-automata 33VIII-B Interface Automata with fixed alphabet 34VIII-C Modal Interfaces with fixed alphabet 35VIII-D Modal Interfaces with variable alphabet 37VIII-E Projecting and Restricting 38VIII-F Observers 40VIII-G Bibliographical note 40
IX Panorama Timed Interface Theories 42IX-A Components as Event-Clock Automata 42IX-B Modal Event-Clock Specifications 43IX-C Bibliographical note 43
X Panorama Probabilistic Interface Theories 44X-A Components as Probabilistic Automata 44X-B Simple Modal Probabilistic Interfaces 45X-C Bibliographical note 45
XI The Parking Garage an example in Require-ments Engineering 45
XI-A The contract framework 45XI-B Top level requirements 46XI-C Formalizing requirements as contracts 46XI-D Sub-contracting to suppliers 48XI-E The four ldquoCrdquo 49
XI-E1 Consistency amp Compatibility 49XI-E2 Correctness 50XI-E3 Completeness 50
XI-F Discussion 50
RR ndeg 8147
Contracts for System Design 5
XII Contracts in the context of AUTOSAR 50XII-A The AUTOSAR context 50XII-B The contract framework 51XII-C Exterior Light Management System 51
XII-C1 Function and timing 51XII-C2 Safety 56
XII-D Integrating Contracts in AUTOSAR 58XII-E Summary and discussion 59
XIII Conclusion 59XIII-A What contracts can do for the designer 59XIII-B Status of research 59XIII-C Status of practice 59XIII-D The way forward 59
References 60
RR ndeg 8147
Contracts for System Design 6
I INTRODUCTION
A The Present System Design
System companies such as automotive avionics and con-sumer electronics companies are facing significant difficultiesdue to the exponentially raising complexity of their productscoupled with increasingly tight demands on functionalitycorrectness and time-to-market The cost of being late tomarket or of imperfections in the products is staggering aswitnessed by the recent recalls and delivery delays that systemindustries had to bear
In 2010 Toyota had to recall 10 Million cars worldwidefor reasons that ranged from the infamous sticky acceleratorpedals to steering and engine problems The last recall atthe end of August 2010 was for the engine control moduleToyota is not alone in this situation Most of the automotivemakers had one or more major recalls in the recent past(see eg httpwwwautorecallsus) involving electronics aswell as mechanical parts Boeing and Airbus Industries hadsignificant delays in the delivery of their latest planes (787and A380) For the A380 underlying causes were cited asissues in the cabling system configuration management anddesign process In particular the complexity of the cabinwiring (100000 wires and 40300 connectors) was considereda major issue (see httpenwikipediaorgwikiAirbus_A380)The delays caused the departure of both the EADS and AirbusCEOs and of the program manager for the A380 and caused anoverall earning shortfall of 48 Billion Euros Boeing originallyplanned the first flight of the 787 for August 2007 (seehttpenwikipediaorgwikiBoeing_787) but after a streamof delay announcements the actual first flight occurred onDecember 15 2009 The delays were caused by a number ofunfortunate events and design errors and caused at least a 23Billion USD write-off not counting the claim of Air India of1 Billion USD damages for delayed delivery and the revenueshortfalls
These are examples of the devastating effects that designproblems may cause The specific root causes of these prob-lems are complex and relate to a number of issues rangingfrom design processes and relationships with different depart-ments of the same company and with suppliers to incompleterequirement specification and testing
B The Future CPS and SoS
Many products and services require to take into considera-tion the interactions of computational and physical processesSystems where this interaction is tight and needs special careare called Cyber-Physical Systems (CPS) [133] The broadmajority of these new applications can be classified as ldquodis-tributed sense and control systemsrdquo that go substantially be-yond the ldquocomputerdquo or ldquocommunicaterdquo functions traditionallyassociated with information technology These applicationshave the potential to radically influence how we deal with abroad range of crucial problems facing our society today forexample national security and safety including surveillanceenergy management and distribution environment control
efficient and reliable transportation and mobility and effectiveand affordable health care A recurring property of theseapplications is that they engage all the platform componentssimultaneouslymdashfrom data and computing services on thecloud of large-scale servers data gathering from the sensoryswarm and data access on mobile devicesmdashwith significantheterogeneity These large scale systems composed of subsys-tems that are themselves systems are now called Systems ofSystems (SoS) and are heavily investigated
As the complexity of these systems increases our inabilityto rigorously model the interactions between the physical andthe cyber sides creates serious vulnerabilities Systems becomeunsafe with disastrous inexplicable failures that could not havebeen predicted The challenges in the realization and operationof these CPS and SoS are manifold and cover a broad range oflargely unsolved design and run-time problems These includemodeling and abstraction verification validation and testreliability and resiliency multi-scale technology integrationand mapping power and energy security diagnostics andrun-time management Failure to address these challengesin a cohesive and comprehensive way will most certainlydelay if not prohibit the widespread adoption of these newtechnologies
C The Need for a Methodological Effort
We believe the most promising means to address the chal-lenges in systems engineering is to employ structured andformal design methodologies that seamlessly and coherentlycombine the various dimensions of the design space (be itbehavior space or time) that provide the appropriate abstrac-tions to manage the inherent complexity and that can pro-vide correct-by-construction implementations The followingtechnology issues must be addressed when developing newapproaches to the design of complex systems CPS and SoSbull The overall design flows for heterogeneous systemsmdash
meant here both in a technical and also an organiza-tional sensemdashand the associated use of models acrosstraditional boundaries are not well developed and un-derstood Relationships between different teams inside asame company or between different stake-holders in thesupplier chain are not well supported by solid technicaldescriptions for the mutual obligations
bull System requirement capture and analysis is in largepart a heuristic process where the informal text andnatural language-based techniques in use today are facingsignificant challenges Formal requirement engineeringis in its infancy mathematical models formal analysistechniques and links to system implementation must bedeveloped
bull Dealing with variability uncertainty and life-cycle issuessuch as extensibility of a product family are not well-addressed using available systems engineering methodol-ogy and tools
bull Design-space exploration is rarely performed adequatelyyielding suboptimal designs where the architecture se-lection phase does not consider extensibility re-usability
RR ndeg 8147
Contracts for System Design 7
and fault tolerance to the extent that is needed to reducecost failure rates and time-to-market
bull The verification and validation of ldquocomplex systemsrdquoparticularly at the system integration phase where anyinteractions are complicated and extremely costly toaddress is a common need in defense automotive andother industries
The challenge is to address the entire process and not toconsider only point solutions of methodology tools andmodels that ease part of the design
D Contract based design
It is our goal to offer a new approach to the system designproblem that is rigorous and effective in dealing with theproblems and challenges described before and that at thesame time does not require a radical change in the wayindustrial designers carry out their task as it cuts across designflows of different type contract-based design
Contracts in the layman use of the term are establishedwhen an OEM must agree with its suppliers on the subsystemor component to be delivered Contracts involve a legal partbinding the different parties and a technical annex that servesas a reference regarding the entity to be delivered by thesuppliermdashin this work we focus on the technical facet ofcontracts Contracts can also be used through their technicalannex in concurrent engineering when different teams developdifferent subsystems or different aspects of a system within asame company
In this paper we argue that contracts can be actually usedalmost everywhere and at nearly all stages of system designfrom early requirements capture to embedded computinginfrastructure and detailed design involving circuits and otherhardware Contracts explicitly handle pairs of properties re-spectively representing the assumptions on the environmentand the guarantees of the system under these assumptionsIntuitively a contract is a pair
C = (AG) of Assumptions Guarantees
characterizing in a formal way 1) under which context thedesign is assumed to operate and 2) what its obligations areAssumeGuarantee reasoning has been known for quite sometime but it has been used mostly as verification mean for thedesign of software Our purpose is more ambitious contractbased design with explicit assumptions is a philosophy thatshould be followed all along the design with all kinds ofmodels whenever necessary Here the models we mean arerichmdashnot only profiles types or taxonomy of data but alsomodels describing the functions performances of variouskinds (time and energy) and safety The consideration of richcontracts as above in the industry is still in its infancy Tomake contract-based design a technique of choice for systemengineers we must developbull Mathematical foundations for contract representation and
requirement engineering that enable the design of frame-works and tools
bull A system engineering framework and associated method-ologies and tool sets that focus on system requirementmodeling contract specification and verification at mul-tiple abstraction layers The framework should addresscross-boundary and cross-organizational design activities
This paper intends to provide a unified treatment of contractswhere they are precisely defined and characterized so that theycan be used in design with no ambiguity In addition the paperprovides an important link between interfaces and contractsto show similarities and correspondences Examples of the useof contracts in design will be provided as well as in depthanalysis of existing literature
E Readerrsquos guide
The organization of the paper is explained in Table IIn Section II a review of the challenges that are faced by the
system industry is proposed followed in Section III by ananalysis of the design methodologies that have been deployedto cope with them
Section IV develops a primer on contracts by using a verysimple example requiring only elementary mathematical back-ground to be followed Its purpose is to smoothly introducethe different concepts and operations we need for a contractframeworkmdashthe restricted case considered is by no meansrepresentative of the kind of system we can address usingcontracts We then introduce a motivating example repre-sentative of requirement engineering In a third sub-sectionldquorequirementsrdquo on a theory of contracts are identified fromanalyzing what is expected from contract-based design andin particular the support for 1) the development of differentaspects or viewpoints of a system such as its function safetytiming and resource use by different teams and how to fusethese different aspects and 2) the possibility for differentsuppliers to develop independently the different subsystemssubcontracted to them This section concludes with the relatedbibliography
Section V is the cornerstone of this paper and it is a newvista on contracts The so-called ldquometa-theoryrdquo of contractsis introduced and developed in detail By meta-theory wemean the collection of concepts operations and propertiesthat any formal contract framework should offer Conceptsoperations and properties are thus stated in a fairly genericway Every concrete framework compliant with this meta-theory will inherit these generic properties The meta-theoryfocuses on assumptions and guarantees its formalizes howdifferent aspects or viewpoints of a specification can beintegrated and on which basis independent development bydifferent suppliers can be safely performed
So far the meta-theory is non effective in that it is notsaid how component and contracts are effectively representedand manipulated The subsequent series of sections propose apanorama of major concrete contract frameworks Section VIIdevelops the AssumeGuarantee contracts This framework isthe most straightforward instance of the meta-theory It dealswith pairs (AG) of assumptions and guarantees explicitlyA and G being both expressed as properties This framework
RR ndeg 8147
Contracts for System Design 8
Section methodological tutorial fundamental technical applicationSection IIchallengesSection IIIaddressing the challengesSection IVwhy contracts where and how
Section Vcontract meta-theory
Section VIIAssumeGuarantee contractsSection VIIIInterface theoriesSection IXtimedSection Xprobabilistic
Section XIrequirements engineeringSection XIIAUTOSAR
Section IIdarr
Section III Section IV
Section V Section VII mdash Section VIIIdarr darr
Section XII Section XI
Section IX mdash Section Xdarr darr
Section Section
Section IIdarr
Section III Section IV
Section V Section XI Section XII
Table IREADERrsquoS GUIDE CATEGORIZATION OF THE DIFFERENT SECTIONS (TOP) AND
DEPENDENCIES (BOTTOM LEFT IN-DEPTH READING BOTTOM-RIGHT QUICK READING)
is flexible in that it allows for different styles of descriptionof such propertiesmdashcomputational efficiency depends on thestyle adopted Section VIII develops the Interface theoriesin which assumptions and guarantees are specified by meansof a single object the interface Interface theories turn outto include the most effective frameworks They can easily beadapted to encompass timing (Section IX) and probabilistic(Section X) characteristics of systems
In Section XI a toy example in requirements engineeringis developed This example is simple but rich enough to illus-trate the very difficulties in formalizing requirements It alsoillustrates well the added value of contract based requirementsengineering First the different responsibilities (assumptionsversus obligation or guarantees) that requirement implicit referto are made explicit and captured in our contract frameworkSecond contracts offer a formal meaning for documents ofrequirements structured into chapters or viewpoints Contractsoffer formal support for checking important properties suchas consistency compatibility completeness and more Finallycontracts offer significant assistance in the process of deduc-ing from the top specification an architecture of specificationsfor the different sub-systems for independent developmentWhile our application example is a toy one is it neverthelesstoo complex for dealing with it by hand We handle it by usinga proof-of-concept tool for contract management
Finally Section XII develops a case study in the contextof AUTOSAR AUTOSAR is a recently established standardin the automobile sector This standard was developed withthe objective of allowing for better flexibility in componentreuse and OEMsupplier relations This section illustrates howcontracts can be used to break into simple pieces of reasoningthe difficult task of correct system integration
II SYSTEM DESIGN CHALLENGES
Many challenges face the system community to deliverproducts that are reliable and effective We summarize someof them below
A Complexity of Systems
The ever-expanding use of electronic embedded systems tocontrol increasingly many aspects of the real world and thetrend to interconnect more and more such systems (often fromdifferent manufacturers) into a global network are creating achallenging scenario for system designers In this scenario thethree challenges that are taking center stage are as follows
The Hardware Platform Complexity Most system com-panies rely on Components off-the-shelf (COTS) and pro-grammability to implement their applications For companieswho build ldquophysically largerdquo systems such as avionics and au-tomotive companies the complexity of the hardware platform
RR ndeg 8147
Contracts for System Design 9
Design task Tasks Tasks Tasks Tasks Tasks Tasksdelayed delayed delayed causing delay causing delay causing delayautomotive automation medical automotive automation medical
System integration 630 565 667 423 190 375test and verificationSystem architecture 296 261 333 385 429 313design and specificationSoftware application 444 304 750 269 310 250andor middlewaredevelopment and testProject management 370 283 167 538 381 375and planning
Table IIDIFFICULTIES RELATED TO SYSTEM INTEGRATION
is reflected in the number of Electronic Control Units and intheir interconnections For a top-of-the-line automobile thenumber of processors to manage and interconnect is above50 The layout of the cables that connect these processingelements with sensors and actuators is a serious concern Initialproduction of the Airbus A380 was troubled by delays in partattributed to the 530 km (330 mi) of wiring in each aircraft
The Embedded Software Complexity Given the cost andrisks associated to developing hardware solutions system com-panies are selecting hardware platforms that can be customizedby reconfiguration andor by software programmability Inparticular software is taking the lionrsquos share of the implemen-tation budgets and cost In cell phones more than 1 millionlines of code is standard today while in automobiles theestimated number of lines by 2010 is in the order of hundredsof millions and in the Boeing 787 is in the order of 20 millionlines However as this happens the complexity explosion ofthe software component causes serious concerns for the finalquality of the products and the productivity of the engineeringteams
The Integration Complexity A standard technique to dealwith complexity consists in decomposing top-down the systeminto subsystems This approach which has been customar-ily adopted by the semiconductor industry for years has alimitation as a designer or a group of designers has to fullycomprehend the entire system and to partition appropriately itsvarious parts a difficult task given the enormous complexityof todayrsquos systems
Hence the future is one of developing systems by compos-ing pieces that all or in part have already been predesignedor designed independently by other design groups or evencompanies This has been done routinely in vertical designchains for example in the avionics and automotive sectorsalbeit in a heuristic and ad hoc way The resulting lack of anoverall understanding of the interplay of the subsystems and ofthe difficulties encountered in integrating very complex partscause system integration to become a nightmare in the systemindustry as demonstrated by Table II1
In addition heterogeneity comes into play Integration of
1VDC research Track 3 Embedded Systems Market Statistics Exhibit II-13from volumes on automotiveindustrial automationmedical 2008
electronic and mechanical design tools and frameworks will beessential in the near future Integration of chemical electronicand biology tools will be essential in the further future fornano-systems Data integration and information flow amongthe companies forming the chain have to be supported Inother words it is essential that the fundamental steps of systemdesign (functional partitioning allocation on computationalresources integration and verification) be supported acrossthe entire design development cycle and across different dis-ciplines
B Complexity of OEM-Supplier Chains
The source of the above problems is clearly the increase incomplexity It is however also the difficulty of the OEMs inmanaging the integration and maintenance process with sub-systems that come from different suppliers who use differentdesign methods different software architectures and differenthardware platforms
There are also multiple challenges in defining technicalannexes to commercial contracts between OEM and suppli-ers Specifications used for procurement should be preciseunambiguous and complete However a recurrent reason forfailures causing deep iterations across supply chain boundariesrests in incomplete characterizations of the environment ofthe system to be developed by the supplier such as missinginformation about failure modes and failure rates missing in-formation on possible sources for interferences through sharedresources and missing boundary conditions This highlightsthe need to explicate assumptions on the design context inOEM-supplier commercial contracts In light of an increasedsharing of hardware resources by applications developed bymultiple suppliers a contract-based approach seems indispens-able for resolving liability issues and allowing applicationswith different criticality levels to co-exist (such as ASILlevels[175] [13] in automotive)
C Managing Requirements
We argued that the design chains should connect seamlesslyto minimize design errors and time-to-market delays Yet theboundaries among companies and between different divisionsof the same company are often not as clean as needed anddesign specs move from one company (or one division) to the
RR ndeg 8147
Contracts for System Design 10
next in non-executable and often unstable and imprecise formsthus yielding misinterpretations and consequent design errorsIn addition errors are often caught only at the final integrationstep as the specifications were incomplete and imprecisefurther nonfunctional specifications (eg timing power con-sumption size) are difficult to trace Further it is commonpractice to structure system level requirements into severalldquochaptersrdquo ldquoaspectsrdquo or ldquoviewpointsrdquo Examples include thefunctions safety timing and energy viewpoints Quite oftenthese different viewpoints are developed by different teamsusing different skills frameworks and tools Yet they are notunrelated as we already mentioned Without a clean approachto handle multiple viewpoints the only sensible way is tocollect these viewpoints into a single requirements documentwhich is then seen as a flat collection of requirements forsubsequent design Since this is clearly impracticable thecommon practice instead is to discard some of the viewpointsin a first stage eg by considering only functions and safetyDesigns are then developed based on these only viewpointsOther viewpoints are subsequently taken into account (timingenergy) thus resulting in late and costly modifications andre-designs
Requirement engineering is a discipline that aims at improv-ing this situation by paying close attention to the managementof the requirement descriptions and traceability support (egusing commercial tools such as DOORS2 in combinationwith Reqtify3) and by inserting whenever possible preciseformulation and analysis methods and tools Research in thisarea is active but we believe more needs to be done to makethis essential step a first class citizen in system design Indeedif the specification quality is low then the entire design processis marred since the very beginning The overall system productspecification is somewhat of an art today since to verify itscompleteness and its correctness there is little that it can beused to compare with
D Managing Risks
System design processes are highly concurrent distributedand typically multi-domain often involving more than onehundred sub-processes The complexity of the entire designprocess and of the relationships between players in the supplychain creates the need to elaborate risk sharing and riskmanagement plans because of the potential enormity of theimpact that design errors and supplier solidity may have onthe economics of a company Risk management has thusbecome a requirement of most of public companies as fi-nancial social and political risks are analyzed and appropriatecountermeasures have to be prepared as a requirement fromthe regulatory bodies Risk mitigation measures typically coverall phases of design processes ranging from assuring highquality initial requirements to early assessments of risks inmeeting product requirements during the concept phase toenforcing complete traceability of such requirements with
2 httpwww-01ibmcomsoftwareawdtoolsdoorsproductline3httpetc
requirements management tools to managing consistency andsynchronization across concurrent sub-processes using PLMtools4 If we will be able to change the design processalong the lines of more formal approaches better complexityhandling better requirement engineering then risks will besubstantially lower than they are today
E System-wide Optimization
We believe that since the design process is fragmentedproduct optimization is rarely carried out across more thanone company boundary and even then it is limited due tobull The lack of appropriate models encompassing both func-
tional and non-functional (Quality of Service) aspectscovering both internal use and export outside the com-pany
bull The time pressure to meet the product deadlinesbull The functional description that is over-constrained by
architectural considerations which de facto eliminate po-tentially interesting implementation alternatives
If the design process were carried out as in a unique well-integrated virtual company including all the players shownabove the overall ecosystem would greatly benefit The issuehere is to allow a reasonably efficient design space explorationby providing a framework where different architectures couldbe quickly assembled and evaluated at each layer of abstractioncorresponding to the design task being considered in the chain
III HOW CHALLENGES HAVE BEEN ADDRESSED SO FAR
In this section we present a review and a critical analysisof the design methodologies that have been deployed to copewith the challenges exposed in the previous section
A Complexity of Systems and System-wide Optimization
Multiple lines of attack have been developed by researchinstitutions and industry to cope with the exponential growth insystems complexity starting from the iterative and incrementaldevelopment several decades ago [123] Among them ofparticular interest to the development of embedded controllersare Layered design Component-based design the V-modelprocess model-based development virtual integration andPlatform-Based Design (PBD) There are two basic princi-ples followed by these methods abstractionrefinement andcompositiondecomposition Abstraction and refinement areprocesses that relate to the flow of design between differentlayers of abstraction (vertical process) while compositionand decomposition operate at the same level of abstraction(horizontal process) Layered design the V-model processand model-based development focus on the vertical processwhile component-based design deals principally with the hor-izontal process PBD combines the two aspects in a unifiedframework and hence subsumes and can be used to integrated
4 PLM Product Lifecycle Management PLM centric design is used incombination with virtual modeling and digital mockups PLM acts as a database of virtual system components PLM centric design is for exampledeployed at Dassault-Aviation httpwwwdassault-aviationcomenaviationinnovationthe-digital-companydigital-designplm-toolshtmlL=1
RR ndeg 8147
Contracts for System Design 11
the other methodologies Contracts are ideal tools to solidifyboth vertical and horizontal processes providing the theoreticalbackground to support formal methods
1) Layered design Layered design copes with complexityby focusing on those aspects of the system pertinent to supportthe design activities at the corresponding level of abstractionThis approach is particularly powerful if the details of alower layer of abstraction are encapsulated when the designis carried out at the higher layer Layered approaches are wellunderstood and standard in many application domains Asan example consider the AUTOSAR standard5 This standarddefines several abstraction layers Moving from ldquobottomrdquoto ldquotoprdquo the micro-controller abstraction layer encapsulatescompletely the specifics of underlying micro-controllers thesecond layer abstracts from the concrete configuration of theElectronic Control Unit (ECU) the employed communicationservices and the underlying operating system whereas the(highest) application layer is not aware of any aspect ofpossible target architectures and relies on purely virtual com-munication concepts in specifying communication betweenapplication components Similar abstraction levels are definedby the ARINC standard in the avionic domains
The benefits of using layered design are manifold Using theAUTOSAR layer structure as example the complete separationof the logical architecture of an application (as represented bya set of components interconnected using the so-called virtualfunction bus) and target hardware is a key aspect of AUTOSARin that it supports decoupling of the number of automotivefunctions from the number of hardware components In par-ticular it is flexible enough to mix components from differentapplications on one and the same ECU This illustrates thedouble role of abstraction layers in allowing designers to focuscompletely on the logic of the application and abstracting fromthe underlying hardware while at the same time imposing aminimal (or even no) constraint on the design space of possiblehardware architectures In particular these abstractions allowthe application design to be re-used across multiple platformsvarying in number of bus-systems andor number and class ofECUs These design layers can in addition be used to matchthe boundaries of either organizational units within a companyor to define interfaces between different organizations in thesupply chain The challenge then rests in providing the properabstractions of lower-level design entities
2) Component-based design Whereas layered designs de-compose complexity of systems ldquoverticallyrdquo component-basedapproaches reduce complexity ldquohorizontallyrdquo whereby designsare obtained by assembling strongly encapsulated design enti-ties called ldquocomponentsrdquo equipped with concise and rigorousinterface specifications Re-use can be maximized by findingthe weakest assumptions on the environment sufficient to es-tablish the guarantees on a given component implementationWhile these interface specifications are key and relevant forany system the ldquoquality attributerdquo of perceiving a subsystemas a component is typically related to two orthogonal criteria
5See httpwwwautosarorg
that of ldquosmall interfacesrdquo and that of minimally constrainingthe deployment context so as to maximize the potential for re-use ldquoSmall interfacesrdquo ie interfaces which are both smallin terms of number of interface variables or ports as wellas ldquologically smallrdquo in that protocols governing the invoca-tion of component services have compact specifications notrequiring deep levels of synchronization constitute evidenceof the success of encapsulationmdashstill small interfaces mustencompass dynamic properties of the system The secondquality attribute is naturally expressible in terms of interfacespecifications where re-use can be maximized by finding theweakest assumptions on the environment sufficient to establishthe guarantees on a given component implementation
One challenge then for component-based design of em-bedded systems is to provide interface specifications that arerich enough to cover all phases of the design cycle Thiscalls for including non-functional characteristics as part ofthe component interface specifications which is best achievedby using multiple viewpoints Current component interfacemodels in contrast are typically restricted to purely functionalcharacterization of components and thus cannot capitalize onthe benefits of virtual integration testing as outlined above
The second challenge is related to product line designwhich allows for the joint design of a family of variants of aproduct The aim is to balance the contradicting goals of striv-ing for generality versus achieving efficient component im-plementations Methods for systematically deriving ldquoquotientrdquospecifications to compensate for ldquominorrdquo differences betweenrequired and offered component guarantees by composing acomponent with a wrapper component (compensating for suchdifferences as characterized by quotient specifications) existsfor restricted classes of component models [155]
3) The V-model process A widely accepted approach todeal with complexity of systems in the defense and trans-portation domain is to structure product development processesalong variations of the V diagram originally developed fordefense applications by the German DoD6
Its characteristic V-shape splits the product developmentprocess into a design and an integration phase Specificallyfollowing product level requirement analysis subsequent stepswould first evolve a functional architecture supporting productlevel requirements Sub-functions are then re-grouped takinginto account re-use and product line requirements into alogical architecture whose modules are typically developed bydifferent subsystem suppliers The realization of such modulesoften involves mechanical hydraulic electrical and electronicsystem design Subsequent phases would then unfold thedetailed design for each of these domains such as the designof the electronic subsystem involving among others the designof electronic control units These design phases are paralleledby integration phases along the right-hand part of the Vsuch as integrating basic- and application software on theECU hardware to actually construct the electronic control unitintegrating the complete electronic subsystems integrating the
6See eg httpwwwv-model-xtde
RR ndeg 8147
Contracts for System Design 12
mechatronic subsystem to build the module and integratingmultiple modules to build the complete product Not shownbut forming an integral part of V-based development processesare testing activities where at each integration level test-suites developed during the design phases are used to verifycompliance of the integrated entity to their specification
This presentation is overly simplistic in many ways Thedesign of electronic components in complex systems suchas aircrafts inherently involves multi-site multi-domain andcross-organizational design teams reflecting eg a partition-ing of the aircraft into different subsystems (such as primaryand secondary flight systems cabin fuel and wing) differentdomains such as the interface of the electronic subsystem tohydraulic andor mechanical subsystems control-law designtelecommunications software design hardware design diag-nostics and development-depth separated design activities car-ried out at the OEM and supplier companies This partitioningof the design space (along perspectives and abstraction layers)naturally lends itself to a parallelization of design activitiesa must in order to achieve timely delivery of the overallproduct leading often into the order of hundreds of concurrentdesign processes To summarize while being popular andwidely referenced the V-model process has become a ldquosloganrdquohiding the complexity of actual design processes In realitylarge system companies develop their own processes and thenstruggle for their application both in-house and across thesupplier chain
4) Model-Based Design Model-based design (MBD) is to-day generally accepted as a key enabler to cope with complexsystem design due to its capabilities to support early require-ment validation and virtual system integration MBD-inspireddesign languages and tools such as SysML7 [149] andorAADL [152] for system level modeling Catia and Model-ica [93] for physical system modeling Matlab-Simulink [118]for control-law design and UML8 [44] [147] Scade [32]and TargetLink for detailed software design depend on de-sign layer and application class The state-of-the-art in MBDincludes automatic code-generation simulation coupled withrequirement monitoring co-simulation of heterogeneous mod-els such as UML and Matlab-Simulink model-based analy-sis including verification of compliance of requirements andspecification models model-based test-generation rapid pro-totyping and virtual integration testing as further elaboratedbelow
In MBD today non-functional aspects such as performancetiming power or safety analysis are typically addressed indedicated specialized tools using tool-specific models withthe entailed risk of incoherency between the correspond-ing models which generally interact To counteract theserisks meta-models encompassing multiple views of designentities enabling co-modeling and co-analysis of typicallyheterogeneous viewpoint specific models have been developedExamples include the MARTE UML [148] profile for real-time
7httpwwwomgorgspecSysML8httpwwwomgorgspecUML
system analysis the SPEEDS HRC metamodel [156] and theMetropolis semantic meta-model [19] [67] [16] [170] InMetropolis multiple views are accommodated via the conceptof ldquoquantitiesrdquo that annotate the functional view of a designand can be composed along with subsystems using a suitablealgebra The SPEEDS meta-model building on and extendingSysML has been demonstrated to support co-simulation andco-analysis of system models for transportation applicationsallowing co-assessment of functional real-time and safety re-quirements It forms an integral part of the meta-model-basedinter-operability concepts of the CESAR reference technologyplatform9
Meta-modeling is also at the center of the model driven(software) development (MDD) methodology MDD is basedon the concept of the model-driven architecture (MDA) whichconsists of a Platform-Independent Model (PIM) of the ap-plication plus one or more Platform-Specific Models (PSMs)and sets of interface definitions MDA tools then supportthe mapping of the PIM to the PSMs as new technologiesbecome available or implementation decisions change [146]The Vanderbilt University group [119] has evolved an em-bedded software design methodology and a set of tools basedon MDD In their approach models explicitly represent theembedded software and the environment it operates in andcapture the requirements and the design of the applicationsimultaneously using domain-specific languages (DSL) Thegeneric modeling environment (GME) [119] provides a frame-work for model transformations enabling easy exchange ofmodels between tools and offers sophisticated ways to sup-port syntactic (but not semantic) heterogeneity The KerMetametamodeling workbench [91] is similar in scope
5) Virtual Integration Rather than ldquophysicallyrdquo integratinga system from subsystems at integration stages model-baseddesign allows systems to be virtually integrated based on themodels of their subsystem and the architecture specificationof the system Such virtual integration thus allows detectingpotential integration problems up front in the early designphases Virtual system integration is often a source of het-erogeneous system models such as when realizing an aircraftfunction through the combination of mechanical hydraulicand electronic systems Heterogeneous composition of modelswith different semantics was originally addressed in Ptolemy[88] Metropolis [20] [67] [16] [48] and in the SPEEDSmeta-model of heterogeneous rich components [65] [29] [31]albeit with different approaches Virtual integration involvesmodels of the functions the computer architecture with itsextra-functional characteristics (timing and other resources)and the physical system for control Some existing frameworksoffer significant support for virtual integration Ptolemy IIMetropolis and RT-Builder Developments around Catia andModelica as well as the new offer SimScape by Simulinkprovide support for virtual integration of the physical part atan advanced level
9wwwcesarprojecteu
RR ndeg 8147
Contracts for System Design 13
6) Platform Based Design Platform-based design was in-troduced in the late 1980s to capture a design process thatcould encompass horizontal (component-based design virtualintegration) and vertical (layered and model-based design)decompositions and multiple viewpoints and in doing sosupport the supply chain as well as multi-layer optimization
The idea was to introduce a general approach that couldbe shared across industrial domain boundaries that wouldsubsume the various definition and design concepts and thatwould extend it to provide a framework to reason aboutdesign Indeed the concepts have been applied to a variety ofvery different domains from automotive to System-on-Chipfrom analog circuit design to building automation to syntheticbiology
The basic tenets of platform-based design are as followsThe design progresses in precisely defined abstraction layersat each abstraction layer functionality (what the system issupposed to do) is strictly separated from architecture (howthe functionality could be implemented) This aspect is clearlyrelated to layered design and hence it subsumes it
Each abstraction layer is defined by a design platform Adesign platform consists ofbull A set of library components This library not only con-
tains computational blocks that carry out the appropriatecomputation but also communication components that areused to interconnect the computational components
bull Models of the components that represent a characteri-zation in terms of performance and other non-functionalparameters together with the functionality it can supportNot all elements in the library are pre-existing com-ponents Some may be ldquoplace holdersrdquo to indicate theflexibility of ldquocustomizingrdquo a part of the design that isoffered to the designer In this case the models representestimates of what can be done since the components arenot available and will have to be designed At times thecharacterization is indeed a constraint for the implementa-tion of the component and it is obtained top-down duringthe refinement process typical of layered designs Thislayering of abstractions based on mathematical models istypical of model-based methods and the introduction ofnon-functional aspects of the design relates to viewpoints
bull The rules that determine how the components can beassembled and how the the functional and non-functionalcharacteristics can be computed given the ones of thecomponents to form an architectureThen a platformrepresents a family of designs that satisfies a set ofplatform-specific constraints [15] This aspect is relatedto component-based design enriched with multiple view-points
This concept of platform encapsulates the notion of re-use asa family of solutions that share a set of common features (theelements of the platform) Since we associate the notion ofplatform to a set of potential solutions to a design problem weneed to capture the process of mapping a functionality (whatthe system is supposed to do) with the platform elements thatwill be used to build a platform instance or an ldquoarchitecturerdquo
(how the system does what it is supposed to do) The strictseparation between function and architecture as well as themapping process have been highly leveraged in AUTOSARThis process is the essential step for refinement and provides amechanism to proceed towards implementation in a structuredway Designs on each platform are represented by platform-specific design models A design is obtained by a designerrsquoscreating platform instances (architectures) via composing plat-form components (process that is typical of component-baseddesign) by mapping the functionality onto the components ofthe architecture and by propagating the mapped design in thedesign flow onto subsequent abstraction layers that are dealtwith in the same way thus presenting the design process asan iterative refinement This last point dictates how to moveacross abstraction layers it is an important part of design spaceexploration and offers a way of performing optimization acrosslayers In this respect PBD supports multiple viewpoints in ageneral way
B Complexity of OEM-Supplier Chains Standardization andHarmonization
So far the main answer to the complexity of OEM-supplierchains has been standardization Standardization concerns boththe design entities and the design processes particularlythrough the mechanism of certification
1) Standardization of design entities By agreeing on (do-main specific) standard representations of design entitiesdifferent industrial domains have created their own linguafranca thus enabling a domain wide shared use of designentities based on their standardized representation Exam-ples of these standards in the automotive sector include therecently approved requirement interchange format standardRIF10 the AUTOSAR11 de-facto standard the OSEK12 operat-ing system standard standardized bus-systems such as CAN13
and Flexray14 standards for ldquocar2Xrdquo communication andstandardized representations of test supported by ASAM15Examples in the aerospace domain include ARINC stan-dards16 such as the avionics applications standard interfaceIMA RTCA17 communication standards In the automationdomain standards for interconnection of automation devicessuch as Profibus18 are complemented by standardized designlanguages for application development such as Structured Text
As standardization moves from hardware to operating sys-tem to applications and thus crosses multiple design layersthe challenge increases to incorporate all facets of designentities required to optimize the overall product while atthe same time enabling distributed development in complex
10httpwwww3org2005ruleswikiRIF_Working_Group11httpwwwautosarorg12httpwwwosek-vdxorg13httpwwwisoorgisosearchhtmqt=Controller+Area+
NetworkampsearchSubmit=Searchampsort=relamptype=simpleamppublished=true14httpwwwflexraycom15httpwwwasamnet16httpwwwaeec-amc-fsemccomstandardsindexhtml17httpwwwrtcaorg18httpwwwprofibuscom
RR ndeg 8147
Contracts for System Design 14
supply chains As an example to address the different view-points required to optimize the overall product AUTOSARextended in transitioning from release 31 to 4 its capabilityto capture timing characteristics of design entities a keyprerequisite for assessing alternate deployments with respectto their impact on timing More generally the need for overallsystem optimization calls for the standardization of all non-functional viewpoints of design entities an objective yet tobe achieved in its full generality in order to allow crosslayer optimization Within the EDA domain such richnessof design interface specifications is industrial practice Withinthe systems domain the rich component model introduced inthe Integrated Projects SPEEDS tackles this key objective incovering multiple design layers (from product requirements todeployment on target architectures) and in providing means ofassociating multiple viewpoints with each design entity it isexpressive enough to allow for cross-supply chain optimizationof product developments This approach is further elaboratedand driven towards standardization in the Artemis flagshipproject CESAR
2) Harmonization of processes and certification Harmo-nizing or even standardizing key processes (such as devel-opment processes and safety processes) provides for a fur-ther level of optimization in interactions across the supplychain As an example Airbus Directives and Procedures(ADBs) provide requirements for design processes of equip-ment manufactures Often harmonized processes across thesupply chain build on agreed maturity gates with incrementalacceptance testing to monitor progress of supplier developmenttowards final acceptance often building on incremental proto-types Shared use of Product Lifcycle Management (PLM)19
databases across the supply chain offers further potentialsfor cross-supply chain optimization of development processesAlso in domains developing safety related systems domainspecific standards clearly define the responsibilities and dutiesof companies across the supply chain to demonstrate func-tional safety such as in the ISO 2626220 for the automotivedomain IEC 6150821 for automation its derivatives CenelecEN 50128 and 5012622 for rail and Do 178 B23 for civilavionics
Yet the challenge in defining standards rests in balancingthe need for stability with the need of not blocking processinnovations As an example means for compositional con-struction of safety cases are seen as mandatory to reducecertification costs in the aerospace and rail domains Similarlythe potential of using formal verification techniques to copewith increasing system complexity is considered in the movefrom DO 178 B to DO 178 C standards
19See [162] and also footnote 420httpwwwisoorgisocatalogue_detailhtmcsnumber=4346421httpwwwiecchfunctionalsafety22httpwwwceneleceuCenelecCENELEC+in+actionWeb+Store
Standardsdefaulthtm23httpwwwdo178sitecom
C Managing Requirements Traceability and Multiple View-points
Depending on application domains up to 50 of all er-rors result from imprecise incomplete or inconsistent andthus unfeasible requirements Requirements are inherently illstructured They must address all aspects of the system andthus cannot be constrained by the lingua franca of a partic-ular domain They are fragmented in the form of large andsometimes huge DOORS files24 structured into viewpointsTwo issues have thus been identified by systems industries asessential for requirement management powerful and flexibletraceability tools to relate requirements between them and tolink them to tests for validation purposes and the developmentof domain specific ontologies as part of the PLM suiteFurther based on an assessment by the system companiesprocesses in the CESAR project25 and the German EmbeddedSystems Innovation alliance26 and building on the finding ofthe Integrated Project SPEEDS27 multiple viewpoints havebeen categorized into perspectives and aspects to provide asolid requirement and property modeling scaffold Perspectivesare viewpoints relevant to architecture modeling as carriedout by different stake-holders during the development processAspects are viewpoints that are orthogonal to the systemstructure Aspects are used to demonstrate compliance of thearchitecture to end-user concerns Example of aspects aresafety cost maintainability performance and weight Themeta-model underlying the CESAR RTP is able to maintainlinks such as the satisfy derive verify refine and allocaterelationships between design artifacts of different perspectivesand across abstraction layers
In addition to cope with the inherently unstructured prob-lem of (in)completeness of requirements industry has setup domain- and application-class specific methodologies Asparticular examples we mention learning process such asemployed by Airbus to incorporate the knowledge base ofexternal hazards from flight incidents the Code of Practiceproposed by the Prevent Project28 using guiding questions toassess the completeness of requirements in the concept phaseof the development of advanced driver assistance systemsUse-case analysis methods as advocated for UML baseddevelopment process follow the same objective All togetherrequirement engineering misses the support of formal ap-proaches for its structuring and analysis
D Cross-company Shared Risk Management
The realization of complex systems calls for design pro-cesses that mitigate risks in highly concurrent distributedand typically multi-domain engineering processes often in-volving more than one hundred sub-processes Risk mitigation
24Typical sub-systems in aeronautics would have a few thousands top-levelrequirements An aircraft can have up to several hundred thousands of them
25wwwcesarprojecteu26httpspes2020informatiktu-muenchende27httpwwwspeedseucom28Albert http
RR ndeg 8147
Contracts for System Design 15
measures typically cover all phases of design processes rang-ing from ensuring high quality initial requirements to earlyassessments of risks in realizability of product requirementsduring the concept phase to enforcing complete traceabilityof such requirements with requirements management tools tomanaging consistency and synchronization across concurrentsub-processes using PLM tools A key challenge rests inbalancing risk reduction versus development time and effortcompletely eliminating the risks stemming from concurrentengineering essentially requires a complete synchronizationalong a fine-grained milestone structure which would kill anydevelopment project due to the induced delays Another keychallenge is the ldquonot my faultrdquo syndrome in the OEM-supplierchain when errors call for costly re-design and the issue ofpenalties arises Properly assigning responsibilities to risks isstill out of reach today
E The Need for Contracts
The way system design challenges have been addressed sofar leaves huge opportunities for improvements by relying oncontract-based design In this section we briefly summarizefor each existing approach to address the design challengeshow contracts could improve the current situation
Contribution 1 Addressing Complexity of Systems andSystem-wide OptimizationWhile layered design (Section III-A1) and component baseddesign (Section III-A2) have been critical steps in breakingsystems complexity they do not by themselves provide theultimate answer When design is being performed at a consid-ered layer implicit assumptions regarding other layers (egcomputing resources) are typically invoked by the designerwithout having these explicated Hence actual properties ofthese other layers cannot be confronted against these hiddenassumptions Similarly when components or sub-systems areabstracted via their interfaces in component based design itis generally not true that such interfaces provide sufficientinformation for other components to be safely implementedbased on this sole interface Contract-based design providesthe due discipline concepts and techniques to cope with thesedifficulties
Model-based development (Section III-A4) has reached sig-nificant maturity by covering nearly all aspects of the system(physics functions computing resources) albeit not yet in afully integrated way To offer a real added value any newlyproposed technology should be rich enough for encompassingall these aspects as well Contract-based design offers in largepart this desirable feature
Virtual integration and virtual modeling (Section III-A5) isa step beyond basic model-based development by offering anintegrated view of all the above different aspects eg physics+ functions + performances Contract-based design supportsthe fusion of different systems aspects
Contract-based design is compliant with the V-model pro-cess (Section III-A3) just because it does not impose anyparticular design process Using contracts only imposes a
small set of rules that any process should accommodate seeSection IV-D for a discussion of this
Finally Platform-Based Design (PBD Section III-A6)which is being deployed in some large systems industries suchas United Technologies Corporation (UTC) is a systematicand comprehensive methodology that unifies the various de-sign methodologies that have been described in this sectionContracts offer theory and methodological support for boththe successive refinement aspect the composition aspect andthe mapping process of PBD allowing formal analysis andsynthesis processes
Contribution 2 Addressing the Complexity of OEM-Supplier ChainsThe problems raised by the complexity of OEM-SupplierChains (Section II-B) are indeed the core target of contract-based design By making the explication of implicit assump-tions mandatory contracts help assigning responsibilities toa precise stake holder for each design entity By supportingindependent development of the different sub-systems whileguaranteing smooth system integration they orthogonalize thedevelopment of complex systems Contracts are thus adequatecandidates for a technical counterpart of the legal bindingsbetween partners involved in the distributed and concurrentdevelopment of a system
Contribution 3 Managing RequirementsSo far the task of getting requirements right and managingthem well (Section III-C) has only got support for sortingthe complexity out (traceability services and ontologies whichis undoubtely necessary) However requirements can only betested on implementations and it is not clear whether properdistinctions are made when performing tests regarding thefollowing fusing the results of tests associated to differentchapters or viewpoints of a requirement document versusfusing the results of tests associated to different sub-systemstesting a requirement under the responsibility of the designerof the considered sub-system versus testing a requirementcorresponding to an assumption regarding the context of useof this sub-systemmdashsuch distinctions should be made as weshall see Also requirements are barely executable and cannotin general be simulated Requirements engineering is the otherprimary target of contract-based design the above issues areproperly handled by contracts and contracts offer improvedsupport for evidencing the satisfaction of certification con-straints
Contribution 4 Managing RisksRisk metrics and risk mitigation measures are the essentialtools in managing risks (Section III-D) By offering improvedsupport for sub-contracting and distributing design to differentteams contracts are likely to significantly reduce the ldquonot myfaultrdquo syndrome
Contribution 5 Addressing CertificationAs explained in Section III-B2 the design of critical sys-tems is subject to a number of certification standards Whilecertification steps are mostly concerned with the processesnot the designs themselves the recent move from DO 178Bto DO 178C for level A critical systems in aeronautics has
RR ndeg 8147
Contracts for System Design 16
shown for the first time the consideration of formal proofsor validations as valid evidences We believe that the samewill eventually hold for contracts In particular by providingadequate formal support for completeness consistency com-patibility and more for sets of requirements contracts wouldprovide a valuable contribution to certification
IV CONTRACTS WHAT WHY WHERE AND HOWAs we argued in the previous section there are two basic
principles followed by design methods so far developed ab-stractionrefinement and compositiondecomposition Abstrac-tion and refinement are processes that relate to the flow of de-sign between different layers of abstraction (vertical process)while composition and decomposition operate at the same levelof abstraction (horizontal process) In this section we presentbriefly contracts and the basic operations they support andthen me make the point that contracts are ideal tools to solidifyboth vertical and horizontal processes providing the theoreticalbackground to support formal methods We conclude thesection by providing a (non exhaustive) bibliography on thegeneral concept of contract
A Contracts
Here we propose a ldquoprimerrdquo on contracts using a simpleexample as the reference for their use
1) Components and their Environment Contracts We startfrom a model that consists of a universal set M of com-ponents each denoted by the symbol M A component Mis typically an open system ie it contains some inputsthat are provided by other components in the system or theexternal world and it generates some outputs This collectionof other components and the exterior world is referred to as theenvironment of the component The environment is often notcompletely known when the component is being developedAlthough components cannot constrain their environment theyare designed to be used in a particular context
In the following example we define a component M1 thatcomputes the division between two real inputs x and y andreturns the result through the real output z The underlyingassumption is that M1 will be used within a design contextthat prevents the environment from giving the input y = 0Since M1 cannot constrain its input variables we handle theexceptional input y = 0 by generating an arbitrary output
M1
variables
inputs x y
outputs z
types x y z isin Rbehaviors (y 6= 0rarr z = xy) and (y = 0rarr z = 0)
A contract contract denoted by the symbol C is a de-scription of a component with the following characteristicproperties
1) Contracts are intentionally abstract2) Contracts distinguish responsibilities of a component
from that of its environmentProperty 1) of a contract highlights the goal of handlingcomplexity of the systems Thus contracts expose enough
information about the component but not more than necessaryfor the intended purpose We can see a contract as an under-specified description of a component that can be either veryclose to the actual component or specify only a singleproperty of a componentrsquos behavior Regarding Property 2)and in contrast to components a contract explicitly makes adistinction between assumptions made about the environmentand guarantees provided mirroring different roles and respon-sibilities in the design of systems
A contract can be implemented by a number of differentcomponents and can operate in a number of different envi-ronments Hence we define a contract C at its most abstractlevel as a pair C = (EC MC ) of subsets of components thatimplement the contract and of subsets of environments inwhich the contract can operate We say that a contract C isconsistent if MC 6= empty and compatible if EC 6= empty
This definition of contracts and the implementation relationis very general and as such it is not effective In concretecontract- based design theories a contract needs to have afinite description that does not directly refer to the actualcomponents and the implementation relation needs to beeffectively computable and establish the desired link betweena contract and the underlying components that implement it
For our present simple example of static systems wepropose the following way to specify contracts
C1
variables
inputs x y
outputs z
types x y z isin Rassumptions y 6= 0
guarantees z = xy
C1 defines the set of components having as variablesinputs x y output z of type real and whose behaviorssatisfy the implication
ldquoassumptionsrArr guaranteesrdquo
ie for the above example y 6= 0rArr z = xy Intuitivelycontract C1 specifies the intended behavior of components thatimplement division It explicitly makes the assumption that theenvironment will never provide the input y = 0 and leaves thebehavior for that input undefined
This contract describes an infinite number of environmentsin which it can operate namely the set EC1
of environmentsproviding values for x and y with the condition that y 6=0 Itdescribes an infinite number of components that implementthe above specification where the infinity comes from theunderspecified case on how an implementation of C1 shouldcope with the illegal input y = 0 In particular we have thatM1 implements C1 Thus contract C1 is consistent We nowshow a variant of contract C1 that is not consistent
Cprime1
variables
inputs x y
outputs z
types x y z isin Rassumptions T
guarantees z = xyRR ndeg 8147
Contracts for System Design 17
where symbol T denotes the boolean constant ldquotruerdquo Incontrast to C1 the contract Cprime1 makes no assumption on valuesof the input y Hence every component that implements Cprime1has to compute the quotient xy for all values of y includingy = 0 which makes no sense
B Contract Operators
There are three basic contract operators that are used insupport of the design methodologies we presented previouslycomposition refinement and conjunction
1) Contract Composition and System Integration Intu-itively the composition operator supports component-baseddesign and in general horizontal processes The compositionoperator that we denote by the symbol times is a partial functionon components The composition is defined with respect to acomposability criterion where two components M and M prime
are composable if their variable types match Composabilityis a syntactic property on pairs of components that definesconditions under which the two components can interactComposition times must be both associative and commutative inorder to guarantee that different composable components maybe assembled together in any order
Consider the component M2 defined as follows
M2
variables
inputs x
outputs y
types x y isin Rbehaviors y = ex
The component M2 computes the value of the output variabley as the exponential function of the input variable x M1 andM2 are they are composable since both common variables xand y have the same type x is an input variable to both M1
and M2 and the output variable y of M2 is fed as an input toM1 It follows that their composition M1 timesM2 has a singleinput variable x and computes the output z as a function ofx that is z = xex
Now consider component M prime2 that consists of an inputvariable x and an output variable z both of type real wherez = abs(x)
M prime2
variables
inputs x
outputs z
types x z isin Rbehaviors z = abs(x)
The component M prime2 is not composable with M1 becausethe two components share the same output variable z Theircomposition is illegal as it would result in conflicting rulesfor updating z
We now lift the above concepts to contracts The compo-sition operator between two contracts denoted by otimes shallbe a partial function on contracts involving a more subtlecompatibility criterion Two contracts C and Cprime are compatibleif their variable types match and if there exists an environmentin which the two contracts properly interact The resultingcomposition C otimes Cprime should specify through its assumptions
this set of environments By doing so the resulting contractwill expose how it should be used Unlike component com-posability contract compatibility is a combined syntactic andsemantic property
Let us formalize this For C a contract let AC and GC beits assumptions and guarantees and define
GC1otimesC2 = GC1andGC2
AC1otimesC2 = max
A∣∣∣∣∣∣AandGC2rArrAC1andAandGC1rArrAC2
(1)
where ldquomaxrdquo refers to the order of predicates by implica-tion thus AC1otimesC2 is the weakest assumption such that thetwo referred implications hold Thus this overall assumptionwill ensure that when put in the context of a componentimplementing the second contract then the assumption ofthe first contract will be met and vice-versa Since the twoassumptions were ensuring consistency for each contract theoverall assumption will ensure that the resulting compositionis consistent This definition of the contract compositiontherefore meets our previously stated requirements The twocontracts C1 and C2 are called compatible if the assumptioncomputed as in (1) differs from F the ldquo falserdquo predicate
Consider contracts C2 and Cprime2 that we define as follows
C2
variables
inputs u
outputs x
types u x isin Rassumptions T
guarantees x gt u
Cprime2
variables
inputs v
outputs y
types v y isin Rassumptions T
guarantees y = minusv
C2 specifies components that for any input value u generatesome output x such that x gt u and Cprime2 specifies componentsthat generate the value of the output variable y as functiony = minusv of the input v Observe that both C2 and Cprime2 areconsistent A simple inspection shows that C1 and C2 can becomposed and their composition yields
C1 otimes C2
variables
inputs u y
outputs x z
types x y u z isin Rassumptions y 6= 0
guarantees x gt u and z = xy
C1 and Cprime2 can also be composed and their composition yields
C1 otimes Cprime2
variables
inputs v x
outputs y z
types v x y z isin Rassumptions v 6= 0
guarantees y = minusv and z = xyRR ndeg 8147
Contracts for System Design 18
Both compositions possess a non-empty assumption (observealso that they are both free of exception) reflecting that thetwo pairs (C1 C2) and (C1 Cprime2) are compatible
In our example we require that compositions C1otimes(C2otimesC3)and (C1 otimes C2) otimes C3 result in equivalent contracts as well ascompositions C1otimesC2 and C2otimesC1 thus providing support forincremental system integration
A quotient operation can be defined that is dual to thecomposition operation Given a system-wide contract C anda contract C1 that specifies pre-existing components and theirinteractions the quotient operation CC1 defines the part ofthe system-wide contract that still needs to be implementedIt formalizes the practice of ldquopatchingrdquo a design to make itbehave according to another contract
2) Contract Refinement and Independent DevelopmentIn all vertical design processes the notions of abstractionand refinement play a central role The concept of contractrefinement must ensure the following if contract Cprime refinescontract C then any implementation of Cprime should 1) implementC and 2) be able to operate in any environment for C Hencethe following definition for refinement pre-order betweencontracts we say that the contract Cprime refines the contract C ifECprime supe EC andMCprime subeMC Since is a pre-order refinementis a transitive relation For our current series of examples andusing previous notations Cprime C amounts to requiring that 1AC implies ACprime and 2 ACprimerArrGCprime implies ACrArrGC
In Figure 4 we start with the contract C1 that representsthe general system-wide requirements We decompose theserequirements into requirements of three subsystems resultingin three contracts C11 C12 and C13 with the property thatC11otimesC12otimesC13 C1 Now these three contracts can be handedto different design teams and refined further independentlyIn particular C12 is further decomposed into contracts C121
and C122 such that C121 otimes C122 C12 and similarly C13 isfurther decomposed into contracts C131 and C132 such thatC131 otimes C132 C13
For all contracts C1 C2 Cprime1 and Cprime2 if C1 is compatible withC2 and Cprime1 C1 and Cprime2 C2 then Cprime1 is compatible with Cprime2and Cprime1 otimes Cprime2 C1 otimes C2
We now give a concrete example where we start withvery abstract requirements for a component that implementsa function z = xex Consider contracts Cprimeprime1 and Cprimeprime2 that wedefine as follows
Cprimeprime1
variables
inputs y
outputs z
types y z isin Rassumptions y 6= 0
guarantees z isin R
Cprimeprime2
variables
inputs x
outputs y
types x y isin Rassumptions T
guarantees y gt 0
The contract Cprimeprime1 formalizes the most crude and abstractrequirements for a divider It requires that the denominatorvalue (input variable y) is not equal to 0 and only ensuresthat the output value of z is any real Note that the contractCprimeprime1 does not declare the nominator input variable x Thecontract Cprimeprime2 specifies components that have an input variablex and an output variable of type y The only requirement onthe behavior of Cprimeprime2 is that y is strictly greater than 0 Thecomposition Cprimeprime1 otimes Cprimeprime2 is well defined The contract C1 refinesCprimeprime1 since it allows more inputs (the nominator input variable x)and restricts the behavior of the output variable z by definingits behavior as the division xy It follows that C1 is alsocompatible with Cprimeprime2 and that C1 otimes Cprimeprime2 Cprimeprime1 otimes Cprimeprime2 Finally wehave that M1 and M2 are implementations of their respectivecontracts It follows that M1 timesM2 implements C1 otimes Cprimeprime2
3) Contract Conjunction and Viewpoint Fusion We nowintroduce the conjunction operator between contracts denotedby the symbol and Conjunction is complementary to composi-tion
1) In the early stages of design the system-level speci-fication consists of a requirements document that is aconjunction of requirements
2) Full specification of a component can be a conjunctionof multiple viewpoints each covering a specific (func-tional timing safety etc) aspect of the intended designand specified by an individual contract see Figure 4 foran illustration
3) Conjunction supports reuse of a component in differentparts of a design see Figure 5 for an illustration
We state the desired properties of the conjunction operatoras follows Let C1 and C2 be two contracts If C1 and C2 areshared refinable then C1 andC2 C1 and C1 andC2 C2 and forall contracts C if C C1 and C C2 then C C1 and C2
To illustrate the conjunction operator we consider a contractCT1 that specifies the timing behavior associated with C1 Forthis contract we introduce additional ports that allow us tospecify the arrival time of each signal
CT1
variables
inputs tx ty
outputs tz
types tx ty tz isin R+
assumptions Tguarantees tzlemax(tx ty) + 1
The contract CT1 is shared refinable with C1 Their conjunctionC1 and CT1 yields a contract that guarantees in addition to C1itself a latency with bound 1 (say in ms) for it Becausethere are no assumptions this timing contract specifies thesame latency bound also for handling the illegal input y = 0In fact the contract says more because it does not mentionthe input y it assumes any value of y is acceptable Asa result the conjunction inherits the weakest T assumptionof the timing contract and cancels the assumption of C1This however is clearly not the intent since the timingcontract is not concerned with the values of the signals andis a manifestation of the weakness of this simple contract
RR ndeg 8147
Contracts for System Design 19
framework in dealing with contracts with different alphabetsof ports and variables We will further explain this aspect andshow how to address this problem in Section VII For themoment we can temporarily fix the problem by introducing yin the interface of the contract and use it in the assumptionsas in the following contract CT2
CT2
variables
inputs y tx ty
outputs tz
types y isin R tx ty tz isin R+
assumptions y 6=0guarantees tzlemax(tx ty) + 1
Note that this timing contract does not specify any bound forhandling the illegal input y = 0 since the promise is notenforced outside the assumptions
So far this example was extremely simple In particularit was stateless Extension of this kind of AssumeGuaranteecontracts to stateful contracts will be indeed fully developedin the coming sections and particularly in Section VII
C Contracts in requirement engineering
In this section we introduce a motivating example that isrepresentative of early requirements capturemdashthe specificationof a parking garage Its full development requires technicalmaterial that we introduce later and we thus defer it toSection XI This example illustrates the following features ofcontract based requirements capture namelybull Top-level system specification is by writing a require-
ments document Different formalisms may be used fordifferent kinds of requirements Here we illustrate thisby blending textual requirements written in constrainedEnglish (possibly obtained using boilerplates) with smallsized automata
bull The document itself is structured into chapters describingvarious aspects of the system such as how gates shouldbehave how payment should proceed plus some overallrules
bull Some requirements are under the responsibility of thesystem under development they contribute to specifyingthe guarantees that the system offers Other requirementsare not under the responsibility of the system underdevelopment they contribute to defining the assumptionsregarding the context in which the system should operateas specified
bull Requirements are written in constrained English languageor by using automata
We now begin with the top-level requirements The systemunder specification is a parking garage subject to paymentby the user At its most abstract level the requirementsdocument comprises the different chapters gate payment andsupervisor see Table III The gate chapter will collect thegeneric requirements regarding entry and exit gates Thesegeneric requirements will then be specialized for entry andexit gates respectively
Focus on the ldquogaterdquo chapter It consists of the three require-ments shown on Table III Requirement Rg1 is best described
gateRg1ldquovehicles shall not pass when gate is closedrdquo see Fig 7Rg2 after vehicle_pass vehicle_pass is forbiddenRg3 after gate_open gate_open is forbidden and
after gate_close gate_close is forbiddenpaymentsupervisor
Table IIITHE TOP-LEVEL SPECIFICATION WITH CHAPTER gate EXPANDED
REQUIREMENTS WRITTEN IN italics ARE ASSUMPTIONS UNDER WHICHgate SHOULD OPERATE
0
gate_close
1gate_opengate_close
vehicle_passgate_open
Figure 1 Requirement Rg1 specified as an io-automaton Prefix ldquordquoindicates an input and prefix ldquordquo indicates an output
by means of an io-automaton shown in Figure 1mdashwe providean informal textual explanation for it between quotes Supposethat some requirement says ldquogate_open never occursrdquo Thisis translated by having no mention of gate_open in thecorresponding io-automaton To express this ldquonegativerdquo factwe must keep track of the fact that gate_open belongs tothe alphabet of actions of the io-automaton Thus when per-forming the translation the explicit list of inputs and outputsshould be explicitly given To avoid such additional notationalburden we have cheated by omitting this unless necessaryThe other two requirements are written using constrainednatural language which can be seen as a boilerplate styleof specification Prefix ldquordquo indicates an input and prefix ldquordquoindicates an output
The first two requirements are not under the responsibilityof the system since they rather concern the car driver Thus itdoes not make sense to include them as part of the guaranteesoffered by the system Should we remove them This wouldbe problematic If drivers behave the wrong way unexpectedthings can occur for sure The conclusion is that 1) we shouldkeep requirements Rg1 and Rg2 and 2) we should handlethem differently than Rg3 which is a guarantee offered by thesystem Indeed Rg1 and Rg2 are assumptions under whichthe gate operates as guaranteed We take the convention thatassumptions are written in italics
So far we have specified gate as a list of requirementsRequirement Rg1 specified as an io-automaton can be con-sidered formal Requirements Rg2 and Rg3 are formulatedin constrained natural language and are ready for subsequentformalization eg as io-automata Are we done Not yetWe need to give a formal meaning to what it means to havea collection of requirements and what it means to distinguishassumptions from guarantees Similarly we must give a formalmeaning to what it means to combine different chapters of arequirements document Intuitively all requirements must be
RR ndeg 8147
Contracts for System Design 20
met for a chapter to be satisfied and similarly all chaptersmust be satisfied for the whole specification to be correctlyimplemented Thus we propose to write the top-level specifi-cation C as the following conjunction
C = Cgate and Cpayment and Csupervisor
As we said formally defining what conjunction and is requirestechnical material that is developed later in this paper Thefollowing issues arise regarding this top-level specificationFirst of all since a conjunction operator is involved in theconstruction of C there is a risk of formulating contradictingrequirementsmdashthis is referred to as the issue of consistencySecond are we sure that the top-level specification C iscomplete ie precise enough to rule out undesirable imple-mentations One good way of checking for completeness is tobe able to execute or simulate this top-level specification CWe provide answers to all these issues in Section XI wherethis example is fully developed
request enter
ticket issue
entry gate open
entry gate closeEntryGate
vehicle enter
vehicle exit
exit ticket insert ExitGateexit gate open
exit gate close
ticket insert payment
coin insert paymentPaymentMachine exit ticket issue
Figure 2 System architecture as specified by the designer
Having the top-level specification C at hand the designerthen specifies an architecture ldquoagrave la SysMLrdquo as shown onFigure 2 Some comments are in order regarding this archi-tecture The considered instance of a parking garage consistsof one entry gate one exit gate and one payment machineCompare with the top-level specification of Table III Thelatter comprises a generic gate a payment machine and asupervisor each one with its set of requirements In contrastthe architecture of Figure 2 involves no supervisor Thesupervisor is meant to be distributed among the two gatesThe architecture of Figure 2 seems to be very loosely coupledFirst the PaymentMachine seems to be totally independent Infact the ticket that is inserted in the exit gate must coincidewith the one issued by the PaymentMachine It turns out thatthis reflects a missing assumption regarding the environmentof the system (namely the user of the parking) Then thetwo gates seem to have the shared input ldquovehicle exitrdquo astheir only interaction But this shared input is involved in
requirement Rs3 which forbids the entry if the parking isfull
The next step in the design consists in subcontractingthe development of each of the three sub-systems of thearchitecture of Figure 2 This amounts to specifying threesubcontracts CEntryGate CExitGate and CPaymentMachinesuch that
CEntryGate otimes CExitGate otimes CPaymentMachine C (2)
The symbol in (2) means that any implementation of theleft hand side is also a valid implementation of the top-level C Then the contract composition operator otimes ensuresthat each supplier can develop its sub-system based on itsown sub-contract only and still integrating the so designedsub-systems yields a correct implementation of the top-levelspecification Once the three sub-contracts are found checkingthat they satisfy (2) requires formalizing the contract compo-sition operator otimes Furthermore guessing such sub-contractsis a difficult task In our development of this example inSection XI we propose adequate answers to these issues
D Contract Support for Design Methodologies
The three operators introduced above fit naturally in anydesign methodology developed so far In particular contractcomposition and conjunction supports horizontal processesand contract refinement supports vertical processes We showhow this is so by first analyzing the use of contract conjunc-tion for requirement management then of composition andrefinement for design chain management re-use and indepen-dent development to close with conjunction composition andrefinement for deployment and mapping
1) Supporting open systems When designing componentsfor reuse their context of use is not fully known in advanceWe thus need a specification of components exposing boththe guarantees offered by the component and the assumptionson its possible context of usemdashits ldquoenvironmentrdquo This stateswhat contracts should be
2) Managing Requirements and Fusing Viewpoints Re-ferring to Section III-C complex systems involve a numberof viewpoints (or aspects) that are generally developed bydifferent teams using different skills As a result there is aneed for fusing these viewpoints in a mathematically soundway Structuring requirements or specifications is a desirableobjective at each step of the design Finally we must formal-ize some key properties that must be evidenced as part ofcertification processes
This process is illustrated in Figure 3 In this figure weshow three viewpoints the behavioral viewpoint where thefunctions are specified the timing viewpoint where timingbudgets are allocated to the different activities and the safetyviewpoint where fault propagation effect and handling arespecified Typically different viewpoints are developed bydifferent teams using different frameworks and tools Devel-opment of each viewpoint is performed under assumptionsregarding its context of use including the other viewpoints To
RR ndeg 8147
Contracts for System Design 21
VIEWPOINT VIEWPOINT VIEWPOINTBEHAVIORAL TIMING SAFETY
is a conjunctionevery contract
C =and
i Ci
CB1 CB2 CT CS1 CS2
CB1 and CB2 and CT and CS1 and CS2
Figure 3 Conjunction of requirements and viewpoints in top-level design
get the full system specification the different viewpoints mustbe fused As the notations of Figure 3 suggest conjunctionis used for fusing viewpoints thus reflecting that the systemunder design must satisfy all viewpoints Similarly eachviewpoint is itself a conjunction of requirements seen as theldquoatomicrdquo contractsmdashall requirements must be met
3) Design Chain Management Re-using and IndependentDevelopment In Figure 4 we show three successive stages ofthe design At the top level sits the overall system specificationas developed by the OEM As an example it can be obtained asthe conjunction of several viewpoints as illustrated on Figure 3
is delegated forimplementation by a supplier
is delegated forimplementation by a supplier
C11 otimes (C121 otimes C122)otimes (C131 otimes C132)
C11
C12
C13
C11
C121 C122 C131 C132
C121 otimes C122 C131 otimes C132
C11 otimes C12 otimes C13
C1
is refined by the OEM
Figure 4 Stepwise refinement
As a first design step the OEM decomposes its system intoan architecture made of three sub-systems for independentdevelopment by (possibly different) suppliers For each ofthese sub-systems a contract C1j j = 1 2 3 is developedA contract composition denoted by the symbol ldquootimesrdquo
C11 otimes C12 otimes C13
mirrors the composition of sub-systems that defines the archi-tecture For our method to support independent development
this contract composition operator must satisfy the following
if designs are independently performed for eachsub-contract C1j j = 1 2 3 then integratingthese sub-systems yields an implementation thatsatisfies the composed contract C11 otimes C12 otimes C13
(3)
This contract composition must then be qualified against thetop-level contract C1 This qualification must ensure that anydevelopment compliant with C11 otimes C12 otimes C13 should alsocomply with C1 To ensure substitutability in any legal contextcompliance concerns both how the system behaves and whatits allowed contexts of use are any legal context for C1 shouldbe also legal for C11otimesC12otimesC13 and under any legal contextthe integrated system should behave as specified by C1 This isformalized as the refinement relation denoted by the symbol
C11 otimes C12 otimes C13 C1 (4)
Overall the satisfaction of (4) guarantees the correctness ofthis first design step performed by the OEM
Obtaining the three sub-contracts C11 C12 and C13 is the artof the designer based on architectural considerations Contracttheories however offer the following services to the designerbull The formalization of parallel composition and refinement
for contracts allows the designer to firmly assess whether(4) holds for the decomposition step or not
bull In passing the compatibility of the three sub-contractsC11 C12 and C13 can be formally checked
bull Using contracts as a mean to communicate specificationsto suppliers guarantees that the information provided tothe supplier is self-contained the supplier has all theneeded information to develop its sub-system in a waythat subsequent system integration will be correct
Each supplier can then proceed with the independent devel-opment of the sub-system it is responsible for For instance asupplier may reproduce the above procedure
Alternatively this supplier can develop some sub-systemsby reusing off-the-shelf components For example contractC121 would be checked against the interface specification of apre-defined component M121 available from a library and thefollowing would have to be verified does component M121
satisfy C121 In this context shared implementations are ofinterest This is illustrated on Figure 5 where the same off-the-shelf component implements the two referred contracts
To conclude on this analysis the two notions of refinementdenoted by the symbol ldquordquo and composition of contractsdenoted by the symbol ldquootimesrdquo are key Condition (3) ensuresindependent development holds
4) Deployment and Mapping Here we address a specificbut important point related to Contribution 1 At some pointin the design of the system specifications must be realized byusing resources Resources can be pre-defined sub-systems orcomponents or they can consist of computing resources com-prising computing units and communication media (networksbusses and protocols) This methodology was advocated and
RR ndeg 8147
Contracts for System Design 22
C11
C121 C122 C131 C132
C11 otimes (C121 otimes C122)otimes (C131 otimes C132)
C121 otimes C122 C131 otimes C132
C122 and C132
Figure 5 Conjunction for component reuse
systematically exploited in Platform Based Design [171] orPLM-centric design see footnote 4 in Section II How sucha step can be captured in contract based design is explainednext
When deploying an application over a computing plat-form in addition to the functional viewpoint non-functionalviewpoints (safety timing energy and possibly other) areof importance as well The safety viewpoint is concernedwith the risk of primary faults and failures how they couldpropagate throughout the system and what the consequencesfor the resilience of the overall system would be in termsof failure probability The timing viewpoint collects timingrequirements regarding the application (requirements on la-tencies throughput jitter and schedulability) The effectivesatisfaction of safety or timing viewpoints by a considereddeployment depends on 1) the supporting execution platformand 2) the mapping of the application to this executionplatform We thus need to formalize what ldquomappingrdquo meansThe reader is referred to Figure 6 for the following discussion
M4M3
M5M6
M1
M2
M3
M1
M4
M2
M5
M6x34
xd63 xo
63
x34
C2 C1
C3
P
C
xo63
xd63
Figure 6 Mapping the application to the execution platform as C and P
Suppose one has a virtual model of the execution platform
as an architecture composed of several components Suchcomponents would in the context of Figure 6 consist of adescription of the available computing units a descriptionof the bus protocol and frame structure andor a library ofRTOS (Real-Time Operating System) services The resultingcomponents are enhanced with timing information (for thetiming viewpoint) and fault propagation information (for thesafety viewpoint) Application contracts are attached to thedifferent sub-systems or components as described on the toppart of the figure Similarly platform contracts are attachedto the different sub-systems or components of the executionplatform as described on the bottom part of the figureAccordingly we assume
C =andk
(otimesiisinIk Cik
)P =
otimesjisinJ
(and`isinLj
Pj`)
where
bull The overall platform contract P decomposes asotimes
jisinJ Pj(eg the bus and the different computing units inFigure 6) where each Pj is the conjunction of its differentviewpoints (the function what can be computed and theassociated performance how much time it takes and howmuch energy it consumes)
bull The overall application contract is the conjunction ofits different viewpoints Ci with their own architecturaldecomposition
In Figure 6 we only show a single viewpoint29 and we assumethat distant communication between C2 and C3 has alreadybeen refined to a communication medium compliant with thecommunication resources offered by the execution platform
The mapping of the application over the architecture ismodeled by the conjunction CandP defined by the following setof synchronization tuples30 depicted in red in the Figure 6
bull The wire x34 linking M3 to M4 in the application issynchronized in the deployment P with the variablex34 of the left computing unit where x34 represents theoutput of the module implementing M3 and the input ofthe module implementing M4 And similarly for the wirelinking M5 to M6
bull In the deployment the wire x63 linking M6 to M3
must traverse the bus To capture this we first refinethe application architecture by distinguishing the originxo63 of this wire from its destination xd63 In the refinedapplication architecture we assume that xo63 and xd63 arerelated by some buffer of bounded size The deploymentis then captured by synchronizing xo63 with the output xo63
of the module implementing M6 in the right computingunit and by synchronizing xd63 with the input xd63 of themodule implementing M3 in the left computing unit
29Here we assume that the different application viewpoints are developedfor the whole application and then combined by conjunctionmdashthis is just amethodological proposal we could proceed differently
30In in a synchronization tuple both occurrences and values of the differentelements are unified
RR ndeg 8147
Contracts for System Design 23
This formalizes the deployment as the conjunction
C and P =[and
k
(otimesiisinIk Cik
) ]and [otimesjisinJ(and
`isinLjPj`) ]
ensuring that C and P refines C by construction There ishowever no free lunch The formula C and P expressing de-ployment involves a conjunction and is as such a possiblesource of inconsistencies If this happens then C and P cannotbe implemented Finding an execution platform P causingno inconsistency in C and P requires a good understanding ofthe application and its needs The more advanced techniquesdeveloped in Section XI provide assistance for this
Since C and P relates application and computing platformmdashwhich sit at different layers of the designmdashwe call suchcontracts vertical contracts Contracts that are not vertical aresometimes called horizontal in that they are meant to relatecomponents sitting at a same level of the design hierarchymdashapplication level or computing platform level or ECU (Elec-tronic Computing Unit) level
Techniques of mapping application to its execution platformthat are similar to the above one are used in the RT-Buildertool 31 and in the Metropolis platform [20] [80]
E Bibliographical note
Having collected the ldquorequirementsrdquo on contract theories itis now timely to confront these to the previous work referringto or related to the term ldquocontractrdquo
It is difficult to write a comprehensive bibliography onthe general aspects of contract based design The topic ismulti faceted and has been addressed by several communitiessoftware engineering language design system engineeringand formal methods in a broad sense We report here a partialand limited overview of how this paradigm has been tackledin these different communities While we do not claim beingexhaustive we hope that the reader will find her way to thedifferent literatures
Contracts in SW engineering This part of the biblio-graphical note was inspired by the report [168] Design byContract is a software engineering technique popularized byBertrand Meyer [139] [140] following earlier ideas fromFloyd-Hoare logic [169] [113] Floyd-Hoare logic assignsmeaning to sequential imperative programs in the form oftriples of assertions PCQ consisting of a preconditionon program states and inputs a command and a postcondi-tion on program states and outputs Meyerrsquos contracts weredeveloped for Object-Oriented programming They exposethe relationships between systems in terms of preconditionsand postconditions on operations and invariants on states Acontract on an operation asserts that given a state and inputswhich satisfy the precondition the operation will terminatein a state and will return a result that satisfy the postcondi-tion and respects any required invariant properties Contractscontribute to system substitutability Systems may be replacedby alternative systems or assemblies that offer the same or
31httpwwwgeensoftcomenarticlertbuilder
substitutable functionality with weaker or equivalent precon-ditions and strongerequivalent postconditions With the aimof addressing service oriented architectures Meyerrsquos contractswere proposed a multiple layering by Beugnard et al [37]The basic layer specifies operations their inputs outputs andpossible exceptions The behavior layer describes the abstractbehavior of operations in terms of their preconditions andpostconditions The third layer synchronisation correspondsto real-time scheduling of component interaction and messagepassing The fourth quality of service (QoS) level detailsnon-functional aspects of operations The contracts proposedby Beugnard et al are subscribed to prior to service invo-cation and may also be altered at runtime thus extendingthe use of contracts to Systems of Systems [141] So farcontracts consisting of prepostconditions naturally fit imper-ative sequential programming In situations where programsmay operate concurrently interference on shared variablescan occur RelyGuarantee rules [115] were thus added tointerface contracts Rely conditions state assumptions aboutany interference on shared variables during the execution ofoperations by the systemrsquos environment Guarantee conditionsstate obligations of the operation regarding shared variables
The concepts of interface and contract were subse-quently further developed in the Model Driven Engineering(MDE) [120] [172] [131] In this context interfaces aredescribed as part of the system architecture and comprisetyped ports parameters and attributes Contracts on interfacesare typically formulated in terms of constraints on the en-tities of components using the Object Constraint Language(OCL) [150] [180] Roughly speaking an OCL statementrefers to a context for the considered statement and expressesproperties to be satisfied by this context (eg if the context isa class a property might be an attribute) Arithmetic or set-theoretic operations can be used in expressing these propertiesThis method however does not account for functional andextra-functional properties of interfaces ie for behavior andperformance To account for behavior the classical approachin MDE consists in enriching components with methods thatcan be invoked from outside andor state machines Likewiseattributes on port methods have been used to represent non-functional requirements or provisions of a component [51]The effect of a method is made precise by the actual codethat is executed when calling this method The state machinedescription and the methods together provide directly animplementation for the component mdash actually several MDErelated tools such as GME and Rational Rose automaticallygenerate executable code from this specification [21] [132][161] The notion of refinement is replaced by the concept ofclass inheritance From a contract theory point of view thisapproach has several limitations Inheritance for instance isunable to cover aspects related to behavior refinement Noris it made precise what it means to take the conjunctionof interfaces which can only be approximated by multipleinheritance or to compose them
In a continuing effort since his joint work with W Dammon Life Sequence Charts (LSC) in 2000 [64] with its Play-
RR ndeg 8147
Contracts for System Design 24
Engine implementation [107] David Harel has developed theconcept of behavioral programming [108] [106] [109] whichputs in the forefront scenarios as a program developmentparadigmmdashnot just a specification formalism In behavioralprogramming b-threads generate a flow of events via anenhanced publishsubscribe protocol Each b-thread is a pro-cedure that runs in parallel to the other b-threads When ab-thread reaches a point that requires synchronization it waitsuntil all other b-threads reach synchronization points in theirown flow At synchronization points each b-thread specifiesthree sets of events requested events the thread proposes thatthese be considered for triggering and asks to be notifiedwhen any of them occurs waited-for events the thread doesnot request these but asks to be notified when any of themis triggered and blocked events the thread currently forbidstriggering any of these events When all b-threads are at asynchronization point an event is chosen (according to somepolicy) that is requested by at least one b-thread and is notblocked by any b-thread The selected event is then triggeredby resuming all the b-threads that either requested it or arewaiting for it This mechanism was implemented on top ofJava and LSCs The execution engine uses planning and modelchecking techniques to prevent the system from falling intodeadlock where all requested events are blocked Behavioralprogramming is incremental in that new threads can be addedto an existing program without the need for making any changeto this original program new deadlocks that are created bydoing so are pruned away by the execution engine Whilebehavioral programming cannot be seen as a paradigm ofcontracts it shares with contracts the objectives of incrementaldesign and declarative style of specification
Our focusmdashcontracts for systems and CPS The frame-works of contracts developed in the area of Software En-gineering have established as useful paradigms for compo-nent based software system development In this paper wetarget the wider area of computer controlled systems morerecently referred to as Cyber-Physical systems where reactivesystems [104] [110] [100] [136] are encountered that issystems that continuously interact with some environmentas opposed to transformational systems [100] considered inObject-Oriented programming For reactive systems model-based development (MBD) is generally accepted as a keyenabler due to its capabilities to support early validationand virtual system integration MBD-inspired design lan-guages and tools include SysML [149] or AADL [152] forsystem level modeling Modelica [93] for physical systemmodeling Matlab-Simulink [118] for control-law design andScade [144] [32] and TargetLink for detailed software designUML-related standardisation efforts in this area also includethe MARTE UML32 profile for real-time systems Contracttheories for model based development were considered inthe community of formal verification They were initiallydeveloped as specification formalisms able to refuse certaininputs from the environment Dill proposed asynchronous
32 wwwomgmarteorg
trace structures with failure behaviors [81] A trace structureis a representation of a component or interface with two setsof behaviors The set of successes are those behaviors whichare acceptable and guaranteed by the component Converselythe set of failures are behaviors which drive the componentinto unacceptable states and are therefore refused This workfocuses primarily on the problem of checking refinement anddoes not explore further the potentials of the formalism froma methodological point of view The work by Dill was laterextended by Wolf in the direction of synchronous systemsNegulescu later generalizes the algebra to Process Spaceswhich abstract away the specifics of the behaviors and derivesnew composition operators [143] This particular abstractiontechnique was earlier introduced by Burch with Trace Algebrasto construct conservative approximations [47] and later gen-eralized by Passerone and Burch [154] to study generic tracestructures with failure behaviors and to formalize the problemof computing the quotient (there called mirror) [153] Thispaper aims at proposing for model based design of systemsand CPS a new vista on contracts In the next section wepropose an all encompassing meta theory of contracts
V A MATHEMATICAL META-THEORY OF CONTRACTS
In software engineering meta-models are ldquomodels of mod-elsrdquo ie formal ways of specifying a certain family ofmodels Similarly we call here meta-theory a way to specifya particular family of theories In this section we proposea meta-theory of contracts This meta-theory is summarizedin Table IV It comes as a few primitive concepts on topof which derived concepts can be built A number of keyproperties can be proved about the resulting frameworkThese properties demonstrate that contracts are a convenientparadigm to support incremental development and independentimplementability in system design The meta-theory will serveas a benchmark for our subsequent review of concrete contracttheories
The meta-theory we develop here is novel There are veryfew attempts of that kind In fact the only ones we are awareof are the recent works by Bauer et al [22] and Chen et al [59]which follow a different (and complementary) approach Thediscussion of this work is deferred to the bibliographicalsection V-H
A Components and their composition
To introduce our meta-theory we start from a universe Mof possible components each denoted by the symbol M orE and a universe of their abstractions or contracts eachdenoted by the symbol C Our meta-theory does not presumeany particular modeling style neither for components nor forcontractsmdashwe have seen in Section IV an example of a (verysimple) framework for static systems More generally someframeworks may represent components and contracts with setsof discrete time or even continuous time traces other theoriesuse logics or state-based models of various kinds and so on
We assume a composition M1 timesM2 acting on pairs ofcomponents Component composition times is partially not to-
RR ndeg 8147
Contracts for System Design 25
Concept Definition and generic properties What depends on the particulartheory of contracts
Primitive
Component Components are denoted by M they can be open or closed How components are specified
Composabilityof components A type property on pairs of components (M1M2) How this type property is defined
Compositionof components
M1timesM2 is well defined if and only if M1 and M2 are composableIt is required that times is associative and commutative The definition of the composition
Environment An environment for component M is a componentE such that EtimesM is defined and closed
Derived
Contract A contract is a pair C = (EC MC ) where MC is a subsetof components and EC a subset of legal environments
Which family C of contractscan be expressed andhow they are expressedunless otherwise specifiedquantifying is implicitly over C isin C
Consistency C is consistent iff it has at least one component MC 6= empty How consistency is checked
Compatibility C is compatible iff it has at least one environment EC 6= empty How compatibility is checked
Implementation M |=M C if and only if M isinMCE |=E C if and only if E isinEC
How implementation is checked
Refinement Cprime C iff ECprime supe EC and MCprime subeMC Property 1 holds How refinement is checked
GLB andLUBof contracts
C1andC2 = Greatest Lower Bound (GLB) for we assume GLB existC1orC2 = Least Upper Bound (LUB) for we assume LUB exist
Property 2 holds
Whether and howGLB and LUB can beexpressed and computed
Compositionof contracts
C1otimesC2 is defined if M1 |=M C1M2 |=M C2
rArr (M1M2) composable
C1otimesC2 =andC
∣∣∣∣∣∣M1 |=M C1 and M2 |=M C2 and E |=E C
dArrM1 timesM2 |=M C and EtimesM2 |=E C1 and EtimesM1 |=E C2
Assumption 1 is in force Properties 3 4 and 5 holdSay that C1 and C2 are compatible if so is C1otimesC2
How composition isexpressed and computed
Quotient C1C2 =or C | C otimes C2 C1 Property 6 holds How quotient is
expressed and computed
Table IVSummary of the meta-theory of contracts We first list primitive concepts and then derived concepts introduced by the meta-theory
tally defined Two components that can be composed arecalled composable Composability of components is meantto be a typing property In order to guarantee that differentcomposable components may be assembled together in anyorder it is required that component composition times is asso-ciative and commutative Components that exhibit no meansfor interacting with the outside world are called closed othercomponents are open An environment for a component Mis another component E composable with M and such thatM times E is closed
B Contracts
In our primer of Section IV we have highlighted the im-portance of the legal environments associated with contractsfor which an implementation will operate satisfactorily At theabstract level of the meta-theory we make this explicit next
Definition 1 A contract is a pair C = (EC MC ) where
bull MC subeM is the set of implementations of C andbull EC subeM is the set of environments of C
For any pair (EM) isin EC times MC E is an environmentfor M Hence MtimesE must be well defined and closed Acontract possessing no implementation is called inconsistentA contract possessing no environment is called incompatibleWrite
M |=M C and E |=E C
to express that M isinMC and E isin EC respectivelyIn concrete theories of contracts both components and con-tracts are described in some finite (preferably concise) wayIn turn it is not true that every set Mprime subeM of componentscan be represented as Mprime = MC for some contract C andsimilarly for sets of environments To highlight this
we assume a family C of expressible contracts (5)
Only contracts belonging to this family can be consideredThis is made explicit in Table IV
C Refinement and conjunctionTo support independent implementability the concept of
contract refinement must ensure the following if contract Cprime
RR ndeg 8147
Contracts for System Design 26
refines contract C then any implementation of Cprime should 1)implement C and 2) be able to operate in any environment forC Hence the following definition for refinement preorder between contracts Cprime refines C written Cprime C if and onlyif MCprime sube MC and ECprime supe EC As a direct consequence thefollowing property holds which justifies the use of the termldquorefinementrdquo for this relation
Property 1 (refinement)1) Any implementation of Cprime is an implementation of C
M |=M Cprime rArrM |=M C and2) Any environment of C is an environment of Cprime
E |=E C rArr E |=E CprimeThe conjunction of contracts C1 and C2 written C1 and C2 isthe greatest lower bound (GLB) of these two contracts withrespect to refinement ordermdashwe assume such a GLB existsThe intent is to define this conjunction as the intersection ofsets of implementations and the union of sets of environmentsHowever due to (5) not every set of components is thecharacteristic set of a contract The best approximation consistsin taking the greatest lower bound for the refinement relationThe following immediate properties hold
Property 2 (shared refinement)1) Any contract that refines C1 and C2 also refines C1 and C2
Any implementation of C1 and C2 is a shared implementa-tion of C1 and C2 Any environment of C1 or C2 is anenvironment of C1 and C2
2) For C sube C a subset of contractsandC is compatible if
and only if there exists a compatible C isin C
The conjunction operation formalizes the intuitive notion of aldquoset of contractsrdquo or a ldquoset of requirementsrdquo
D Contract composition
The objective of contract composition is to ensure that1) composing respective implementations of each contract
yields an implementation for the composition and2) composing an environment for the resulting composition
with an implementation for C2 yields an environment forC1 and vice-versa
These two properties are essential in supporting top-downdesign by successive decompositions and refinements of con-tracts Contract composition C1 otimes C2 is thus defined on topof component composition as indicated in Table IV with thefollowing assumption in force throughout this meta-theory
Assumption 1 The following condition holds
C1 otimes C2 isin CC1otimesC2
(Note that this assumption is non trivial since it is not true foran arbitrary set C sube C that
andCisinC C isin C) The condition
for C1 otimes C2 to be defined is that every pair (M1M2) ofrespective implementations is composable so that M1 timesM2
is well definedmdashrecall that component composability is atyping property Consequently if E is an environment forM1timesM2 E is composable with both M1 and M2 and EtimesM1
is an environment for M2 and vice-versa Referring to the
formula defining C1 otimes C2 denote by CC1otimesC2 sube C the set ofcontracts specified in the brackets The following lemma willbe instrumental
Lemma 1 Let four contracts be such that Cprime1 C1Cprime2 C2 and C1 otimes C2 is well defined Then so is Cprime1 otimes Cprime2and CCprime1otimesCprime2 supe CC1otimesC2
Proof Since C1otimesC2 is well defined it follows that every pair(M1M2) of respective implementations of these contracts is acomposable pair of components Hence Cprime1otimesCprime2 is well definedaccording to the formula of Table IV Next since Cprime1 C1 andCprime2 C2 and using Assumption 1 M1 |=M Cprime1 and M2 |=M Cprime2implies M1 |=M C1 and M2 |=M C2 similarly E timesM2 |=E C1and EtimesM1 |=E C2 implies EtimesM2 |=E Cprime1 and EtimesM1 |=E Cprime2Therefore replacing in the big brackets defining the contractcomposition C1 by Cprime1 and C2 by Cprime2 can only increase the setCC1otimesC2 2
To conform to the usage we say that C1 and C2 arecompatible contracts if their composition C1 otimes C2 is definedand compatible in the sense of Table IV The followingproperties are a direct corollary of Lemma 1
Property 3 (independent implementability) For all con-tracts C1 C2 Cprime1 and Cprime2 if
1) C1 is compatible with C22) Cprime1 C1 and Cprime2 C2 hold
then Cprime1 is compatible with Cprime2 and Cprime1 otimes Cprime2 C1 otimes C2
Thus compatible contracts can be independently refined Thisproperty holds in particular if Cprime1 and Cprime2 are singletons
Corollary 1 Compatible contracts can be independentlyimplemented
Property 3 is fundamental particularly in top-down designTop-down incremental design consists in iteratively decom-posing a system-level contract C into sub-system contractsCi i isin I for further independent development To ensure thatindependent development will not lead to integration problemsit is enough to verify that
otimesiisinI Ci C We insist that since
contracts are purposely abstract and subsystems are not manythe composition of contracts Ci will not typically result in stateexplosion33
The following property is essential as it states that contractcomposition can be performed in any order and changesin architecture (captured by changes in parenthesizing) areallowed
Property 4 (associativity and commutativity) For all con-tracts C1 C2 C3 and C4 if C1 and C2 are compatible C3 andC4 are compatible and C1otimesC2 is compatible with C3otimesC4 thenC1 is compatible with C3 C2 is compatible with C4 C1 otimes C3is compatible with C2 otimes C4 and
(C1 otimes C2)otimes (C3 otimes C4) = (C1 otimes C3)otimes (C2 otimes C4) (6)
33 This is unlike in compositional verification where timesiisinIMi |=M Pis to be checked where Mi are detailed implementations and P is aproperty In this case the composition timesiisinIMi typically gives raise to stateexplosion Techniques have thus been proposed to verify such properties inan incremental way [176] [62] [98] [1] [121]
RR ndeg 8147
Contracts for System Design 27
Proof To shorten notations write C12 instead of C1 otimesC2 andsimilarly for any subset of 1 2 3 4 By Assumption 1 andthe associativity and commutativity of component composi-tion C1234 is characterized by the following two propertieswhere index i ranges over the set 1 4
Mi |=M Ci rArr M1times timesM4 |=M C1234
E |=E C1234 rArr Etimes (timesj 6=iMj) |=E Ci(7)
Observe that (7) is fully symmetric which proves (6) Nextusing the assumptions regarding compatibility we derive theexistence of at least one environment E satisfying the premiseof the second implication of (7) Since (7) is fully symmetricthis proves the conclusions of Property 4 regarding compati-bility 2
Property 5 (distributivity) If the following contract compo-sitions are all well defined then the following holds
[(C11 and C21)otimes (C12 and C22)] [(C11 otimes C12) and (C21 otimes C22)] (8)
Proof By Lemma 1 C(C11andC21)otimes(C12andC22) supe CC11otimesC12 Taking the GLB of these two sets thus yields[(C11 and C21)otimes (C12 and C22)] (C11 otimes C12) and similarlyfor (C21 otimes C22) Thus (8) follows 2
The use of distributivity is best illustrated in the followingcontext Suppose the system under design decomposes intotwo sub-systems labeled 1 and 2 and each subsystem hastwo viewpoints associated with it labeled by another indexwith values 1 or 2 Contract (C11 and C21) is then the contractassociated with sub-system 1 and similarly for sub-system 2Thus the left hand side of (8) specifies the set of imple-mentations obtained by first implementing each sub-systemindependently and then composing these implementationsProperty 5 states that by doing so we obtain an implemen-tation of the overall contract obtained by first getting thetwo global viewpoints (C11 otimes C12) and (C21 otimes C22) andthen taking their conjunction This property supports inde-pendent implementation for specifications involving multipleviewpoints Observe that only refinement not equality holdsin (8)
E Quotient
The quotient of two contracts is defined in Table IV It isthe adjoint of the product operation otimes in that C1C2 is themost general context C in which C2 refines C1 It formalizesthe practice of ldquopatchingrdquo a component to make it behavingaccording to another specification From its definition inTable IV we deduce the following property
Property 6 (quotient) The following holds
C C1C2 hArr C otimes C2 C1
Proof Immediate from the definition 2
F Discussion
By inspecting Table IV the different notions can be classi-fied into the following two categories
bull Primitive notions that are assumed by the meta-theoryThis category comprises components component com-posability and composition
bull Derived notions comprise contract refinement conjunc-tion composition and quotient consistency and com-patibility for contracts The derived notions follow fromthe primitive ones through set theoretic non effectivedefinitions
The meta-theory offers by itself a number of fundamentalproperties that underpin incremental development and inde-pendent implementability Concrete theories will offer defini-tions for the primitive notions as well as effective means toimplement (or sometimes approximate) the derived notionsObservers and then abstract interpretation we develop nextprovide generic approaches to recover effectiveness
G Observers
Notion Observer
C = (EC MC )(bEC b
MC)
C = C1andC2 bEC = bE
C1 or bEC2 b
MC = bM
C1 and bMC2
C = C1orC2 bEC = bE
C1 and bEC2 b
MC = bM
C1 or bMC2
C = C1otimesC2bEC(E) =
bMC1 (M1) and bM
C2 (M2)
dArrbEC2 (EtimesM1) and bE
C1 (EtimesM2)
bMC(M1 timesM2) = bM
C1 (M1) and bMC2 (M2)
Table VMirroring the algebra of contracts with observers
A typical obstacle in getting finite (or more generallyeffective) representations of contracts is the occurrence ofinfinite data types and functions having infinite domains Thesecan be dealt with by using observers which originate from thebasic notion of test for programs
Definition 2 Let C be a contract An observer for Cis a pair (bE
C bMC) of non-deterministic boolean functions
M 7rarr F T called verdicts such that
bEC(M) outputs F =rArr M 6isin ECbMC(M) outputs F =rArr M 6isin MC
(9)
The functions M 7rarr bEC(M) and M 7rarr bM
C(M) being bothnon-deterministic accounts for the fact that the outcome of atest depends on the stimuli from the environment and possiblyresults from internal non-determinism of the tested componentitself Note the single-sided implication in (9) which reflectsthat tests only provide semi-decisions
Relations and operations of the meta-theory can be mirroredby relations and operations on observers as explained inTable Vmdashwe omit the formulas for the quotient as semi-effectiveness of testing makes it useless Despite GLB andLUB can be mirrored using the formulas of the table nothingcan be said about the relationship of observers for contractsbased on the fact that they are in a refinement ordering Dually
RR ndeg 8147
Contracts for System Design 28
nothing can be inferred in terms of their refinement fromsuch a relationship between the observers Still the followingweaker result holds which justifies how GLB and LUB arerepresented using observers in Table V
Lemma 2 Let (bEC b
MC) be an observer for C and let Cprime C
Then any pair (bE bM) satisfying bE ge bEC and bM le bM
C is anobserver for CprimeThe following immediate results hold regarding consistencyand compatibility
Lemma 31) If bE
C(E) outputs F for all tested environment E then Cis incompatible
2) If bMC(M) outputs F for all tested component M then C
is inconsistent
To summarize Definition 2 provides semi-decision proceduresto check whether a component or an environment are validfor a contract Lemma 3 provides semi-decision proceduresfor checking consistency and compatibility Finally Table Vindicates how operations from the contract algebra can bereflected into operations on observers
Due to the need for exercising all components or environ-ments using observers for checking consistency or compat-ibility is still non-effective For concrete theories exhibitingsome notion of ldquostrongestrdquo environment or component for theconsidered contract a reinforcement of Lemma 3 will ensureeffectiveness
In Section VI where concrete theories are reviewed weindicate for each theory how observers can be constructedand how Lemma 3 specializes
H Bibliographical note
Abstract contract theories and features of our presen-tation Our presentation here is new There is only a smallliterature providing an abstract formalization of the notion ofcontracts The only attempts we are aware of are the recentworks by Bauer et al [22] and Chen et al [59] albeit withdeeply different and complementary approaches
The publication [22] develops an axiomatization of thenotion of specification from which contracts can be derivedin a second step More precisely specifications are abstractentities that obey the following list of axioms it possesses arefinement relation that is a preorder which induces a notionof equivalence of specifications and a parallel compositionthat is associative commutative (modulo equivalence) andmonotonic with respect to refinement It is assumed thatif two specifications possess a common lower bound thenthey possess a greatest lower bound A quotient is alsoassumed which is the residuation of the parallel composi-tion From specifications contracts are introduced as pairs ofspecifications very much like AssumeGuarantee contracts wedevelop in Section VII are pairs of assertions Sets of legalenvironments and sets of implementations are associated tocontracts Finally modal contracts are defined by borrowingideas from modal specifications we discuss in Section VIIIThis abstract theory nicely complements the one we develop
here in that it shows that both specifications and contracts canbe defined as primitive entities and be used to build moreconcrete theories
The work [59] develops the concept of declarative speci-fication which consists of a tuple P = (ΣinΣout TΣ FΣ)where Σin and Σout are input and output alphabets of actionsΣ = Σin ] Σout and TΣ FΣ sube Σlowast such that FΣ sube TΣ
are sets of permissible and inconsistent traces respectivelymdashthis approach find its origins in earlier work by Dill [81]and Negulescu [143] Outputs are under the control of thecomponent whereas inputs are issued by the environmentThus after any successful interaction between the componentand the environment the environment can issue any input αeven if it will be refused by the component If α is refusedby the component after the trace t isin TΣ tα isin FΣ is aninconsistent trace capturing that a communication mismatchhas occurred An environment is called safe if it can preventa component from performing an inconsistent trace For Qto be used in place of P it is required that Q must existsafely in any environment that P can exist in safely this isthe basis on which refinement is defined Alphabet extensionis used by which input actions outside the considered alphabetare followed by an arbitrary behavior for the declarativespecification A conjunction is proposed that is the GLB forrefinement order A parallel composition is proposed whichis monotonic with respect to refinement A quotient is alsoproposed which is the residuation of parallel composition
Observers Observers being related to the wide areaof software and system testing have been widely studiedA number of existing technologies support the design ofobservers and we review some of them now
Synchronous languages [28] [100] [30] are a formalism ofchoice in dealing with observers The family of SynchronousLanguages comprises mainly the imperative language Es-terel [92] [84] and the dataflow languages Lustre [144] andSignal [157] The family has grown with several childrenoffering statecharts-like interfaces and blending dataflow andstatechart-based styles of programming such as in Scade V634Synchronous languages support only systems governed bydiscrete time not systems with continuous time dynamics(ODEs) They benefit from a solid mathematical semantics Asa consequence executing a given program always yields thesame results (results do not depend on the type of simulator)The simulated or analysed program is identical to the codefor embedding Thanks to these unique features specificationscan easily be enhanced with timing andor safety viewpointsThe RT-Builder35 tool on top of Signal is an example offramework supporting the combination of functional and tim-ing viewpoints while analyzing an application deployed overa virtual architecture (see Section IV-D4) The widely usedSimulinkStateflow36 tool by The Mathworks offers similarfeatures One slight drawback is that its mathematical seman-
34httpwwwesterel-technologiescomproductsscade-suite35httpwwwgeensoftcomenarticlertbuilder36httpwwwmathworkscomproductssimulink
RR ndeg 8147
Contracts for System Design 29
tics is less firmly defined (indeed results of executions maydiffer depending on the code executed simulation or generatedC code) On the other hand Simulink supports continuoustime dynamics in the form of systems of interconnectedODEs (Ordinary Differential Equations) thus supporting themodeling of the physical part of the system Using Simulinkpossibly enhanced with SimScape37 allows for includingphysical system models in observers eg as part of the systemenvironment The same comment holds regarding Modelica38
Actually observers have been proposed and advocated in thecontext of Lustre and Scade [101] [102] [103] Esterel [45]and Signal [137] [138] More precisely Scade advocatesexpressing tests using Scade itself Tests can then easily beevaluated at run time while executing a Scade program Toconclude observe that synchronous languages and formalismsdiscussed in this section are commercially available and widelyused
Another good candidate for expressing observers is theProperty Specification Language (PSL) PSL is an industrialstandard [151] [86] [85] for expressing functional (or behav-ioral) properties targeted mainly to digital hardware designWe believe that PSL is indeed very close to several lessestablished but more versatile formalisms based on restrictedEnglish language that are used in industrial sectors otherthan digital hardware eg in aeronautics automobile orautomation Consider the following property
ldquo For every sequence that starts with an a imme-diately followed by three occurrences of b and endswith a single occurrence of c d holds continuouslyfrom the next step after the end of the sequence untilthe subsequent occurrence of e rdquo
This property is translated into its PSL version
[]ab[3]c |=gt (d until e)
PSL is a well-suited specification language for expressingfunctional requirements involving sequential causality of ac-tions and events Although we are not aware of the usageof PSL in the particular context of contract-based design wemention the tool FoCS [2] that translates PSL into checkersthat are attached to designs The resulting checker takes theform of an observer if the PSL specification is properlypartitioned into assumption and guarantee properties More re-cently PSL was also used for the generation of transactors thatmay adapt high-level requirements expressed as transaction-level modules to the corresponding register-transfer implemen-tation [18] [17] It follows that the existing tool support forPSL makes this specification language suitable in the contract-based design using observers We note that the availabilityof formal analysis tools allows the design to be checkedexhaustivelymdashthis is of course at the price of restrictionson data types Another benefit in using PSL as an observer-based interface formalism is an existing methodology for user-guided automated property exploration built around this lan-
37httpwwwmathworkscomproductssimscape38httpswwwmodelicaorg
guage [158] [42] that is supported by the tool RATSY [43]As previously stated PSL is built on top of LTL and regularexpressions One can thus express liveness properties in PSLwhich are not suitable for online monitoring There are twoorthogonal ways to avoid this potential issue (1) restrictingthe PSL syntax to its safety fragment or (2) adapting the PSLsemantics to be interpreted over finite traces [87] A survey ofusing PSL in runtime verification can be found in [85]
Another relevant formalism for building observers consistsof the Live Sequence Charts (LSC) [64] [107] [105] LSCare a graphical specification language based on scenarios thatis an extension of Message Sequence Charts (MSC)39 Atypical LSC consists of a prechart and a main chart Thesemantics is that whenever the prechart is satisfied in a run ofthe system eventually the main chart must also be satisfiedPrecharts should not be confused with assumptions howeverthey are rather sort of ldquoprerequisitesrdquo LSCs are multi-modalin that any construct in the language can be either cold orhot with a semantics of ldquomay happenrdquo or ldquomust happenrdquorespectively If a cold element is violated (say a conditionthat is not true when reached) this is considered a legalbehavior and some appropriate action is taken Violation ofa hot element however is considered a violation of thespecification and is not allowed to happen in an executionLSC are executable The execution of a set of LSCs is calledplay out by the authors [107] Play out is useful for checkingan LSC specification against a property [66] LSC can beused as (expressive) tests to monitor the execution of a designover non-terminating runs While doing so the same rules asabove are applied except that the design controls the emissionof events and the LSC specification is used to react in caseof violation of the specification This is manifested by theabsence of rules explaining the occurrence of some event atrun-time This procedure is called play in by the authors Toconclude LSCs are well suited to express observers
VI PANORAMA OF CONCRETE THEORIES
For the coming series of sections where concrete contracttheories are reviewed the reader is referred to Table IV ofSection V where the meta-theory of contracts is developedWe will illustrate how various concrete contract theories canbe developed by specializing the meta-theory
VII PANORAMA ASSUMEGUARANTEE CONTRACTS
Our static example of Section IV provided an exampleof contract specified using Assumptions and Guarantees As-sumeGuarantee contracts (AG-contracts) Assumptions char-acterize the valid environments for the considered compo-nent whereas the Guarantees specify the commitments ofthe component itself when put in interaction with a validenvironment Various kinds of AG-contract theories can beobtained by specializing the meta-theory in different waysVariations concern how the composition of components isdefined We will review some of these specialization and relatethem to the existing literature
39httpwwwsdl-forumorgMSCindexhtm
RR ndeg 8147
Contracts for System Design 30
In general AG contract theories build on top of componentmodels that are assertions ie sets of behaviors or tracesassigning successive values to variables As we shall seedifferent kinds of frameworks for assertions can be consid-ered including asynchronous frameworks of Kahn ProcessNetworks (KPN) [117] and synchronous frameworks in whichbehaviors are sequences of successive reactions assigningvalues to the set of variables of the considered system We firstdevelop the theory for the simplest case of a fixed alphabetThen we develop the other cases
A Dataflow AG contracts
For this simplest variant all components and contractsinvolve a same alphabet Σ of variables possessing identical40
domain DWith this simplification a component M identifies with an
assertion
P sube Σ 7rarr Dlowast cupDω (10)
ie a subset of the set of all finite or infinite behaviors overalphabet Σ such a behavior associates to each symbol x isin Σa finite or infinite flow of values The flows are not mutuallysynchronized and there is no global clock or logical step Wediscuss in Section VII-D variants of this framework with moresynchronous models of behaviors For convenience we feelfree to use both set theoretic and boolean notations for therelations and operations on assertions
Two components are always composable and we definecomponent composition by the intersection of their respectiveassertions
P1timesP2 = P1andP2 (11)
Formulas (10) and (11) define a framework of asynchronouscomponents with no global clock and no notion of reac-tion Instead a component specifies a relation between thehistories of its different flows When input and output portsare considered as in Section VII-B and components are in-putoutput functions we obtain the model of Kahn ProcessNetworks [117] widely used for the mapping of synchronousprograms over distributed architectures [159] [160]
Definition 3 A contract is a pair C = (AG) of assertionscalled the assumptions and the guarantees The set EC of thelegal environments for C collects all components E such thatE sube A The set MC of all components implementing C isdefined by AtimesM sube GThus any component M such that M le G or notA is animplementation of C and MC = G or notA is the maximalimplementation Observe that two contracts C and Cprime withidentical input and output alphabets identical assumptionsand such that Gprime or notAprime = G or notA possess identical sets ofimplementations MC =MCprime According to our meta-theorysuch two contracts are equivalent Any contract C = (AG)is equivalent to a contract in saturated form (AGprime) such that
40This is only an assumption intended to simplify the notations It is by nomeans essential
Gprime supe notA or equivalently G or A = T the true assertionto exhibit Gprime just take Gprime = G or notA A saturated contractC = (AG) is consistent if and only if G 6= empty and compatibleif and only if A 6= empty
Next for C and Cprime two saturated contracts with identicalinput and output alphabets
refinement Cprime C holds iffAprimegeAGprimeleG (12)
Conjunction follows from the refinement relation for C1 andC2 two saturated contracts with identical input and outputalphabets C1 and C2 = (A1orA2 G1andG2)
Focus now on contract composition C = C1 otimes C2 for twosaturated contractsmdashthis is no loss of generality as we haveseen Contract composition instantiates through the followingformulas cf (1) in Section IV
G = G1andG2
A = max
A∣∣∣∣∣∣AandG2rArrA1
andAandG1rArrA2
(13)
which satisfies Assumption 1 of the meta-theory If further-more contracts are saturated then (13) reformulates as theformulas originally proposed in [29]
G = G1 andG2
A = (A1 andA2) or not(G1 andG2)(14)
Observe that the so obtained contract (AG) is saturatedG orA = (G1 andG2) or (A1 andA2) or not(G1 andG2) = T
No quotient operation is known for AssumeGuaranteecontracts
We finish this section by observing that the two contractsC1 and Cprime1 of Section IV-A1 satisfy Cprime1 C1 according to thetheory of this section guarantees are identical but assumptionsare relaxed
B Capturing exceptions
Referring to the primer of Section IV-A1 and its staticsystem example dividing by zero may raise an exception Forinstance a careless designer may consider instead of M1 aslight variation M prime1 of it where the behaviors are only partiallydefined
M prime1 behaviors (y 6= 0rarr z = xy)
leaving what happens if a value 0 is submitted for y unspeci-fied In practice y = 0 would raise an exception leading to anunpredictable outcome and possibly a crash unless exceptionhandling is offered as a rescue by the execution platform
In this section we show how a mild adjustment of ourtheory of AG contracts can capture exceptions and theirhandling To simplify we develop this again for the case ofa fixed alphabet Σ We only present the add-ons with respectto the previous theories the parts that remain unchanged arenot repeated
Since exceptions are undesirable events caused by the com-ponent itself and not by its inputsmdashfor our simple example the
RR ndeg 8147
Contracts for System Design 31
exception is the improper handling of the division by zeromdashweneed to include inputs and outputs as part of our frameworkfor components
A component is thus a tuple M = (ΣinΣout P ) whereΣ = Σin cup Σout is the decomposition of alphabet Σ intoits inputs and outputs and P sube (Σ 7rarr (Dlowast cupDω)) is anassertion Whenever convenient we shall denote by Σin
M QM PM etc the items defining component M Components M1
and M2 are composable if Σout1 cap Σout
2 = empty If so thenM1timesM2 = (ΣinΣout P ) is well defined with Σout =Σout
1 cup Σout2 Σin = Σminus Σout and P = P1 cap P2
Let us now focus on exceptions To capture improper re-sponse (leading to a ldquocrashrdquo) we distinguish a special elementfail isin D We assume that crash is not revertible ie inany behavior of the component any variable remains at failwhen it reaches that value Referring to the static example ofSection IV we would then set x0 = fail for any x We arenow ready to formalize what it means for a component to befree of exception
Definition 4 A component M is free of exception if1) It accepts all inputs
prΣinM
(PM ) = ΣinM 7rarr (DlowastcupDω)
2) It does not cause by itself the occurrence of fail in itsbehaviors for any behavior σ isin PM if the projectionprΣin
M(σ) of σ to the input alphabet Σin
M does not involvefail then neither does σ
Exception freeness defined in this way is such that if M1 andM2 are both composable and free of exception then M1timesM2
is also free of exception Hence we are free to restrict ouruniverse of components to exception free componentsmdashthusDefinition 4 defines our family of components AG contractsare re-defined accordingly
Definition 5 A contract is a tuple C = (ΣinΣout AG)where Σin and Σout are the input and output alphabets andA and G are assertions over Σ called the assumptions andthe guarantees The set EC of the legal environments for C areall free of exception components E such that Σin
E = ΣoutC
ΣoutE = Σin
C and PE sube A The set MC of all componentsimplementing C is defined by M is free of exception Σin
M =ΣinC and Σout
M = ΣoutC and PEtimesM sube G for every environment
E of CFocus now on the issue of consistency and compatibility forcontracts The following holds
Property 7 Let C = (ΣinΣout AG) be a contract satis-fying the following conditions
prΣinC
(G) = ΣinM 7rarr (DlowastcupDω) (15)
prΣoutC
(A) = ΣoutM 7rarr (DlowastcupDω) (16)
fail does not occur in G andA (17)
Then C is consistent and compatibleProof By condition (15) the component M = (ΣinΣout G)satisfies condition 4 of Definition 4 It may not satisfy condi-tion 2 however To achieve this we must modify in M the
behaviors not belonging to A to avoid fail to occur PreservingM on A will ensure that implementation of C is preservedTo get M prime replace any behavior σ isin G and notA by a behaviorσprime such that prΣin
C(σprime) = prΣin
C(σ) and prΣout
C(σprime) 63 fail
Component M prime obtained in this way is free of exception andimplements C showing that C is consistent Consider next thecomponent E = (ΣoutΣin A) If E is free of exception thenit is an environment for C If this is not the case then we canmodify E on AandnotG as we did for obtaining M prime This yieldsan environment Eprime for C showing that C is compatible 2
Conditions (15) and (16) express that assumptions andguarantees are both input enabled Condition (17) is the keyone Observe that now contract Cprime1 of Section IV-A1 isinconsistent since it has no implementationmdashimplementationsmust be free of exception In turn contract C1 is consistentThis is in contrast to the theory of Section VII-A whereboth contracts were considered consistent (crashes were notruled out) Indeed contract C1 of Section IV-A1 satisfies theconditions of Property 7 whereas Cprime1 does not Addressingexceptions matters
C Dealing with variable alphabets
Since contracts aim at capturing incomplete designs wecannot restrict ourselves to a fixed alphabetmdashit is not known inadvance what the actual alphabet of the complete design willbe Thus the simple variants of Sections VII-A and VII-B haveno practical relevance and we must extend them to dealingwith variable alphabets In particular components will now bepairs M = (ΣM PM ) where ΣM is the alphabet of M andPM is an assertion over ΣM Similarly contracts are triplesC = (ΣC AC GC) where assumptions AC and guarantees GCare assertions over alphabet ΣC
Key to dealing with variable alphabet this is the operationof alphabet equalization that we introduce next For P an as-sertion over alphabet Σ and Σprime sube Σ we consider its projectionprΣprime(P ) over Σprime which is simply the set of all restrictionsto Σprime of all behaviors belonging to P We will also need theinverse projection prminus1
Σprimeprime (P ) for Σprimeprime supe Σ which is the set ofall behaviors over Σprimeprime projecting to Σ as behaviors of P For(Σi Pi) i = 1 2 we call alphabet equalization of (Σ1 P1)and (Σ2 P2) the two assertions (Σprminus1
Σ (Pi)) i = 1 2 whereΣ = Σ1 cup Σ2
We also need to define alphabet equalization when thealphabet Σ decomposes as Σ = Σin ] Σout Equalizing theabove decomposition to a larger alphabet Σprimeprime supe Σ yieldsΣprimeprimeout = Σout whence Σprimeprimein = Σprimeprime Σprimeprimeout follows
Alphabet equalization serves as a preparation step to reusethe framework of Section VII-A when alphabets are variable
This being defined all operations and relations introducedin Section VII-A are extended to the case of variable alphabetsby 1) applying alphabet equalization to the involved assertionsand 2) reusing the operation or relation as introduced inSection VII-A
As pointed out in [29] this generalization yields a contracttheory that is a valid instantiation of the meta-theory (up tothe missing quotient) It is not satisfactory from the practical
RR ndeg 8147
Contracts for System Design 32
standpoint however The reason is that the conjunction oftwo contracts with disjoint alphabets yields a trivial assump-tion T which is very demandingmdashany environment must beaccommodatedmdashand does not reflect the intuition (more onthis will be discussed in Section VIII-D
To summarize Sections VII-A VII-B and VII-C togetherdefine a framework for asynchronous AssumeGuarantee con-tracts where components are of Kahn Process Network type
D Synchronous AG contracts
We obtain variants of this framework of AssumeGuaranteecontracts by changing the concrete definition of what anassertion is and possibly revisiting what the component com-position is We can redefine assertions as
P sube (Σ 7rarr D)lowast cup (Σ 7rarr D)ω (18)
Compare (18) with (10) In both cases assertions are sets ofbehaviors With reference to (10) behaviors were tuples offinite or infinite flows one for each symbol of the alphabetIn contrast in (18) behaviors are finite or infinite sequencesof reactions which are the assignment of a value to eachsymbol of the alphabet By having a distinguished symbolperp isin D to model the absence of an actual data we getthe multiple-clocked synchronous model used by synchronouslanguages [30] Definition (18) for assertions correspond to thesynchronous model of computation whereas (10) correspondsto the Kahn Process Network type of model [117] [142] Thematerial of Sections VII-A VII-B and VII-C can be adaptedto this new model of component composition thus yielding aframework of synchronous AssumeGuarantee contracts
E Observers
The construction of observers for this case is immediate Wedevelop it for the most interesting case in which exceptions arehandled see Sections VII-A and VII-B Let P be an assertionaccording to (10) P defines a verdict bP by setting
bP (σ) = T if and only if σ isin P (19)
Observers must return their verdict in some finite amount oftime Hence on-line interpretation based on Definition 3 isappropriate With this interpretation for C = (ΣinΣout AG)a contract its associated observer is obtained as follows withreference to Definition 2
bull bEC(E) is performed by drawing non-deterministically a
behavior σ of E and then evaluating bA(σ)bull bMC(M) is performed by drawing non-deterministically a
behavior σ of M and then evaluating bA(σ)rArr bM (σ)
Lemma 3 for generic observers specializes to the followingeffective semi-decision procedure
Lemma 4
1) If bA outputs F then C is incompatible2) If bA rArr bG outputs F then C is inconsistent
F Discussion
AssumeGuarantee contracts are a family of instantiationsof our meta-theory This family is flexible in that it canaccommodate different models of communication and differentmodels of exceptions AssumeGuarantee contracts are anadequate framework for use in requirements capture Indeedrequirements are naturally seen as assertions When categoriz-ing requirements into assumptions (specifying the context ofuse of the system under development) and guarantees (that thesystem offers) formalizing the resulting set of requirements asan AG contract seems very natural
Regarding exceptions the special value fail that we intro-duced to capture exceptions is not something that is given inpractice Value fail may subsume various run time errors Al-ternatively for the synchronous AssumeGuarantee contractsfail can capture the failure of a component to be input enabled(able in each reaction to accept any tuple of inputs)
In its present form the framework of AssumeGuaranteecontracts (synchronous or asynchronous) suffers from theneed to manipulate negations of assertions an operation thatis generally not effective except if the framework is restrictedto finite state automata and finite alphabets of actions Forgeneral frameworks using observers or abstract interpretationcan mitigate this in part
G Bibliographical note
By explicitly relying on the notions of Assumptions andGuarantees AG-contracts are intuitive which makes themappealing for the engineer In AG-contracts Assumptions andGuarantees are just properties The typical case is when theseproperties are languages or sets of traces which includes theclass of safety properties [122] [58] [136] [14] [61] AG-contracts were advocated by the SPEEDS project [29] Theywere further experimented in the framework of the CESARproject [63] with the additional consideration of weak andstrong assumptions The theory developed in [29] turns outto be closest to this presentation still exceptions were nothandled in [29] The presentation developed in this paperclarifies the design choices in AG-contract theories
Inspired by [126] another form for AG-contract was pro-posed by [97] [99] when designs are expressed using theBIP programming language [41] [174] To achieve separatedevelopment of components and to overcome the problemsthat certain models have with the effective computation ofthe operators the authors avoid using parallel compositionotimes of contracts Instead they replace it with the concept ofcircular reasoning which states as follows in its simplestform if design M satisfies property G under assumptionA and if design N satisfies assumption A then M times Nsatisfies G When circular reasoning is sound it is possibleto check relations between composite contracts based ontheir components only without taking expensive compositionsIn order for circular reasoning to hold the authors deviserestricted notions of refinement under context and show howto implement the relations in the contract theory for the BIP
RR ndeg 8147
Contracts for System Design 33
framework Compatibility is not addressed and this proposaldoes not consider conjunction
Regarding extensions a notion of contract for real-timeinterfaces is proposed in [40] Sets of tasks are associated tocomponents which are individually schedulable on a processorAn interface for a component is an ω-language containing alllegal schedules Schedulability of a set of components on asingle processor then corresponds to checking the emptinessof their intersection The interface language considered isexpressive enough to specify a variety of requirements likeperiodicity the absence or the presence of a jitter etc An as-sumeguarantee contract theory for interfaces is then developedwhere both assumptions and guarantees talk about boundson the frequency of task arrivals and time to completionsDependencies between tasks can also be captured Refinementand parallel product of contracts are then defined exactly asin the SPEEDS generic approach
In [145] a platform-based design methodology that usesAG analog contracts is proposed to develop reliable ab-stractions and design-independent interfaces for analog andmixed-signal integrated circuit design Horizontal and verti-cal contracts are formulated to produce implementations bycomposition and refinement that are correct by constructionThe effectiveness of the methodology is demonstrated on thedesign of an ultra-wide band receiver used in an intelligenttire system an on-vehicle wireless sensor network for activesafety applications
AG-contracts have been extended to a stochastic setting byDelahaye et al [75] [76] [77] In this work the implementa-tion relation becomes quantitative More precisely implemen-tation is measured in two ways reliability and availabilityAvailability is a measure of the time during which a systemsatisfies a given property for all possible runs of the system Incontrast reliability is a measure of the set of runs of a systemthat satisfy a given property Following the lines of the contracttheories presented earlier satisfaction is assumption-dependentin the sense that runs that do not satisfy the assumptions areconsidered to be ldquocorrectrdquo the theory supports refinementstructural composition and logical conjunction of contractsand compositional reasoning methods have been proposedwhere the stochastic or non-stochastic satisfaction levels canbe budgeted across the architecture For instance assume thatimplementation Mi satisfies contract Ci with probability αifor i = 1 2 then the composition of the two implementationsM1timesM2 satisfies the composition of the two contracts C1otimesC2
with probability at least α1 + α2 minus 1Features of our presentation This presentation of AG-
contracts is new in may respects For the first time it iscast into the meta-theory of contracts with the advantage ofclarifying the definition of refinement and parallel compositionof contractsmdashthis involved some hand waving in the originalwork [29] Also this allowed us to handle exceptions properly
VIII PANORAMA INTERFACE THEORIES
Interface theories are an interesting alternative to As-sumeGuarantee contracts They aim at providing a merged
specification of the implementations and environments associ-ated to a contract via the description of a single entity calledan interface We review some typical instances of interfacetheories with emphasis on interface automata and modalinterfaces Interface theories generally use (a mild variation of)Lynch InputOutput Automata [135] [134] as their frameworkfor components and environments As a prerequisite we thusrecall the background on InputOutput Automata io-automatafor short
A Components as io-automataAn io-automaton is a tuple M = (ΣinΣout Q q0rarr)
wherebull Σin and Σout are disjoint finite input and output alpha-
bets set Σ = Σin cup Σoutbull Q is a finite set of states and q0isinQ is the initial statebull rarr sube QtimesΣtimesQ is the transition relation as usual we
write q αminusrarr qprime to mean (q α qprime) isin rarr and qαminusrarr to
indicate the existence of a qprime such that q αminusrarr qprimeBy concatenation transition relation rarr extends to a relationrarrlowast on Q times Σlowast times Q where Σlowast is the set of all finite wordsover Σ Say that a state qprime is reachable from q if there existssome word m such that q mminusrarrlowast qprime To considerably simplifythe development of the theory we restrict ourselves to
deterministic io-automata ie such thatq
αminusrarr q1 and q αminusrarr q2 implies q2 = q1(20)
Two io-automata M1 and M2 having identical alphabet Σare composable if the usual inputoutput matching conditionholds Σout
1 capΣout2 = empty and their composition M = M1timesM2
is given by
Σin = Σin1 cap Σin
2
Σout = Σout1 cup Σout
2
Q = Q1 timesQ2 and q0 = (q10 q20)
and the transition relation rarr is given by
(q1 q2)αminusrarr (qprime1 q
prime2) iff qi
αminusrarri qprimei i = 1 2
An io-automaton is said closed whenever Σin = empty and openotherwise For Mi i = 1 2 two io-automata and two statesqi isin Qi say that q1 simulates q2 written q2leq1 if
forallα qprime2 such that q2αminusrarr2 qprime2 rArr
q1
αminusrarr1 qprime1
and qprime2leqprime1(21)
Say that
M1 simulates M2 written M2leM1 if q20leq10 (22)
Observe that simulation relation (2122) does not distinguishinputs from outputs neither it distinguishes the componentfrom its environment It is the classical simulation relationmeant for closed systems Due to condition (20) of determin-ism simulation coincides with language inclusion
Variable alphabet is again dealt with using the mechanismof alphabet equalization For M = (ΣinΣout Q q0rarr) anio-automaton and Σprime sup Σ we define
MuarrΣprime
=(Σin cup (Σprime Σ)Σout Q q0rarrprime
)RR ndeg 8147
Contracts for System Design 34
whererarrprime is obtained by adding torarr for each state and eachadded action a self-loop at this state labeled with this action
Componentsmdashand consequently environmentsmdashfor use ininterface theories will be receptive io-automata (also termedinput enabled) ie they should react by proper response toany input stimulus in any state41
M is receptive iff forallq isin Qforallα isin Σin qαminusrarr (23)
Receptiveness is stable under parallel composition
B Interface Automata with fixed alphabet
For reasons that will become clear later we restrict thepresentation of interface automata to the case of a fixedalphabet Σ We begin with the definition of Interface Automatawhich are possibly non-receptive io-automata Moreover wegive their interpretation as contracts according to the meta-theory
Definition 6 An Interface Automaton is a tuple C =(ΣinΣout Q q0rarr) where ΣinΣout Qrarr are as inio-automata
The initial state q0 however may not satisfy q0isinQ If q0isinQholds Interface Automaton C defines a contract by fixing apair (EC MC ) as followsbull The set EC of the legal environments for C collects all
components E such that1) Σin
E = Σout and ΣoutE = Σin Thus E and C seen as
io-automata are composable and E timesC is closed2) For any output action α isin Σin of environment E
such that qEαminusrarrE and any reachable state (qE q)
of E times C then (qE q)αminusrarrEtimesC holds
There exists a unique maximal environment EC isin EC inthat EC timesC simulates EtimesC in the sense of (22) for anyE isin EC EC = (ΣoutΣin Q cup gt q0rarrEC ) where(a) the restriction to Qtimes ΣtimesQ of transition relationrarrEC coincides with rarr
(b) forallq isin Q q αminusrarrEC gt holds if and only if not[qαminusrarr ]
and α isin Σout(c) gt αminusrarrEC gt holds for any α isin Σ
bull The setMC of the implementations of C collects all com-ponents M such that io-automaton C simulates ECtimesMin the sense of (22)
Condition 2) means that environment E is only willing toemit an output if it is accepted as an input by C in thecomposition E times C Regarding the existence and uniquenessof EC observe first that conditions (a) and (b) together implythat EC is receptive Also by (a) and (b) EC times C is strictlyidentical with (emptyΣ Q q0rarr) ie it is obtained from Cseen as an io-automaton by simply turning inputs to outputsConsequently Condition 2) holds and thus EC isin EC By (b)and (c) EC is maximal
The above definition of Interface Automata is heterodoxcompare with the original references [72] [5] Definition 6
41In fact receptiveness is assumed in the original notion of io-automatonby Nancy Lynch [135] [134] We use here a relaxed version of io-automatonfor reasons that will become clear later
introduces the two sets EC and MC whereas no notionof implementation or environment is formally associated toan Interface Automaton in the original definition Also thehandling of the initial state is unusual Failure of q0isinQ tohold typically arises when the set of states Q is emptyOur Definition 6 allows to cast Interface Automata in theframework of the meta-theory of Table IV
Corresponding relations and operations must be instantiatedand we do this next As a first immediate result
Lemma 5 q0 isin Q is the necessary and sufficient conditionfor C to be both consistent and compatible in the sense of themeta-theory ie EC 6= empty and MC 6= empty
Refinement and conjunction Contract refinement as de-fined in Table IV is equivalent to alternate simulation [10]defined as follows for Ci i = 1 2 two contracts say that tworespective states qi i = 1 2 are in alternate simulation writtenq2q1 if
forallα isin Σout2 qprime2 st q2
αminusrarr2 qprime2 rArr
α isin Σout
1
q1αminusrarr1 qprime1
qprime2qprime1
forallα isin Σin1 q
prime1 st q1
αminusrarr1 qprime1 rArr
α isin Σin
2
q2αminusrarr2 qprime2
qprime2qprime1
(24)
Say that C2 refines C1 written C2C1 if q20q10 The firstcondition of (24) reflects the inclusionMC2
subeMC1 whereas
the second condition of (24) reflects the opposite inclusionEC2supe EC1
Alternate simulation can be effectively checkedsee [70] for issues of computational complexity Unfortunatelyno simple formula for the conjunction of contracts is knownSee [83] for the best results in this direction
Parallel composition and quotient Contract compositionC2otimesC1 as defined in the meta-theory is effectively computedas follows for Ci two Interface Automata satisfying the con-ditions of Lemma 5 Consider as a first candidate for contractcomposition the composition C2timesC1 where Ci i = 1 2 areseen as io-automata This first guess does not work becauseof the condition involving environments in the contract compo-sition of the meta-theory More precisely by the meta-theorywe should have
E |=E C rArr [EtimesM2 |=E C1 and EtimesM1 |=E C2]
which requires forallα isin Σouti qi
αminusrarri rArr (q1 q2)αminusrarrC2timesC1
Pairs (q1 q2) not satisfying this are called illegal In words apair of states (q1 q2) is illegal when one Interface Automatonwants to submit an output whereas the other one refuses toaccept itmdashreferring to AssumeGuarantee contracts one couldinterpret this as a mismatch of assumptions and guaranteesin this pair of interfaces Illegal pairs must then be prunedaway Pruning away illegal pairs from C2timesC1 together withcorresponding incoming transitions may cause other illegalpairs to occur The latter must also be pruned away untilfixpoint occurs The result is the contract composition C2otimesC1
RR ndeg 8147
Contracts for System Design 35
As a result of this pruning it may be the case that theresulting contract has empty set of states which by Lemma 5expresses that the resulting composition of the two interfacesis inconsistent and incompatiblemdashin the original literature onInterface Automata [72] [5] it is said that the two interfacesC1 and C2 are incompatible
In [39] incremental design of deterministic Interface Au-tomata is studied Let Cdarr be the interface C with input andoutput actions interchanged Given two Interface Automata C1and C2 the greatest interface compatible with C2 such that theircomposition refines C1 is given by (C2 C1darr)darr Hence the partregarding quotient in the meta-theory is correctly addressed fordeterministic Interface Automata
Dealing with variable alphabets So far we have pre-sented the framework of interface automata for the case of afixed alphabet The clever reader may expect that dealing withvariable alphabets can be achieved by using the mechanismof alphabet equalization via inverse projections42 This is acorrect guess for contract composition It is however not clearif it is also adapted for conjunction for which no satisfactoryconstruction exists as previously indicated
In contrast alphabet equalization and conjunction are el-egantly addressed by the alternative framework of ModalInterfaces we develop now
C Modal Interfaces with fixed alphabet
Modal Interfaces inherit from both the Interface Au-tomata and the originally unrelated notion of Modal Automa-ton (or Modal Transition System) see the bibliographicalnote VIII-G As Interface Automata Modal Interfaces usereceptive io-automata as their components and environmentsThe presentation of Modal Interfaces we develop here isaligned with our meta-theory and thus differs from classicalpresentations Again we begin with the case of a fixedalphabet Σ
Definition 7 We call Modal Interface a tuple of the formC = (ΣinΣout Q q0rarr 99K) where ΣinΣout Q q0 are asin Interface Automata and rarr 99Ksube Q times Σ times Q are twotransition relations called must and may respectively
A Modal Interface C such that q0isinQ induces two (possiblynon receptive) io-automata
and Cmust = (ΣinΣout Q q0rarr)and Cmay = (ΣinΣout Q q0 99K)
A Modal Interface is deterministic if Cmay is deterministic inthe sense of 20 C defines a contract by fixing a pair (EC MC )as follows
The set EC of the legal environments for C collects allcomponents E such that
1) ΣinE = Σout and Σout
E = Σin consequently E andCmust seen as io-automata are composable and E timesCmust is closed the same holds with Cmay in lieu ofCmust
42The inverse projection of an io-automaton is simply achieved by addingin each state a self-loop for each missing symbol
2) For any α isin Σin such that qEαminusrarrE and any reachable
state (qE q) of E times Cmay (qE q)αminusrarrEtimesCmust
There exists a unique maximal environment EC isin EC in thatEC times Cmay simulates E times Cmay in the sense of (22) for anyE isin EC EC = (ΣoutΣin Q cup gt q0rarrEC ) where(a) the restriction to QtimesΣintimesQ of transition relationrarrEC
coincides with rarr the restriction to Q times Σout times Q oftransition relation rarrEC coincides with 99K
(b) for any q isin Q q αminusrarrEC gt holds if and only if not[qα99K ]
and α isin Σout(c) gt αminusrarrEC gt holds for any α isin Σ
The set MC of the implementations of C collects all compo-nents M such that
3) ECtimesCmay simulates ECtimesM in the sense of (22)[only may transitions are allowed for ECtimesM ]
4) for any reachable state (qE qM ) of ECtimesM and (qE q)of ECtimesCmay such that (qE qM )le(qE q) and any ac-tion α isin Σout
M such that q αrarr then (qE qM )αminusrarrECtimesM
[must transitions are mandatory in ECtimesM ]
The first paragraph is a verbatim of the original definition ofModal Interfaces [166] Definition 7 introduces the two setsEC and MC whereas the classical theory of Modal Interfacesconsiders and develops a different notion of model (oftenalso called ldquoimplementationrdquo which is unfortunate) As forInterface Automata in Section VIII-B the handling of initialstate q0 is heterodox Our Definition 7 allows to cast ModalInterfaces in the framework of the meta-theory
To justify the existence and uniqueness of EC observe firstthat conditions (a) and (b) together imply that EC is receptiveCondition (2) follows from (a) Maximality in the sense of(22) follows from (b) and (c)
Consistency and Compatibility We begin with consis-tency Say that state q isin Q of C is consistent if q αrarr impliesq
α99K otherwise we say that it is inconsistent Assume thatC has some inconsistent state q isin Q meaning that for someaction α q αrarr holds but q
α99K does not hold By conditions 3)
and 4) of Definition 7 for any environment E and anyimplementation M of C no state (qE qM ) of EtimesM satisfies(qE qM )leq Hence all may transitions leading to q can bedeleted from C without changing MC Performing this makesstate q unreachable in Cmay thus Condition 2 of Definition 7is relaxed and the set of environments is possibly augmentedSince we have removed may transitions some more stateshave possibly become inconsistent So we must repeat thesame procedure Since the number of states is finite thisprocedure eventually reaches a fixpoint At fixpoint the setQ of states partition as Q = Qcon ]Qincon where Qincon
collects all states that were or became inconsistent as a resultof this procedure and Qcon only collects consistent statesIn addition since the fixpoint has been reached Qincon isunreachable from Qcon As a final step we delete Qincon andcall [C] the so obtained contract The following result holds
Lemma 6
RR ndeg 8147
Contracts for System Design 36
1) Modal Interface [C] satisfies
M[C]
=MC and E[C]supe EC (25)
where the inclusion is strict unless C possesses noinconsistent state
2) [C] offers the smallest set of environments among theModal Interfaces satisfying (25)
3) C is consistent and compatible if and only if Qcon 3 q0In the sequel unless otherwise specified we will only considerModal Interfaces that are consistent and compatible
Refinement and conjunction Conjunction and refinementare instantiated in a very elegant way in the theory of ModalInterfaces Contract refinement in the sense of the meta-theoryis instantiated by the effective notion of Modal refinement weintroduce now Roughly speaking modal refinement consistsin enlarging the must relation (thus enlarging the set of legalenvironments) and restricting the may relation (thus restrictingthe set of implementations) The formalization requires the useof simulation relations
For C a Modal Interface and qisinQ a state of it introducethe following may and must sets
may(q) = α isin Σ | q α99K
must(q) = α isin Σ | q αrarr
Definition 8 (modal refinement) Let Ci i = 1 2 be twoModal Interfaces and let qi be a state of Ci for i = 1 2Say that q2 refines q1 written q2 q1 if
may2(q2) sube may1(q1)must2(q2) supe must1(q1)
and forallα isin Σ
q1
α99K1 qprime1
q2α99K2 qprime2
=rArr qprime2 qprime1
Say that C2 C1 if q20 q10
The following result relates modal refinement with contractrefinement as defined in the meta-theory It justifies the con-sideration of modal refinement Its proof follows by direct useof Definition 7 and Lemma 6
Lemma 7 For C1 and C2 two Modal Interfaces the follow-ing two properties are equivalent(i) MC2
sube MC1and EC2
supe EC1 meaning that contract C2
refines contract C1 following the meta-theory(ii) [C2] [C1] ie [C2] refines contract [C1] in the sense of
modal refinementThe conjunction of two Modal Interfaces is thus the GreatestLower Bound (GLB) with respect to refinement order Itscomputation proceeds in two steps In a first step we wildlyenforce the GLB and compute a pre-conjunction by takingunion of must sets and intersection of may sets
Definition 9 The pre-conjunction43 C1andC2 of two ModalInterfaces is only defined if Σin
1 = Σin2 and Σout
1 = Σout2
43Pre-conjunction was originally denoted by the symbol amp in [164] [167][166]
and is given by Σin = Σin1 Σout = Σout
1 Q = Q1timesQ2q0 = (q10 q20) and its two transition relations are given by
must(q1 q2) = must1(q1) cupmust2(q2)may(q1 q2) = may1(q1) capmay2(q2)
(26)
Due to (26) C1andC2 may involve inconsistent states and thusin a second step the pruning introduced in Lemma 6 must beapplied
C1 and C2 = [C1andC2] (27)
Say that the two Modal Interfaces C1 and C2 are consistent44
if C1 and C2 is consistent in the sense of Lemma 6Parallel composition and quotient For Modal Interfaces
we are able to define both parallel composition and quotient inthe sense of the meta-theory As it was the case for InterfaceAutomata parallel composition for Modal Interfaces raisescompatibility issues and thus a two-step procedure is againfollowed for its computation
Definition 10 The pre-composition C1otimesC2 of two ModalInterfaces is only defined if Σout
1 capΣout2 = empty and is given by
Σout = Σout1 cup Σout
2 Q = Q1timesQ2 q0 = (q10 q20) and itstwo transition relations are given by
must(q1 q2) = must1(q1) capmust2(q2)may(q1 q2) = may1(q1) capmay2(q2)
(28)
Say that a state (q1 q2) of C1otimesC2 is illegal if
may1(q1) cap Σin2 6sube must2(q2)
or may2(q2) cap Σin1 6sube must1(q1)
Illegal states are pruned away from C1otimesC2 as follows Removefrom Cmay
1 times Cmay2 all transitions leading to (q1 q2) As
performing this may create new illegal states the same isrepeated until fixpoint is reached As a final step we delete thestates that are not may-reachable This finally yields C1otimesC2which no more possesses illegal states
The above construction is justified by the following resultLemma 8 C1otimesC2 as defined in Definition 10 instantiates
the contract composition from the meta-theory
Proof (sketch) E is an environment for C iff for any reachablestate (qE q1 q2) of E times Cmay
1 times Cmay2 we have
rs(qE ) sube must1(q1) capmust2(q2) (29)
where rs(q) the ready set of state q is the subset of actionsα such that q αminusrarr holds Let M1 be any implementation ofC1 and consider EtimesM1 We need to prove that EtimesM1 is anenvironment for C2 ie satisfies Condition 2 of Definition 7(we must also prove the symmetric property) Let (qE q1 q2)be a reachable state of EtimesM1timesCmay
2 We must prove
rs(qE ) cap rsM1 (q1 ) cap Σ in2 sube must2(q2)
By (29) it suffices that the following property holds
rsM1(q1 ) cap Σ in
2 sube must2(q2) (30)
44This is the usual wording in the literature
RR ndeg 8147
Contracts for System Design 37
However we only know that rsM1(q1 ) sube may1 (q1 ) Hence
to guarantee (30) we must prune away illegal pairs of statesTo this end we use the same procedure as before we makestate (q1 q2) unreachable in Cmay
1 timesCmay2 by removing all may
transitions leading to that state We complete the reasoning aswe did for the study of consistency 2
Definition 11 The quotient C1C2 of two modal interfacesC1 and C2 is only defined if Σin
1 cap Σout2 = empty and is defined
according to the following two steps procedure First defineC as follows Σout = Σout
1 Σout2 Q = Q1 times Q2 q0 =
(q10 q20) and its two transition relations are given by
must(q1 q2) = must1(q1)
may(q1 q2) = not [may1(q1) cap notmust1(q1)] cupnot [must1(q1) capmust2(q2)] cupnot [may1(q1) cupmay2(q2)]
These formulas may give raise to inconsistent states and thusin a second step we set C1C2 = [C]This definition is justified by the following result [166]showing that Definition 11 instantiates the meta-theory
Lemma 9 C1 otimes C2 C if and only if C2 CC1
Now it may be that (C1C2)otimesC2 possess illegal pairs of states(Definition 10) whence the following improvement whereΣout and Σin are as in Definition 11 and may and mustrefer to the quotient C1C2
Definition 12 Let Cprime be the interface defined on the samestate structure as C1C2 with however the following modali-ties
may prime(q1 q2) = may(q1 q2) cap(may2(q2) cup Σin
)must prime(q1 q2) = must(q1 q2) cup (Σout
1 cap Σout2 capmay2(q2))
define the compatible quotient written C1C2 to be thereduction of Cprime C1C2 = [Cprime]
This construction is justified by the following result
Lemma 10 The compatible quotient C1C2 solves thefollowing problem
max
C∣∣∣∣∣∣C has no inconsistent stateC otimes C2 has no illegal pair of statesC otimes C2 C1
Proof Denote C = C1C2 the compatible quotient definedabove The proof is threefold (i) C is proved to be a solutionof the inequality CotimesC2 C1 (ii) C is proved to be compatiblewith C2 and (iii) every Cprime satisfying the two conditions aboveis proved to be a refinement of C
Remark that reachable states in (C1C2)otimesC2 are of the form(q1 q2 q2) and that for every reachable state pair (q1 q2) inC1C2 state (q1 q2 q2) is reachable in (C1C2)otimes C2
(i) Remark that may prime sube may and must prime supe must HenceC1C2 C1C2 Since the parallel composition is monotonic(C1C2)otimes C2 (C1C2)otimes C2 C1
(ii) For every state (q1 q2 q2) reachable in (C1C2)otimes C2one among the following three cases occurs
bull Assume e isin Σin1 meaning that e is an input for both C2
and C1C2 Hence state (q1 q2 q2) is not illegal becauseof e
bull Assume e isin Σout1 cap Σout
2 Therefore e is an input of thecompatible quotient Remark must prime(q1 q2) sube may2(q2)Hence state (q1 q2 q2) is not illegal because of e
bull Assume e isin Σout1 capΣin
2 meaning that e is an output of thecompatible quotient Remark may prime(q1 q2) sube must2(q2)Therefore state (q1 q2 q2) is not illegal because of e
(iii) Let Cprimeprime be a modal interface such that C1C2 Cprimeprime C1C2 We shall prove that either Cprimeprime C1C2 or that Cprimeprime is notcompatible with C2 Remark that every reachable state (q1 q2)of C1C2 is related to exactly one state qprimeprime of Cprimeprime by the twomodal refinement relations Assume that Cprimeprime is not a refinementof C1C2 meaning that there exists related states (q1 q2)and qprimeprime such that may prime(q1 q2) sube may primeprime(qprimeprime) sube may(q1 q2)and must prime(q1 q2) supe must primeprime(qprimeprime) supe must(q1 q2) and eithermay prime(q1 q2) ( may primeprime(qprimeprime) or must prime(q1 q2) ) must primeprime(qprimeprime)Remark e isin Σin
1 implies that e isin may prime(q1 q2) iff e isinmay(q1 q2) and that e isin must prime(q1 q2) iff e isin must(q1 q2)Therefore the case e isin Σin
1 does not have to be considered
1) Assume there exists e such that e isin may primeprime(qprimeprime) may prime(q1 q2) Remark this implies e isin Σout
1 cap Σin2
meaning that e is an output of the compatible quo-tient Remark also that e 6isin must2(q2) Therefore state(qprimeprime q2) is illegal in Cprimeprime otimes C2
2) Assume there exists e such that e isin must prime(q1 q2) must primeprime(qprimeprime) Remark this implies e isin Σout
1 cap Σout2
meaning that e is an input of the compatible quotientRemark also that e isin may2(q2) Therefore state (qprimeprime q2)is illegal in Cprimeprime otimes C2
2
D Modal Interfaces with variable alphabet
As a general principle every relation or operator introducedin Section VIII-C (for Modal Interfaces with a fixed alphabetΣ) is extended to the case of variable alphabets by 1) extendingand equalizing alphabets and then 2) applying the relations oroperators of Section VIII-C to the resulting Modal InterfacesFor all frameworks we studied so far alphabet extension wasperformed using inverse projections see Section VII-C Forinstance this is the procedure used in defining the compositionof io-automata extending alphabets in io-automata is byadding at each state and for each added action a self-loop labeled with this action The very reason for using thismechanism is that it is neutral for the composition in thefollowing sense it leaves the companion io-automaton freeto perform any wanted local action
So for Modal Interfaces what would be a neutral procedurefor extending alphabets Indeed considering (26) or (28)
RR ndeg 8147
Contracts for System Design 38
yields two different answers namely
for (26)
α isin may1(q1) and α isin whatever2(q2)dArr
α isin whatever(q1 q2)
for (28)
α isin must1(q1) and α isin whatever2(q2)dArr
α isin whatever(q1 q2)
where ldquowhateverrdquo denotes either may or must Consequentlyneutral alphabet extension is by adding
bull may self-loops for the conjunction andbull must self-loops for the composition
The bottom line is that we need different extension proceduresThese observations explain why alphabet extension is properlyhandled neither by Interface Automata (see the last paragraphof Section VIII-B) nor by AG-contracts (see the end ofSection VII-C) These theories do not offer enough flexibilityfor ensuring neutral extension for all relations or operators
We now list how alphabet extension must be performed foreach relation or operator for two Modal Interfaces C1 and C2(the reader is referred to [166] for justifications) Alphabetsare extended as follows where Σprime supe Σ Define the strongextension of C to Σprime written CuarrΣprime
as follows
CuarrΣprime
(Σin)uarrΣprime
= Σin cup (Σprime Σ)
(Σout)uarrΣprime
= Σout
QuarrΣprime
= Q
quarrΣprime
0 = q0
mayuarrΣprime
= may cup (Σprime Σ)
mustuarrΣprime
= must cup (Σprime Σ)
(31)
In (31) the added may and must transitions are all self-loopsThe weak extension of C written CuArrΣprime
is defined using thesame formulas with the only following modification
CuArrΣprime
=
mustuArrΣprime= must
(32)
Observe that the strong extension uses the classical inverseprojection everywhere The weak extension however proceedsdifferently with the must transitions in that it forbids the legalenvironments to submit additional actions as its outputs
Using weak and strong alphabet equalization the relationsand operations introduced in Section VIII-C extend to variablealphabets as indicated now In the following formulas (ΣΣprime)is a pair such that Σ sube Σprime and (Σ1Σ2Σ) denotes a triplesuch that Σ = Σ1 cup Σ2 and satisfying the typing constraints
Σini = Σin cap Σi and Σout
i = Σout cap Σi for i = 1 2
It is understood that contract C has alphabet Σ and so on
Theorem 1 The following relations and operators
M prime |=M C = M prime |=M CuArrΣprime
Eprime |=E C = Eprime |=E CuarrΣprime
C1 C2 = C1 CuArrΣ2
C1 and C2 = CuArrΣ1 and CuArrΣ
2
C1 otimes C2 = CuarrΣ1 otimes CuarrΣ2
C1C2 = CuArrΣ1 CuarrΣ2
(33)
instantiate the meta-theory
Proof The first two formulas just provide definitions so noproof is needed for them Their purpose is to characterizethe weakly and strongly extended Modal Interfaces in termsof their sets of environments and implementations For bothextensions allowed output actions of the implementations areaugmented whereas mandatory actions are not For the weakextension legal environments are not modified in that noadditional output action is allowed for them In contrast for thestrong extension legal environments are allowed to submit anyadditional output action These observations justify the otherformulas 2
E Projecting and Restricting
A difficult step in the management of contracts was illus-trated in Figure 4 of Section IV-D It consists in decomposinga contract C into a composition of sub-contractsotimes
iisinI Ci C (34)
where sub-contract Ci has alphabet Σi = Σini ] Σout
i As aprerequisite to (34) the designer has to guess some topologicalarchitecture by decomposing the alphabet of actions of C as
Σ =⋃iisinI Σi Σi = Σin
i ] Σouti (35)
such that composability conditions regarding inputs and out-puts hold Guessing architectural decomposition (35) relies onthe designerrsquos understanding of the system and how it shouldnaturally decomposemdashthis typically is the world of SysMLFinding decomposition (34) is however technically difficultin that it involves behaviors It is particularly difficult if Cis itself a conjunction of viewpoints or requirements whichtypically occurs in requirements engineering see Section XI
C =andkisinK Ck (36)
The algorithmic means we develop in the remaining part ofthis section will be instrumental in solving (34) They will beused in the Parking Garage example of Section XI
Projecting over a subalphabet Projecting a contract overa sub-alphabet is the first natural tool for consideration Itis the dual operation with respect to alphabet extension thatwas developed in Section VIII-D Two projections can bedefined which can be seen as under- and over-approximationsrespectively by referring to the refinement order
RR ndeg 8147
Contracts for System Design 39
Let C be a Modal Interface with alphabet Σ = Σin cup Σout
and let Σprime sub Σ be a sub-alphabet Define respectively theabstracted projection and refined projection
CdarrΣprime= min Cprime | ΣCprime = Σprime and Cprime C
CdArrΣprime= max Cprime | ΣCprime = Σprime and Cprime C
(37)
where ldquominrdquo and ldquomaxrdquo refer to refinement order for ModalInterfaces with different alphabets see (33) The projectionCdArrΣprime
(respectively CdarrΣprime) is computed via the following on-
the-fly algorithm 1) Perform ε-closure on the set of states byconsidering unobservable the actions not belonging to Σprime andthen 2) Perform determinization by giving priority to mustover may (respectively to may over must) see Table VI fordetails Step 2) of the procedure for computing CdArrΣprime
is apossible source of inconsistencies
The abstracted projection CdarrΣprimeprovides a projected view
of a system-level contract over a small subset of actionsThe abstracted projection is thus a useful tool for contractexploration and debug It is not a synthesis tool however
This is in contrast to the refined projection CdArrΣprime which
satisfies the following result For any finite set Ci | i isin Iof Modal Interfaces with respective alphabets Σi we haveassuming that the left and right hand sides are properlydefinedmdasha typing property on input and output alphabetsotimes
iisinI
[Ci and
(andkisinK C
dArrΣi
k
)]
andkisinK Ck (38)
To show this by symmetry it is enough to show (38) withthe conjunction on the right hand side replaced by any singleCk for k selected from finite set K For any i isin I we haveCdArrΣi
k Ck and thus
Cprimei =def
[Ci and
(andkisinK C
dArrΣi
k
)] Ck (39)
holds for every i from which (38) follows Unfortunately therefined projection quite often gives raise to inconsistenciesIn addition the contract composition arising in left hand sideof (38) is subject to incompatibilities Informally said thistechnique works if the sub-systems are only ldquoloosely coupledrdquoso that neither inconsistencies nor incompatibilities occur Tomitigate this problem we propose an alternative technique forturning a conjunction into a composition
Restricting to a sub-alphabet Let C be a Modal Interfacewith alphabet Σ = Σin cup Σout and let (ΣprimeinΣprimeout) be twoinput and output sub-alphabets such that Σprimeout sube Σout SetΣprime = Σprimein]Σprimeout and define the restriction of C to Σprime denotedby CdarrΣprime via the procedure shown in see Table VII comparewith Table VI Observe that the states of the restriction cor-respond to sets of states of the original Modal Interface Therestriction aims at avoiding incompatibilities when consideringthe composition as the following lemma shows
Lemma 11 If C and CdarrΣprime are both consistent then so istheir compatible quotient CCdarrΣprime see Definition 12Proof Consider two alphabets Σ supe Σprime and a consistent C onalphabet Σ such that CdarrΣprime is also consistent The only casewhere quotient produces inconsistent states is whenever there
input CΣΣprime output Cprime
let proj(OpX) =if X has not been visitedthen
1 mark X visited2 for every α isin Σprime do
21 let Y = ε-closure(Σminus Σprime next(αX))22 let m = OpmC(q α) | q isin X23 add to Cprime a transition (Xα Y ) with modality m24 proj(Op Y )
done
let project(Op C) =1 let X0 = ε-closure(Σminus Σprime q0)2 set initial state of Cprime to X0
3 proj(OpX0)4 reduce Cprime5 return Cprime
let order (cannot maymustle) =
must le may
cannot le may
in CdarrΣprime= project(or C)
CdArrΣprime= project(and C)
Table VIALGORITHM FOR COMPUTING THE PROJECTIONS (37)
input CΣinΣoutΣprimeinΣprimeout output Cprime
let order(cannot maymustlein) = cannot lein may lein must
order(cannot maymustleout) =
must le may
cannot le mayin let rest(X) =
if X has not been visitedthen
1 mark X visited2 for every α isin Σprime do
21 let Y = ε-closure(Σminus Σprime next(αX))22 let m = OpmC(q α) | q isin X
where Op = if α isin Σprimein then orin else andout
23 add to Cprime a transition (Xα Y ) with modality m24 rest(Op Y )
done
let restrict(C) =1 let X0 = ε-closure(Σminus Σprime q0)2 set initial state of Cprime to X0
3 rest(OpX0)4 reduce Cprime5 return Cprime
Table VIIALGORITHM FOR COMPUTING THE RESTRICTION CdarrΣprime
exists an action e and a state pair (qR) in CCdarrΣprime such thate has modality must in q and does not have modality mustin R We prove by contradiction that no such reachable statepair (qR) and action e exist Remark that by definition of therestriction q isin R The restriction is assumed to be in reducedform meaning that it does not contain inconsistent states Twocases have to be considered
1) Action e has modality cannot in R Several sub-caseshave to be considered depending on the IO status ofe and on the fact that the reduction of the restrictionhas turned a may modality for e into a cannot In allcases action e has modality cannot or may in q which
RR ndeg 8147
Contracts for System Design 40
contradicts the assumption2) Action e has modality may in R This implies that e also
has modality may in q which contradicts the assumptionThis finishes the proof of the lemma 2
The following holds by Lemma 10
CdarrΣprime otimes (CCdarrΣprime ) CCCdarrΣprime has no inconsistent state
(CdarrΣprime CCdarrΣprime ) has no incompatible pair of states(40)
By Lemma 11 the only property for checking is the consis-tency of CdarrΣprime This is a significant improvement comparedto the issues raised by the refined projection as explained inthe paragraph following (39) Decomposition (40) can be usedwhile sub-contracting through the following algorithm
Algorithm 1 We are given some system-level contract CThe top-level designer guesses some topological architectureaccording to (35) Then she recursively decomposes
C = C0 C0darrΣ1otimes C1
C0darrΣ1otimes C1darrΣ2
otimes C2 C0darrΣ1
otimes otimes Cnminus1darrΣn
=def C(Σ1) otimes otimes C(Σn)
(41)
which ultimately yields a refinement of C by a compatiblecomposition of local sub-contracts 2
Discussion The operations of projection and restrictionthat we introduced here can probably be made be genericat the level of the meta-theory Observe however that suchoperations explicitly refer to the notion of sub-alphabet whichdoes not exist at the level of the meta-theory In additionModal Interfaces are the only concrete theory in which variablealphabets are properly supported For these two reasons wepreferred to develop these operations for Modal Interfacesonly
F Observers
Here we develop observers for a Modal InterfaceC = (ΣinΣout Q q0rarr 99K) having no inconsistent statemeaning that rarrsube99K With this consistency assumption inforce observers are then obtained as follows with referenceto Definition 2bull Condition 2 of Definition 7 boils down to requiring thatE times Cmust simulates E Simulation testing can thus beused to check this call bE
C(E) the corresponding verdictbull To test for implementations we first construct the max-
imal environment EC and apply testing to check sim-ulation of EC times M by Cmay call bM
C1 the corre-sponding verdict Performing this requires maintainingpairs of states ((qE qM ) (qE q)) in simulation relation(qE qM )le(qE q) For any such pair of states let bM
C2 de-note the verdict answering whether (qE qM )
αminusrarrECtimesMholds each time q αminusrarr holds for any α isin Σout Theoverall verdict for implementation testing is then
bMC1(EC timesM) and bM
C2(EC timesM)
Lemma 3 for generic observers specializes to the followingeffective semi-decision procedure
Lemma 121) If bE
C outputs F then C is incompatible2) If bM
C1 and bMC2 outputs F then C is inconsistent
G Bibliographical note
As explained in [72] [56] [127] [83] [165] [166] Inter-face Theories make no explicit distinction between assump-tions and guarantees
Interface Automata variants and extensions InterfaceAutomata were proposed by de Alfaro and Henzinger [72][70] [5] [54] as a candidate theory of interfaces In thesereferences Interface Automata focused primarily on parallelcomposition and compatibility Quoting [72]
ldquoTwo interfaces can be composed and are compatibleif there is at least one environment where they canwork togetherrdquo
The idea is that the resulting composition exposes as aninterface the needed information to ensure that incompatiblepairs of states cannot be reached This can be achieved byusing the possibility for a component to refuse selectedinputs from the environment at a given state [72] [56] Incontrast to our development in Section VIII-B no sets ofenvironments and implementations are formally associated toan Interface Automaton in the original developments of theconcept A refinement relation for Interface Automata wasdefined in [72]mdashwith the same definition as oursmdashit couldnot however be expressed in terms of sets of implementationsProperties of interfaces are described in game-based logicseg ATL [9] with a theoretical high-cost complexity Theoriginal semantics of an Interface Automaton was given by atwo-player game between an input player that represents theenvironment (the moves are the input actions) and an outputplayer that represents the component itself (the moves are theoutput actions) Despite the availability of partial results [83]the framework of Interface Automata lacks support for theconjunction of interfaces in a general setting and does notoffer the flexibility of modalities Sociable Interfaces [71]combine the approach presented in the previous paragraphwith interface automata [72] [73] by enabling communicationvia shared variables and actions45 First the same actioncan appear as a label of both input and output transitionsSecondly global variables do not belong to any specificinterface and can thus be updated by multiple interfaces Con-sequently communication and synchronization can be one-to-one one-to-many many-to-one and many-to-many Symbolicalgorithms for checking the compatibility and refinement ofsociable interfaces have been implemented in TICC [3]Software Interfaces were proposed in [55] as a pushdownextension of interface automata (which are finite state) Push-down interfaces are needed to model call-return stacks ofpossibly recursive software components This paper contains
45This formalism is thus not purely synchronous and is mentioned in thissection with a slight abuse
RR ndeg 8147
Contracts for System Design 41
also a comprehensive interface description of Tiny OS46 anoperating system for sensor networks Moore machines andrelated reactive synchronous formalisms are very well suitedto embedded systems modeling Extending interface theoriesto a reactive synchronous semantics is therefore meaningfulSeveral contributions have been made in this direction startingwith Moore and Bidirectional Interfaces [56] In Moore Inter-faces each variable is either an input or an output and thisstatus does not change in time Bidirectional Interfaces offeradded flexibility by allowing variables to change IO statusdepending on the local state of the interface Communicationby shared variable is thus supported and for instance allowsdistributed protocols or shared buses to be modeled In bothformalisms two interfaces are deemed compatible wheneverno variable is an output of both interfaces at the same timeand every legal valuation of the output variables of oneinterface satisfies the input predicate of the other The mainresult of the paper is that parallel composition of compatibleinterfaces is monotonic with respect to refinement Note thatMoore and Bidirectional Interfaces force a delay of at leastone transition between causally dependent input and outputvariables exactly like Moore machines In [83] the frame-work of Synchronous Interfaces is enriched with a notion ofconjunction (called shared refinement) This development wasfurther elaborated in [78] In Moore interfaces legal values ofthe input variables and consequent legal values of the outputvariables are not causally related Synchronous Relational In-terfaces [177] [178] have been proposed to capture functionalrelations between the inputs and the outputs associated toa component More precisely inputoutput relations betweenvariables are expressed as first-order logic formulas over theinput and output variables Two types of composition are thenconsidered connection and feedback Given two relationalinterfaces C1 and C2 the first one consists in connecting someof the output variables of C1 to some of the input variablesof C2 whereas feedback composition allows one to connectan output variable of an interface to one of its own inputsThe developed theory supports refinement compatibility andalso conjunction The recent work [112] studies conditions thatneed to be imposed on interface models in order to enforceindependent implementability with respect to conjunctionFinally [53] develops the concept of simulation distancesfor interfaces thereby taking robustness issues into accountby tolerating errors Finally Web services Interfaces wereproposed in [38]
The discussion of variants and extensions related to timeresources and probability is deferred to corresponding sec-tions
Modal Interfaces variants and extensions Propertiesexpressed as sets of traces can only specify what is forbiddenUnless time is explicitly invoked in such properties it isnot possible to express mandatory behaviors for designsModalities were proposed by Kim Larsen [130] [11] [46] asa simple and elegant framework to express both allowed and
46httpwwwtinyosnet
mandatory properties Modal Specifications basically consist inassigning a modality may or must to each possible transition ofa system They have been first studied in a process-algebraiccontext [130] [125] in order to allow for loose specificationsof systems Since then they have been considered for automata[128] and formal languages [163] [164] and applied to a widerange of application domains (see [11] for a complete survey)Informally a must transition is available in every componentthat realizes the modal specification while a may transitionneeds not be A modal specification thus represents a set ofmodelsmdashunfortunately models of modal transition systems areoften call ldquoimplementationsrdquo in the literature which is unfor-tunate in our context We prefer keeping the term ldquomodelrdquoand reserve the term ldquoimplementationrdquo for the entities intro-duced in Sections VIII-B and VIII-C Modal Specificationsoffer built-in conjunction of specifications [129] [167] Theexpressiveness of Modal Specifications has been characterizedas a strict fragment of the Hennessy-Milner logic in [46]and also as a strict fragment of the mu-calculus in [89] Theformalism is rich enough to specify safety properties as well asrestricted forms of liveness properties Modal Interfaces withthe right notion of compatibility were introduced in [165][166] and the problem of alphabet equalization with weakand strong alphabet extensions was first correctly addressed inthe same references In [23] compatibility notions for ModalInterfaces with the passing of internal actions are definedContrary to the approach reviewed before a pessimistic viewof compatibility is followed in [23] ie two Modal Interfacesare only compatible if incompatibility between two interfacescan occur in any environment A verification tool called MIOWorkbench is available The quotient of Modal Specificationswas studied in [124] [164] Determinism plays a role in themodal theory Non-deterministic Modal Interfaces have pos-sibly non-deterministic io-automata as class of componentsThey are much more difficult to study than deterministic onesand corresponding computational procedures are of highercomplexity A Modal Interface is said to be deterministic if itsmay-transition relation is deterministic For nondeterministicModal Interfaces modal refinement is incomplete [128] thereare nondeterministic Modal Interfaces C1 and C2 for whichthe set of implementations of C1 is included in that of C2without C1 being a modal refinement of C2 Hence refinementaccording to the meta-theory is not exactly instantiated butonly approximated in a sound way A decision procedure forimplementation inclusion of nondeterministic Modal Interfacesdoes exist but turns out to be EXPTIME-complete [12] [25]whereas the problem is PTIME-complete if determinism isassumed [167] [26] The benefits of the determinism assump-tion in terms of complexity for various decision problemson modal specifications is underlined in [26] The ldquomergerdquoof non-deterministic Modal Specifications regarded as partialmodels has been considered in [179] This operation consistsin looking for common refinements of initial specifications andis thus similar to the conjunction operation presented hereIn [179] [90] algorithms to compute the maximal commonrefinements (which are not unique when non-determinism is
RR ndeg 8147
Contracts for System Design 42
allowed) are proposed They are implemented in the toolMTSA [82] Assumeguarantee contracts viewed as pairs ofModal Specifications were proposed in [96] It thus com-bines the flexibility offered by the clean separation betweenassumptions and guarantees and the benefits of a modalframework Several operations are then studied refinementparallel composition conjunction and priority of aspects Thislast operation composes aspects in a hierarchical order suchthat in case of inconsistency an aspects of higher priorityoverrides a lower-priority contract The synthesis of ModalInterfaces from higher-level specifications has been studiedfor the case of scenarios In [173] Existential Live SequenceCharts are translated into Modal Specifications hence provid-ing a mean to specify modal contracts Regarding extensionsAcceptance Interfaces were proposed by J-B Raclet [163][164] Informally an Acceptance Interface consists of a set ofstates with for each state a set of ready sets where a readyset is a set of possible outgoing transitions from that stateIn intuitive terms an Acceptance Interface explicitly specifiesits set of possible models Acceptance Interfaces are moreexpressive than Modal Interfaces but at the price of a pro-hibitive complexity for the various relations and operators ofthe theory Modal Interfaces have been enhanced with markedstates by Caillaud and Raclet [27] Having marked statessignificantly improves expressiveness It is possible to specifythat some state must be reachable in any implementation whileleaving the particular path for reaching it unspecified As anexample of use Modal Interfaces with marked states have beenapplied in [4] to the separate compilation of multiple clockedsynchronous programs
The discussion of variants and extensions related to timeresources and probability is deferred to corresponding sec-tions
Features of our presentation The presentation of in-terface theories in this paper is new in many aspects Forthe first time all interface theories are clearly cast in theabstract framework of contracts following our meta-theory Inparticular the association to an interface C of the two sets ECandMC is new It clarifies a number of concepts In particularthe interface theories inherit from the properties of the meta-theory without the need for specific proofs The projectionand restriction operators for Modal Interfaces are new Castinginterface theories into the meta-theory was developed for thebasic interface theories only It would be useful to extend thisto the different variants and see what the benefit would beBenoicirct Caillaud has developed the MICA tool [49] whichimplements Modal Interfaces with all the operations andservices discussed in this section
IX PANORAMA TIMED INTERFACE THEORIES
In this section we develop an instance of an interface theoryfor timed systems This section is meant to be illustrative ofour approach to concrete instances of contract theories It doesnot claim to expose the good instance Our presentation buildson top of [35] To simplify the exposure we restrict ourselves
to the case of a fixed alphabet Σ As usual now we begin withthe component model
A Components as Event-Clock Automata
Timed Automata [6] constitute the basic model for systemsdealing with time and built on top of automata In wordstimed automata are automata enhanced with clocks Predicateson clocks guard both the states (also called ldquolocationsrdquo) andthe transitions Actions are attached to transitions that resultin the resetting of some of the clocks
Event-Clock Automata [7] [8] [35] form a subclass oftimed automata where clock resets are not arbitrary eachaction α comes with a clock hα which is reset exactlywhen action α occurs The interest of this subclass is thatevent-clock automata are determinizable which facilitates thedevelopment of a (modal) theory of contracts The definitionof event-clock automata requires some prerequisites
We are given an underlying finite set H of clocks A clockvaluation is a map ν H 7rarr R+ where R+ denotes the set ofnonnegative reals The set of all clock valuations is denotedby V We denote by 0 the clock valuation assigning 0 to allclocks and by ν + t the clock obtained by augmenting ν withthe constant t For ν a valuation the valuation ν[0hα] assigns0 to hα and keeps the valuation of other clocks unchanged
Clocks can be used to define guards The class of guardsconsidered by [35] consists of finite conjunctions of expres-sions of the form h sim n where h is a clock n is an integerand sim is one of the following relations ltle=ge gt Forg a guard write ν |= g to mean that valuation ν satisfiesguard g For N an integer G(H N) denotes the set of allguards over H involving only integers n lt N + 1 and wewrite G(H) = G(Hinfin)
Definition 13 An event-clock automaton over alphabet Σis a tuple M = (ΣinΣout Q q0 Nrarr) wherebull ΣinΣout Q q0 are as for io-automata elements of Q
are called locationsbull HΣ = hα | α isin Σ is the set of clocksbull N is a finite integer and rarrsube Q times G(HΣ N) times Σ times Q
is the transition relation write qgαminusrarr qprime to mean that
(q g α qprime) isinrarr
The semantics of M is a timed transition system with infinitestate space QtimesV defined as follows transition q
gαminusrarr qprime canfire from state (q ν) isin Q times V iff ν |= g as a result of thisfiring the clock hα is reset to zero thus resulting in the newstate (qprime ν[0hα]) isin Q times V In our Timed Interface theorycomponents are event-clock automata that are
1) deterministic in the following sense
forall(q α ν) isin Qtimes Σtimes V there is at mostone transition q
gαminusrarr qprime such that ν |= g(42)
2) receptive meaning that
forallq isin Qforallα isin Σin qTαminusrarr
holds where T denotes the trivial guard ldquotruerdquo
RR ndeg 8147
Contracts for System Design 43
Instead of further developing our theory we will show how totake advantage of previously developed theories by showingthat event-clock automata are finitely encoded by means of re-gion automata that we introduce next Fix bound N A regionis an equivalence class ϑ of clock valuations ν satisfying thesame set of guards from G(H N) Denote by Θ the set of allsuch regions (bound N is understood) For ϑ isin Θ consider
τ(ϑ) = ϑprimeprime | existνprimeprime isin ϑprimeprimeexistν isin ϑexistt ge 0 st νprimeprime = ν + t
which is the set of all regions that can be obtained from ϑ byletting time elapse Finally for ϑ a region and α an actionϑdarrα is the region obtained from ϑ by resetting clock hα Usingthese notations we associate to each event-clock automatonM = (ΣinΣout Q q0 Nrarr) a Region Automaton which isthe following finite state automaton
R [M ] =(Σin timesΘΣout timesΘ QtimesΘ (q00)rArr
)(43)
where the transition relation rArr is given by
(q ϑ)ϑrdquoα
===rArr (qprime ϑprime) iff
q gαrarr qprime withϑrdquo sube τ(ϑ) cap g andϑprime = ϑrdquodarrα
(44)
Vice-versa any Region Automaton R defines a uniqueevent-clock automaton M [R] by deducing from (44) theminimal guards associated to its transitions Starting from anevent-clock automaton M M [R [M ]] is related to M by astrengthening of its guards However it holds that47
R [M [R [M ]]] = R [M ] (45)
Under the above correspondence components in theevent-clock automaton domain are mapped to components inthe io-automaton domain
B Modal Event-Clock Specifications
In this section we develop the framework of con-tracts on top of our component model of deterministicevent-clock automata To simplify we only develop the caseof a fixed alphabet Σ
Definition 14 A Modal Event-Clock Specification (MECS)is a tuple C = (ΣinΣout Q q0rarr 99K) where ΣinΣoutQ q0 are as in Interface Automata and
rarr sube 99K sube Qtimes G(HΣ)times ΣtimesQ
Using the same construction as above MECS C induces aRegion Modal Event-Clock Specification (RMECS) denoted byR [C] which is a Modal Interface according to Definition 7Accordingly R [C] defines a pair (ER[C]
MR[C]) of sets of
io-automata and we finally define
(EC MC ) =def
(M[ER[C]
]M[MR[C]
])The map C 7rarr R [C] satisfies48
R [M [R [C]]] = R [C] (46)
47It is shown in [35] that M 7rarr R [M ] forms a Galois connection48Again it is a Galois connection [35]
This allows us to lift the contract theory of RMECS (whichare Modal Interfaces) to a contract theory of MECS Whilethis is conceptually elegant it is not efficient since movingfrom MECS to RMECS (from timed models to region models)is ExpTime which is costly To cope with this difficulty theauthors of [35] have provided direct cheap formulas expressedin the MECS domain These formulas provide a partial answerto the issue of complexity In particular the following lemmaholds that was stated and proved in [35]
Lemma 13 For C1 and C2 two MECS having identical inputand output alphabets define C1andC2 symbolically with rules ofthe following form
Glbmay q1
g1α99K qprime1 and q2
g2α99K qprime2
(q1 q2)g1andg2α99K (qprime1 q
prime2)
Glbmustleft q1
g1αrarr qprime1 and q2g2α qprime2
(q1 q2)g1andg2αrarr (qprime1 q
prime2)
where denotes ad libitumrarr or 99K and with Glbmustright
defined symmetrically (see [35] for the complete set of rules)Then we have
R [C1andC2] = R [C1]andR [C2] (47)
Inconsistent states for both sides of (47) correspond A similarlemma holds for contract quotient C1C2 Unfortunately thepruning of inconsistent states cannot be performed directlyin the MECS domain and mapping to regions is mandatoryNevertheless dedicated rules to handle directly inconsistentstates exist in the symbolic versions of the different relationsand operations on MECS As a result the computation ofthe regions is only mandatory when the designer aims atcleaning its contract by pruning the inconsistencies A similarlemma holds for contract composition C1otimesC2 Again pruningincompatible pairs of states cannot be performed directly inthe MECS domain and mapping to regions is mandatory49
C Bibliographical note
This note focuses on interface types of framework Thereader is referrect to the bibliographical note of Section VII-Gfor extensions of AG-contracts addressing time
A first interface theory able to capture the timing aspectsof components is Timed Interfaces [74] Timed Interfacesallows specifying both the timing of the inputs a componentexpects from its environment and the timing of the outputsit can produce Compatibility of two timed interfaces is thendefined and refers to the existence of an environment such thattiming expectations can be met The Timed Interface theoryproposed in [68] fills a gap in the work introduced in [74]by defining a refinement operation In particular it is shownthat compatibility is preserved by refinement This theoryalso proposes a conjunction and a quotient operation and is
49Authors of [35] do not mention this fact for the following reason Theydo not consider the issue of receptiveness for components and therefore theissue of compatibility does not arise
RR ndeg 8147
Contracts for System Design 44
implemented in the tool ECDAR [69] Timed SpecificationTheories are revisited from a linear-time perspective in [60]
The first timed extension of modal transition systems waspublished in [52] It is essentially a timed (and modal) versionof the Calculus of Communicating Systems (by Milner) Basedon regions tool support for refinement checking were imple-mented and made available in the tool EPSILON [95] Anothertimed extension of Modal Specifications was proposed in [36]In this formalism transitions are equipped with a modality anda guard on the component clocks very much like in timedautomata For the subclass of modal event-clock automataan entire algebra with refinement conjunction product andquotient has been developed in [33] [34]
Resources other than time were also consideredmdashwithenergy as the main target Resource Interfaces [57] can beused to enrich a variety of interface formalisms (InterfaceAutomata [72] AssumeGuarantee Interfaces [73] etc) witha resource consumption aspect Based on a two player game-theoretic presentation of interfaces Resource Interfaces allowfor the quantitative specification of resource consumptionWith this formalism it is possible to decide whether compo-sitions of interfaces exceed a given resource usage thresholdwhile providing a service expressed either with Buumlchi condi-tions or thanks to quantitative rewards Because resource usageand rewards are explicit rather then being defined implicitlyas solutions of numerical constraints this formalism doesnot allow one to reason about the variability of resourceconsumption across a set of logically correct models
X PANORAMA PROBABILISTIC INTERFACE THEORIES
Probabilistic systems are non-deterministic systems inwhich choice is controlled by random trial Such systems areuseful for many purposes ranging from physical or biologicalsystems to security protocols intrusion detection and up tosafety and reliability analyses in system design In this sectionas another illustration of our meta-theory we develop a simpleinstance of a probabilistic interface theory Again to simplifythe exposure we restrict ourselves to the case of a fixedalphabet Σ
A Components as Probabilistic Automata
We first introduce Probabilistic Automata with inputs andoutputs also called InputOutput Markov Decision Processesand then we motivate their use in safety analysis
Definition 15 A Probabilistic Automaton with inputs andoutputs (io-PA) is a tuple M = (ΣinΣout Q q0Πrarr)wherebull Σin and Σout are disjoint finite input and output alpha-
bets such that Σin cup Σout = Σbull Q is a finite set of states and q0isinQ is the initial state
we denote by Π(Q) the finite set of all probabilities overQ also called the probabilistic states
bull rarr sube Qtimes ΣtimesΠ(Q) is the transition relation we writeq
αminusrarr π to mean (q α π) isinrarr and q αminusrarr if q αminusrarr πholds for some π
bull In addition we require M to be deterministic in thefollowing sense for any pair (q α) isin Q times Σ q αminusrarr πand q αminusrarr πprime implies π = πprime
A run σ of M starts from initial state q0 and then progressesby a sequence of steps of the form q
αminusrarr π 7rarr qprime wheresupplementary transitions π 7rarr qprime are drawn at random byselecting a successor state qprime isin Q according to probabilityπ A strategy consists in fixing a function ϕ Q rarr Σand using it to select the next action Once a strategy hasbeen fixed jumping from a probabilistic state to the next onegives raise to a time-invariant Markov Chain whose invariantprobability can be computed or statistically estimated Whenall probabilistic states are Dirac measures δqprime selecting qprime asa next state with probability one io-PA M boils down to anio-automaton Thus io-PA subsume io-automata
Two io-PA M1 and M2 are composable if Σout1 capΣout
2 = emptyTwo composable io-PA M1 and M2 compose into M = M1timesM2 as follows
(q1 q2)αminusrarrM π1 otimes π2 iff
q1
αminusrarrM1π1 and
q2αminusrarrM2
π2(48)
where otimes denotes the product of two probabilities thus makingthe two components independent Parallel composition definedin this way has all the desired properties
Similarly the concept of simulation relation is easily de-rived from that of io-automata by preserving probabilitiesfor Mi i = 1 2 two io-PA and two states qi isin Qi say that q1
simulates q2 written q2le q1 if there exists a surjective mapf Q1 7rarr Q2 such that
forallα st q2αminusrarr2 π2 existπ1 isin Π(Q1)
dArr (49) q1αminusrarr1 π1
π2(qprime2) =sumf(qprime1)=qprime2
π1(qprime1)
π1(qprime1) gt 0rArr f(qprime1) le qprime1
Observe that since we consider only deterministic io-PAthere exists at most one π2 such that q2
αminusrarr2 π2 hence thereis no need to quantify over π2 in the precondition of (49) Inprobability theory relation π2(qprime2) =
sumf(qprime1)=qprime2
π1(qprime1) writesπ2 = f(π1) Say that M1 simulates M2 written M2leM1 ifq20leq10 Simulation relation is preserved by composition IfM2leM1 then every strategy ϕ2 Q2 7rarr Σ2 defined over M2
has its counterpart into a matching strategy ϕ1 Q1 7rarr Σ1
over M1 by setting ϕ1(q1) = ϕ2(f(q1)) For i = 1 2 letΩi = QN
i be the set of all sequences of states of Qi and let(ΩiPi) i = 1 2 be the two resulting probability spaces whenmatching strategies are used for M1 and M2 Then the mapf induces a measurable map ψ = (f f ) Ω1 7rarr Ω2 suchthat
intZ(ω2)dP2(ω2) =
intZ(ψ(ω1))dP1(ω1) In particular
the probability distributions with respect to P1 and P2 of anymeasurable function depending only on the successive actionsperformed are identical
The natural use of io-PAs for safetyreliability analysis isto capture faulty situations through states Component states
RR ndeg 8147
Contracts for System Design 45
are partitioned into safe states and faulty states that can beequipped with different fault labels (names of states can dothis no semantic adaptation is needed) The probabilistic partof io-PAs naturally captures the spontaneous occurrence offaults When in a faulty state a component outputs actionsthat can either be used to model fault propagation or maybe alarms for use in system supervision Input actions in afaulty state can be used to either model denial of servicefrom other components (thus resulting in a risk of movingto a faulty state) or may be reconfiguration actions Thusspontaneous occurrence of failures with fault propagation iscaptured by this framework To summarize io-PAs offer anatural framework in which to combine functional and safetyviewpoints
B Simple Modal Probabilistic Interfaces
By following the same steps as for Modal Interfacessee Definition 7 we can define Simple Modal ProbabilisticInterfaces as pairs C = (Cmay Cmust) of io-PAs There is nonew difficulty in doing this Expressiveness of this frameworkhowever is modest whence the attribute ldquosimplerdquo When usedin the context of safetyreliability analysis Simple ModalProbabilistic Interfaces support the specification of fault ac-commodation in systems For example one can specify abouta componentbull that it does not accommodate denial of service inputs
representing fault propagation are disallowed (ldquomust notoccurrdquo)
bull that it must be prepared to possible denial of serviceinputs representing fault propagation are allowed (ldquomustbe acceptedrdquo)
bull that it never generates spontaneous failures actions lead-ing to a probabilistic state from which a faulty state can beimmediately reached are disallowed (ldquomust not occurrdquo)
bull that spontaneous failures are unavoidable actions leadingto a probabilistic state from which a faulty state can beimmediately reached are allowed (ldquomust be acceptedrdquo)
One could argue that io-PA by themselves offer a similarexpressiveness by playing with probabilities Simple ModalProbabilistic Interfaces however offer the full algebra ofcontracts which io-PA donrsquot
C Bibliographical note
This note focuses on interface types of framework Thereader is referred to the bibliographical note of Section VII-Gfor extensions of AG-contracts addressing probability
Exactly like the Interval Markov Chain (IMC) for-malism [116] they generalize Constraint Markov Chains(CMC) [50] are abstractions of a (possibly infinite) sets ofDiscrete Time Markov Chains Instead of assigning a fixedprobability to each transition transition probabilities are keptsymbolic and defined as solutions of a set of first orderformulas Variability across implementations is made possiblenot only with symbolic transition probabilities but also thanksto the labelling of each state by a set of valuations or setsof atomic propositions This allows CMCs to be composed
thanks to a conjunction and a product operators While theexistence of a residuation operator remains an open problemCMCs form an interface theory in which satisfaction andrefinement are decidable and compositions can be computedusing quantifier elimination algorithms In particular CMCswith polynomial constraints form the least class of CMCsclosed under all composition operators Abstract ProbabilisticAutomata (APA) [79] is another specification algebra withsatisfaction and refinement relations product and conjunctioncomposition operators Despite the fact that APAs generalizeCMCs by introducing a labeled modal transition relationdeterministic APAs and CMCs coincide under the mild as-sumption that states are labeled by a single valuation Forboth formalisms parallel composition is restricted to non-interacting components since alphabets of actions must bedisjoint
Our formalism of Simple Modal Probabilistic Interfaces ex-hibits the whole contract algebra Regarding limitations unlikeIMC CMC and APA this model does not allow for specifyingfamilies of transition probabilities and hence it cannot helpfor quantitative reasoning about reliability analysis
XI THE PARKING GARAGE AN EXAMPLE INREQUIREMENTS ENGINEERING
In this section we develop the parking garage exampleintroduced in Section IV-C Some of the material is repeatedfor better readability Despite being simple and small this ex-ample quickly becomes complex for reasons that are intrinsicto the formal management of requirements The MICA tooldeveloped by Benoicirct Caillaud was used to develop it [49]
Requirements are written in constrained English languageand then translated into Modal Interfacesmdashwhile the pre-sented translation is manual automatic translation can beenvisioned50 Once this is completed contracts are formallydefined and the apparatus of contracts can be used In par-ticular important properties regarding certification can beformally defined and checked eg consistency compatibilitycorrectness and completeness In addition support is providedfor turning top-level requirements into an architecture of sub-systems each one equipped with its own requirements Thelatter can then be submitted to independent suppliers forfurther development
A The contract framework
We shall use Modal Interfaces (with variable alphabet) asdeveloped in Sections VIII-C and subsequent ones There arethree main reasons for this choice
1) By offering the may and must modalities Modal Inter-faces are well suited to express mandatory and optionalbehaviors in the specification which we consider impor-tant for requirements engineering
50In fact the contract specification languages proposed in the projectsSPEEDS [29] and CESAR (httpwwwcesarprojecteu) are examples oftranslations from a constrained English language to a formal models ofcontracts similar to Modal Interfaces
RR ndeg 8147
Contracts for System Design 46
2) Being large sets of requirements structured into chaptersrequirements documents are a very fragmented style ofspecification Only Modal Interfaces offer the neededsupport for an accurate translation of concepts such asldquoset of requirementsrdquo ldquoset of chaptersrdquo together with aqualification of who is responsible for each requirement(the considered component or sub-system versus itsenvironment)
3) As we shall see at the top-level conjunction prevailsHowever as soon as the designer refines the top-levelrequirements into an architecture of sub-systems com-position enters the game Turning a conjunction of top-level requirements into a composition of sub-systemsspecifications thus becomes a central task Only ModalInterfaces provide significant assistance for this
Overall the problem considered in claim 3) can be stated asfollows The designer begins with some system-level contractC which is typically specified as a conjunction of viewpointsandor requirements The designer guesses some topologicalarchitecture by decomposing the alphabet of actions of C as
Σ =⋃iisinI Σi Σi = Σin
i ] Σouti (50)
such that composability conditions regarding inputs and out-puts hold Once this is done we expect our contract frameworkto provide help in generating a decomposition of C asotimes
iisinI Ci C (51)
where sub-contract Ci has alphabet Σi = Σini ] Σout
i Guess-ing architectural decomposition (50) relies on the designerrsquosunderstanding of the system and how it should naturallydecomposemdashthis typically is the world of SysML Findingdecomposition (51) is however technically difficult in that itinvolves behaviors The algorithmic means that were presentedin Section VIII-E provide the due answer In this ParkingGarage example we will use both the abstracted projectionand the restriction that were developed in that section
B Top level requirements
In this section we begin with the top-level requirementsThe system under specification is a parking garage subjectto payment by the user At its most abstract level the re-quirements document comprises the different chapters gatepayment and supervisor see Table VIII The gate chapterwill collect the generic requirements regarding entry and exitgates These generic requirements will then be specialized forentry and exit gates respectively
0
gate_close
1gate_opengate_close
vehicle_passgate_open
Figure 7 Requirement Rg1 specified as an io-automaton Prefix ldquordquoindicates an input and prefix ldquordquo indicates an output
gateRg1ldquovehicles shall not pass when gate is closedrdquo see Fig 7Rg2 after vehicle_pass vehicle_pass is forbiddenRg3 after gate_open gate_open is forbidden and
after gate_close gate_close is forbiddenpaymentsupervisor
Table VIIITHE TOP-LEVEL SPECIFICATION WITH CHAPTER gate EXPANDED
REQUIREMENTS WRITTEN IN italics ARE ASSUMPTIONS UNDER WHICHgate SHOULD OPERATE
Focus on the ldquogaterdquo chapter It consists of the three re-quirements shown on Table VIII Requirement Rg1 is bestdescribed by means of an io-automaton shown in Figure 7mdashwe provide an informal textual explanation for it betweenquotes51 The other two requirements are written using con-strained natural language which can be seen as a boilerplatestyle of specification Prefix ldquordquo indicates an input and prefixldquordquo indicates an output
The first two requirements are not under the responsibilityof the system since they rather concern the car driver Thus itdoes not make sense to include them as part of the guaranteesoffered by the system Should we remove them This wouldbe problematic If drivers behave the wrong way unexpectedthings can occur for sure The conclusion is that 1) we shouldkeep requirements Rg1 and Rg2 and 2) we should handlethem differently than Rg3 which is a guarantee offered by thesystem Indeed Rg1 and Rg2 are assumptions under whichthe gate operates as guaranteed In the sequel assumptions arewritten in italics
So far we have specified gate as a list of requirementsRequirement Rg1 specified as an io-automaton can be con-sidered formal Requirements Rg2 and Rg3 are formulatedin constrained natural language and are ready for subsequentformalization eg as io-automata Are we done Not yetWe need to give a formal meaning to what it means to havea collection of requirements and what it means to distinguishassumptions from guarantees The contract framework wedevelop next will provide support for this
C Formalizing requirements as contracts
We shall use Modal Interfaces (with variable alphabet) asdeveloped in Sections VIII-C and subsequent ones Thuswe first need to explain how the specification of ldquogaterdquo inTable VIII translates into Modal Interfaces
We first observe that each requirement Rgj of Table VIIIis a sentence that can be formalized as an io-automaton see
51 We take the convention that the variables of the resulting io-automatonare those mentioned in the text of the requirement Some adjustment is neededto this convention however as exemplified by Figure 7 Suppose that somerequirement says ldquogate_open never occursrdquo This is translated by havingno mention of gate_open in the corresponding io-automaton To expressthis ldquonegativerdquo fact we must keep track of the fact that gate_open belongsto the alphabet of actions of the io-automaton Thus when performing thetranslation the explicit list of inputs and outputs should be explicitly givenTo avoid such additional notational burden we have cheated by omitting thisunless necessary
RR ndeg 8147
Contracts for System Design 47
Figure 7 for such a formalization of requirement Rg1 Ac-cordingly each chapter D = gatepaymentsupervisorof Table VIII is structured as a pair
D = ((A1 Am) (G1 Gn)) (52)
where the Ais (the assumptions) and the Gjs (the guarantees)are io-automata in which all involved actions possess thesame status (input or output) throughout all Ais and Gjs Thetranslation of a specification of the form (52) into a ModalInterface is performed by applying the following two series ofrules
Rules 1 We adopt the following rules for the translation ofguarantees (in the form of io-automata) into Modal InterfacesRG
1 Unless otherwise explicitly stated transitions labeledby an output action of the considered system are givena may modality the rationale for doing this is that thedefault semantics for guarantees is ldquobest effortrdquo A mustmodality is assigned if the requirement specifies itmdashegby having a ldquomustrdquo in the sentence
RG2 Transitions labeled by an input action of the considered
system are given a must modality the rationale for doingthis is that as part of its guarantees the component mustnot refuse an input that is ldquolegallyrdquo submitted by theenvironment
RG3 Guarantees in a same requirements chapter D combine
by conjunctionApplying Rules 1 to the set of guarantees of D yields thecontract encoding these guarantees denoted by GD 2
Performing this for the single guarantee Rg3 of gate yieldsthe Modal Interface shown in Figure 8
0 1gate_opengate_close
0 1gate_opengate_close
Figure 8 Translating the guarantee Rg3 of gate as an io-automaton (top)and then as a Modal Interface Ggate (bottom) using Rules 1
Rules 2 We adopt the following rules for the translationof assumptions (in the form of io-automata) into ModalInterfacesRA
1 We exchange the status inputoutput in every assump-tion thus taking the point of view of the environment
RA2 Having done this we apply Rules 1 to the assumptions
So far this yields a draft Modal Interface A that must besatisfied by every environment
RA3 This is not enough however as we really want envi-
ronments that submit all legal stimuli To ensure this wesimply turn in A all may transitions to must transitionswhich yields A
Applying Rules 2 to the set of assumptions of D yields theModal Interface AD encoding these assumptions 2
Performing this for the assumptions Rg1 and Rg2 of gateyields the Modal Interface shown in Figure 9
1 0
gate_close
1gate_opengate_close
gate_openvehicle_pass
2 0
gate_open
1vehicle_passgate_open
3 (11)
gate_close
(10)
gate_opengate_closevehicle_pass
gate_open
4 0
gate_close
1gate_openvehicle_passgate_close
gate_open
Figure 9 Translating the assumptions of gate as a Modal Interface Agate
using Rules 2 1 translation of Rg1 2 translation of Rg2 3 the resultingconjunction 4 the final result after applying rule RA
3 and renaming the states
So far we have represented any chapter D of the require-ments document as a pair of Modal Interfaces (AD GD) withmirroring inputoutput statuses for their actionsmdashevery inputof AD is an output of GD and vice-versa It is the merit ofModal Interfaces to allow for a direct representation of thispair of assumption and guarantee in the form of a single ModalInterface by using the following formula for A and G twoModal Interfaces with mirroring inputoutput statuses for theiractions
(AG) is represented by the quotient (AotimesG)A (53)
which is the contract characterizing the components thatimplement G in the context of A see Section V-E Performingthis for the whole chapter gate yields the Modal Interfaceshown in Figure 10 Some comments are in order regardingthis Modal Interfacebull Regarding the guarantees offered by the component
Allowed outputs possess a may modality which reflectsthat Guarantees specify what the component may deliverOther actions are forbidden
bull Regarding the context of operation Legal inputs to thegate (eg vehicle_through when exiting state ldquo1rdquo) havea must modality This complies with the intuition that
RR ndeg 8147
Contracts for System Design 48
gate(x) where x isinentry exitRg1(x) ldquovehicles shall not pass when x_gate is closedrdquo see Fig 7Rg2(x) after vehicle_pass vehicle_pass is forbiddenRg3 after x_gate_open x_gate_open is forbidden and after x_gate_close x_gate_close is forbidden
paymentRp1 ldquouser inserts a coin every time a ticket is inserted and only thenrdquo Fig omittedRp2 ldquouser may insert a ticket only initially or after an exit ticket has been issuedrdquo Fig omittedRp3 ldquoexit ticket is issued after ticket is inserted and payment is made and only thenrdquo Fig omitted
supervisorRg1(entry)Rg1(exit)Rg2(entry)Rg2(exit)Rs1 initially and after entry_gate close entry_gate open is forbiddenRs2 after ticket_issued entry_gate open must be enabledRs3 ldquoat most one ticket is issued per vehicle entering the parking and tickets can be issued only if requested
and ticket is issued only if the parking is not fullrdquo see Fig 12Rs4 ldquowhen the entry gate is closed the entry gate may not open unless a ticket has been issuedrdquo Fig omittedRs5 ldquothe entry gate must open when a ticket is issuedrdquo Fig omittedRs6 ldquoexit gate must open after an exit ticket is inserted and only thenrdquo Fig omittedRs7 ldquoexit gate closes only after vehicle has exited parkingrdquo Fig omitted
Table IXREQUIREMENTS FOR THE TOP-LEVEL
0
1vehicle_pass
2gate_open
vehicle_passgate_closegate_open
gate_close3vehicle_pass
gate_close
vehicle_pass
Figure 10 Chapter gate of the top-level requirements document translatedinto a Modal Interface Cgate
the component should not refuse legal stimuli from itsenvironment Violation of the contract by its environmentoccurs when an illegal input is submitted by the environ-ment (vehicle_through when exiting state 0 or state 3) Asa consequence the whole contract gets relaxed which isreflected by the move to the special state ldquo2rdquo from whichany action is allowedmdashsuch a state is often called a ldquotoprdquostate Note that this top state resulted from computing thequotient
The same procedure applies to all chapters gate paymentand supervisor of the top-level textual specification shownin Table IX (it is an expansion of Table VIII) In particu-lar the Modal Interfaces encoding chapters payment andsupervisor of the top-level are displayed in Figures 11 to 13Figure 13 showing the contract associated to the supervisor isunreadable and the reader may wonder why we decided to putit here We indeed wanted to show that when contract designis performed formally and carefully top-level contracts rapidlybecome complex even for modest sets of requirements So theformal management of requirements and their translation intoformal contracts must be tool-assisted
Finally the whole top-level contract C is the conjunctionof the contracts representing chapters gate payment and
supervisor of the top-level requirements document
C = Cgate and Cpayment and Csupervisor (54)
Owing to the complexity of Csupervisor shown in Figure 13we do not show the Modal Interface C formalizing the fulldocument Nevertheless the latter was generated and can thenbe exploited as we develop next The above specificationonly covers the functional viewpoint of the system Otherviewpoints might be of interest as well eg regarding timingbehavior and energy consumption They would be developedwith the same method and combined to the above contract Cusing conjunction
D Sub-contracting to suppliers
In this section we apply the technique developed in Sec-tion VIII-E for generating an architecture of sub-systems withtheir associated sets of requirements Each sub-system canthen be submitted for independent development to a differentsupplier
The duty of the designer is to specify an architecture ldquoagravela SysMLrdquo as shown on Figure 14 Some comments arein order regarding this architecture The considered instanceof a parking garage consists of one entry gate one exitgate and one payment machine Compare with the top-levelspecification of Table IX The latter comprises a generic gatea payment machine and a supervisor each one with its setof requirements In contrast the architecture of Figure 14involves no supervisor The supervisor is meant to be dis-tributed among the two gates The architecture of Figure 14seems to be very loosely coupled First the PaymentMachineseems to be totally independent In fact the ticket that isinserted in the exit gate must coincide with the one issued bythe PaymentMachine It turns out that this reflects a missingassumption regarding the environment of the system (namelythe user of the parking) Then the two gates seem to have the
RR ndeg 8147
Contracts for System Design 49
0 1ticket_insert_payment 2
coin_insert_paymentticket_insert_payment
3
coin_insert_payment
ticket_insert_paymentcoin_insert_paymentexit_ticket_issue
exit_ticket_issueticket_insert_paymentcoin_insert_payment
Figure 11 Chapter payment of the top-level requirements documenttranslated into a Modal Interface Cpayment
(a0)
vehicle_exit (b0)request_enter
(a1)vehicle_enter
request_entervehicle_exit
ticket_issue
vehicle_enter
vehicle_exit(b1)
request_enter
(a2)
vehicle_enter
vehicle_exitticket_issuerequest_enter
vehicle_enter
vehicle_exit
vehicle_enter
(b2)request_enter
vehicle_exit
vehicle_enter
request_enter
Figure 12 Modal Interface for Rs3
0
entry_gate_close
1
exit_ticket_insert
7
vehicle_entervehicle_exit
44
request_enter
entry_gate_closeexit_ticket_insert
2
exit_gate_open
vehicle_entervehicle_exit
43
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
3
request_enter
vehicle_enter
75
vehicle_exit
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
4
ticket_issue
vehicle_enter
72
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
vehicle_enter
5
vehicle_exit
11
entry_gate_open
exit_gate_openexit_ticket_insertexit_gate_closeentry_gate_closevehicle_enterentry_gate_openvehicle_exitrequest_enter
ticket_issue
vehicle_entervehicle_exit
exit_ticket_insertrequest_enter
6
exit_gate_open
8
exit_gate_close
59
entry_gate_open
vehicle_enter
vehicle_exit exit_ticket_insertrequest_enter
exit_gate_open
exit_gate_close
58
entry_gate_open
vehicle_entervehicle_exit
request_enter
9
exit_ticket_insert
45
entry_gate_open
exit_gate_open
vehicle_entervehicle_exitexit_ticket_insert
request_enter
10
entry_gate_open
vehicle_exit
entry_gate_openexit_ticket_insertrequest_enter
exit_gate_open
entry_gate_close
47
ticket_issue
68
vehicle_enter
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insertrequest_enter
12
ticket_issue
69
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
49
vehicle_enter
13
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
19
request_enter
77
entry_gate_open
50
vehicle_exit
vehicle_enter
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
20
entry_gate_open
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
21
ticket_issue
34
vehicle_enter
71
entry_gate_close
vehicle_exit
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
22
vehicle_enter
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
23request_enter
84
entry_gate_open
127
vehicle_exit
vehicle_enter
exit_ticket_insertrequest_enter
exit_gate_open
24
vehicle_exit
33
entry_gate_open
vehicle_entervehicle_exit
exit_ticket_insertrequest_enter
16
exit_gate_open
17
exit_gate_close
25
entry_gate_open
vehicle_enter
vehicle_exit
exit_gate_openexit_ticket_insertrequest_enter
exit_gate_close
26
entry_gate_open
vehicle_entervehicle_exit
request_enter
18
exit_ticket_insert
114
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
80
entry_gate_open
vehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
81ticket_issue
79
entry_gate_close
99
vehicle_enter
vehicle_exit
exit_gate_open
entry_gate_open
exit_ticket_insertrequest_enter
82vehicle_enter
vehicle_entervehicle_exitexit_gate_open
exit_ticket_insert
31
request_enter
83
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
32
entry_gate_open
vehicle_exitexit_ticket_insertrequest_enter
entry_gate_open
exit_gate_open
vehicle_enter
91
entry_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
vehicle_enter
92
entry_gate_close
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
35
request_enter
101
entry_gate_close
entry_gate_open
60
vehicle_exit
vehicle_enter
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
36
vehicle_exit
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
37
exit_gate_open
125
exit_gate_close
93
entry_gate_close
entry_gate_open
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
exit_gate_open
38
vehicle_exit
exit_gate_close
94
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
39
exit_gate_open
40
exit_gate_close
entry_gate_close
entry_gate_open
vehicle_enter
ticket_issue
vehicle_exitexit_ticket_insertrequest_enter
exit_gate_open
exit_gate_close
entry_gate_open
73entry_gate_close
vehicle_entervehicle_exit
ticket_issue
request_enter
41
exit_ticket_insert
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
ticket_issue
entry_gate_open
exit_ticket_insertrequest_enter
42
exit_gate_open
entry_gate_close
entry_gate_close
ticket_issue
vehicle_enter
entry_gate_open
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
exit_gate_open vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
exit_ticket_insert
entry_gate_close
request_enterentry_gate_open
46
ticket_issue
124
vehicle_enter
vehicle_exit
entry_gate_open
request_enter
exit_ticket_insert
126
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
48
vehicle_enter
vehicle_entervehicle_exit
exit_gate_open
request_enterexit_ticket_insert
113
entry_gate_open
vehicle_exit
request_enter
exit_ticket_insertentry_gate_open
exit_gate_open
105
entry_gate_close
vehicle_enter
request_enter
vehicle_enter
exit_ticket_insert
entry_gate_openexit_gate_open
56
vehicle_exit
74entry_gate_close
vehicle_exit
exit_ticket_insertentry_gate_open
57
exit_gate_open
entry_gate_close
123
exit_gate_close
vehicle_enter
request_enter
vehicle_exit
exit_ticket_insert
entry_gate_openexit_gate_open
request_enter
76
entry_gate_close
exit_gate_close
61
vehicle_enter
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
14
ticket_issue
entry_gate_close
vehicle_enter
vehicle_exit
exit_gate_closeentry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
15
vehicle_enter
vehicle_exit
vehicle_enter
request_enter
exit_gate_openexit_ticket_insert
vehicle_exit
86
entry_gate_open
exit_gate_close
vehicle_entervehicle_exit
request_enter
entry_gate_openexit_ticket_insert
51
exit_gate_open
52
exit_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit
exit_ticket_insertexit_gate_open exit_gate_close
vehicle_entervehicle_exit
request_enter
53
exit_ticket_insert
entry_gate_open
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
54
exit_gate_open
67entry_gate_open
request_enter
vehicle_enter
vehicle_exit
exit_ticket_insertexit_gate_open
55
entry_gate_open
entry_gate_close
request_enter
vehicle_exit
exit_ticket_insert
entry_gate_openexit_gate_open
vehicle_enter
vehicle_enter
entry_gate_open
exit_ticket_insertexit_gate_open
70
request_enter
62
vehicle_exit
entry_gate_close
vehicle_enter
ticket_issue
entry_gate_open
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
entry_gate_close
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_exit
vehicle_entervehicle_exit
ticket_issue
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_close
exit_gate_open
vehicle_enter
ticket_issue
exit_gate_close
vehicle_exit exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
entry_gate_open
exit_ticket_insert
63
exit_gate_open
64exit_gate_close
entry_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit exit_ticket_insertexit_gate_open
exit_gate_close
entry_gate_close
entry_gate_close
vehicle_entervehicle_exit
request_enter
65
exit_ticket_insert
entry_gate_open
entry_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
66exit_gate_open
entry_gate_open
entry_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit
exit_ticket_insertexit_gate_open
entry_gate_close
vehicle_exit
request_enter
exit_gate_open
exit_ticket_insertentry_gate_open
vehicle_enter
vehicle_entervehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insert
78
request_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
vehicle_enter
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
vehicle_exit
exit_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
exit_gate_close
vehicle_enter
request_enter
vehicle_exit
entry_gate_closeexit_gate_openexit_ticket_insert
entry_gate_close
vehicle_exit
request_enter
exit_ticket_insert
entry_gate_open
vehicle_enter
vehicle_entervehicle_exit
exit_ticket_insert
request_enter
104entry_gate_close
112entry_gate_open
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enter
95entry_gate_close
entry_gate_openvehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
exit_ticket_insert
entry_gate_close
request_enterentry_gate_open
115
ticket_issue
98
vehicle_enter
vehicle_exit
exit_ticket_insert
entry_gate_open
request_enter
116
vehicle_enter
vehicle_entervehicle_exit
exit_ticket_insert
30
request_enter
107
entry_gate_open
vehicle_entervehicle_exit
exit_ticket_insert
request_enter97
entry_gate_open
vehicle_exit
exit_ticket_insert
request_enterentry_gate_open
vehicle_enter
96entry_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
89
request_enter
106
entry_gate_closeentry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insert
90
request_enter
100
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
entry_gate_closeexit_ticket_insertrequest_enter
exit_gate_open
vehicle_enter
entry_gate_closeexit_gate_openexit_ticket_insertrequest_enter
vehicle_exit
vehicle_entervehicle_exit
ticket_issue
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_close
exit_gate_open
vehicle_enter
ticket_issue
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
vehicle_enter
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
102
vehicle_exit
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
103
exit_gate_open
exit_gate_close
vehicle_enter
vehicle_exit
request_enterexit_ticket_insert
entry_gate_closeexit_gate_open
exit_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
request_entervehicle_enter
entry_gate_closeexit_ticket_insertentry_gate_open
exit_gate_open
request_enter
vehicle_enter
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insert
85
vehicle_exit
vehicle_exit
entry_gate_close
entry_gate_openexit_ticket_insert
exit_gate_open
request_enter
117
vehicle_enter
exit_gate_close
vehicle_exit
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insert
request_enter
87
vehicle_enter
exit_gate_close
exit_gate_close
entry_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
27
ticket_issue
vehicle_enter
vehicle_exit
exit_gate_close
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
28
vehicle_enter
vehicle_exit
vehicle_enter
exit_gate_close
exit_ticket_insertexit_gate_open
29request_enter
111
entry_gate_open
vehicle_exit
vehicle_enter
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
exit_gate_open
109
entry_gate_open
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
vehicle_enter
108
entry_gate_close
vehicle_exit
vehicle_enter
exit_gate_close
exit_gate_openexit_ticket_insert
88
request_enter
vehicle_exit
110
entry_gate_close
entry_gate_open
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
exit_gate_close
entry_gate_close
vehicle_entervehicle_exit
entry_gate_open
exit_ticket_insert
request_enter
entry_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enterentry_gate_close
vehicle_enter
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
exit_gate_close
entry_gate_close
entry_gate_open
exit_ticket_insert
exit_gate_open
vehicle_enter
request_enter
vehicle_exit
exit_gate_close
entry_gate_close
entry_gate_open
exit_ticket_insertexit_gate_open
vehicle_enter
vehicle_exit
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
exit_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enter
entry_gate_close
vehicle_exit
request_enter
vehicle_enterentry_gate_close
exit_ticket_insert
entry_gate_openexit_gate_open
exit_gate_close
vehicle_exit
request_enter
vehicle_enter
exit_ticket_insert
entry_gate_close
entry_gate_open
vehicle_exit
exit_gate_close
entry_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
128ticket_issue
vehicle_enter
vehicle_exit
exit_gate_close
exit_gate_open
entry_gate_open
exit_ticket_insertrequest_enter
129vehicle_enter
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insert
130
request_enter
122entry_gate_open
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
120
entry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
vehicle_enter
119entry_gate_close
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insert
118
request_enter
121
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_gate_close
entry_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
exit_gate_closeexit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
exit_gate_open
exit_gate_close
request_enter
exit_ticket_insertentry_gate_close
vehicle_exit
exit_gate_open
exit_gate_close
request_enter
vehicle_enter
entry_gate_close
exit_ticket_insertentry_gate_open
vehicle_entervehicle_exit
request_enter
exit_gate_open
entry_gate_open
exit_ticket_insert
exit_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
entry_gate_open
vehicle_exit
exit_ticket_insert
request_enter
vehicle_enter
entry_gate_closeentry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
vehicle_enter
exit_ticket_insertrequest_enter
entry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
entry_gate_close
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_open
Figure 13 Chapter supervisor of the top-level requirements documenttranslated into a Modal Interface Csupervisor for a capacity of two for theparking garage
shared input ldquovehicle exitrdquo as their only interaction But thisshared input is involved in requirement Rs3 which forbidsthe entry if the parking is full
In Figure 15 we show the result of applying to the ar-chitecture of Figure 14 the Algorithm 1 developed in Sec-tion VIII-E which yields by construction a refinement of thetop-level contract C by a decomposition into local contracts
C C(ΣEntryGate)otimes C(ΣExitGate)otimes C(ΣPaymentMachine)
(55)
Local contract C(ΣEntryGate) is the more complex one becauseit involves countingmdashwe have assumed a capacity of two tokeep it simple Remarkably enough the decomposition (55)involves small sub-systems compared to Csupervisor (Fig 13)and the global contract C the restriction operation is to beacknowledged for this strong reduction in size
E The four ldquoCrdquo
Requirements capture and management are important mat-ters for discussion with certification bodies These bodieswould typically assess a number of quality criteria from egthe following list elaborated by INCOSE [114] AccuracyAffordability Boundedness Class Complexity Completeness
request enter
ticket issue
entry gate open
entry gate closeEntryGate
vehicle enter
vehicle exit
exit ticket insert ExitGateexit gate open
exit gate close
ticket insert payment
coin insert paymentPaymentMachine exit ticket issue
Figure 14 System architecture as specified by the designer
0
vehicle_exit
1
request_enter
3
vehicle_enter
request_entervehicle_exit
2ticket_issue
vehicle_enter
request_entervehicle_exit
vehicle_enter
4
entry_gate_open
entry_gate_closeentry_gate_open
ticket_issuevehicle_enterrequest_entervehicle_exit
entry_gate_close
request_entervehicle_exit
5vehicle_enter
vehicle_enter
6
request_enter
15
entry_gate_close
16
vehicle_exit vehicle_enter
request_enter
7
vehicle_exit
8
entry_gate_close
entry_gate_closevehicle_enter
request_entervehicle_exit
vehicle_exit
vehicle_enter
request_enter
9ticket_issue
vehicle_exit
vehicle_enter
request_enter
10
entry_gate_open
vehicle_exit
entry_gate_closerequest_enter
11
vehicle_enter
vehicle_enter
vehicle_exit12
request_enter
14entry_gate_close
vehicle_enter
vehicle_exit
request_enter
13entry_gate_close
vehicle_enter
vehicle_exit request_enter
vehicle_enter
request_enter
vehicle_exit
vehicle_exit
vehicle_enter
request_enter
entry_gate_close
vehicle_enter
request_entervehicle_exit
0 1exit_ticket_insert
4
vehicle_exit
exit_ticket_insert
2
exit_gate_open
vehicle_exit
exit_ticket_insert
3vehicle_exitexit_gate_close
exit_ticket_insertvehicle_exit
exit_ticket_insertexit_gate_close
vehicle_exitexit_gate_open
0 1ticket_insert_payment 2
coin_insert_paymentticket_insert_payment
3
coin_insert_payment
ticket_insert_paymentcoin_insert_paymentexit_ticket_issue
exit_ticket_issueticket_insert_paymentcoin_insert_payment
Figure 15 The three restrictions of the global contract C for the three sub-systems EntryGate (top) ExitGate (mid) and PaymentMachine (bottom)
Conciseness Conformance Consistency Correctness Criti-cality Level Orthogonality Priority Risk Unambiguousnessand Verifiability In this section we focus on four quality crite-ria that are considered central by certification authorities andare relevant to contracts namely Completeness CorrectnessConsistency and Compatibility
1) Consistency amp Compatibility Consistency and compat-ibility have been formally defined in the meta-theory seeSection V and Table IV therein In particular those formaldefinitions can be formally checked Thus the question ariseswhether these formal definitions suitably reflect the commonsense meaning of these terms
According to the common meaning a set of requirementsis consistent if it is not self-contradicting The intent is thatthere is no point in trying to implement an inconsistent set ofrequirements as no such implementation is going to exist
RR ndeg 8147
Contracts for System Design 50
It turns out that the existence of implementations is theformal definition of consistency according to the meta-theoryClearly the formal definition of consistency meets its commonsense interpretation We illustrate consistency on the top-levelspecification of Table IX Referring to this table we havestrengthened Rs6 and Rs7 in some way Lack of consistencyis revealed by checking the mutual consistency of these tworequirements with the requirement Rg3 applied to the exitgate After the following scenario
exit_ticket_insertexit_gate_openexit_ticket_insert
event exit_gate_open has modality must in left-hand interfaceand modality cannot in right-hand interface
According to the common meaning an architecture of sub-systems as characterized by their respective specifications iscompatible if these sub-systems ldquomatch togetherrdquo in that theycan be composed and the resulting system can interact withthe environment as expectedmdashuse cases can be operated aswished As explained in Table IV of Section V this is theformal definition of compatibility in the meta-theory Againthe formal definition of compatibility meets its common senseinterpretation
2) Correctness Correctness can only be defined withreference to another specification We propose to translateldquocorrectnessrdquo by one of the following properties dependingon the case (see Table IV for the notations)bull ldquois a correct implementation ofrdquo written |=Mbull ldquois a correct environment ofrdquo written |=Ebull ldquorefinesrdquo written
3) Completeness Completeness raises a difficulty Al-though the term ldquocompletenessrdquo speaks for itself it cannotbe formally defined what it means to be complete for a top-level specification in the form of a set of requirements Thereason is that we lack a reference against which completenesscould be checked Hence the only way to inspect a top-level specification for completeness is to explore it manuallyThe best help for doing this is to execute the specificationThus specifications must be executable Fortunately ModalInterfaces are executable and this way undesirable behaviorscan be revealed We illustrate this on the top-level specificationof Table IX where Rs6 is changed into ldquoexit gate must openafter an exit ticket is insertedrdquo (by omitting ldquoand only thenrdquo)Lack of completeness is revealed by simulation The followingscenario can occur
exit_ticket_insertexit_gate_openvehicle_exitexit_gate_closeexit_gate_open
which allows vehicles to exit without having inserted an exitticket an unwanted behavior This reveals that the specificationwas not tight enough ie incomplete So far for completenessof the top-level specification
In contrast completeness can be formally defined whena reference C is available We propose to say that Cprime isincomplete with reference to C if
1) Cprime does not refine C but2) there exists Cprimeprime Cprime such that Cprimeprime is consistent and
compatible and refines CThe rationale for this definition is that Cprime is not precise enoughbut can be made so by adding some more requirementsNote that Cprime is incomplete with reference to C if and onlyif Cprime and C is consistent and compatible This criterion is ofparticular relevance when Cprime =
otimesiisinI Ci is an architecture of
sub-contracts where Ci is to be submitted to supplier i forindependent development
F Discussion
Requirements engineering is considered very difficult Re-quirements are typically numerous and very difficult to struc-ture Requirements concern all aspects of the system func-tion performance energy reliabilitysafety Hence systemsengineers generally use several frameworks when expressingrequirements The framework of contracts expressed as ModalInterfaces that we have proposed here improves the situationin a number of aspectsbull It encompasses a large part of the requirements52
bull It can accommodate different concrete formalisms Inour example we have blend textual requirements withrequirements specified as state machines Richer for-malisms such as Stateflow diagrams can be accom-modated in combination with abstract interpretationtechniquesmdashthis is not developed here
bull We have shown how to offer formal support to importantproperties such as the four Crsquos during the process ofcertification
bull We have proposed a correct-by-construction approach tothe difficult step of moving from the top-level specifi-cation in the form of a requirements document to anarchitecture of sub-contracts for the suppliers53
XII CONTRACTS IN THE CONTEXT OF AUTOSAR
In this section we use AUTOSAR as an industrial exampleof how to leverage contracts within an existing standard toextend it
A The AUTOSAR context
AUTOSAR54 is a world-wide development partnership in-cluding almost all players in the automotive domain electronics
52 According to figures that were given to us by industrials 70-80 of therequirements can be expressed using the style we have developed here Otherrequirements typically involve physical characteristics of the system or definethe range for some parameters
53 The framework of AssumeGuarantee contracts that is used in Section XIIdoes not offer this for two reasons First it lacks the quotient and secondlocal alphabets are not properly handled In contrast AssumeGuarantee con-tracts are very permissive in how they can be expressed In particular dataflowdiagrams (Simulink) can be used to express assumptions and guarantees
54httpwwwautosarorg
RR ndeg 8147
Contracts for System Design 51
supply chain It has been created with the purpose of de-veloping an open industry standard for automotive softwarearchitectures To achieve the technical goals of modularityscalability transferability and reusability of functions AU-TOSAR provides a common software infrastructure based onstandardized interfaces for the different layers The AUTOSARproject has focused on the objectives of location indepen-dence standardization of interfaces and portability of codeWhile these goals are undoubtedly of paramount importancetheir achievement may not be sufficient for improving thequality of software systems As for most other embeddedsystem car electronics is characterized by functional as well asnon functional properties assumptions and constraints [111]Therefore an AUTOSAR based development process benefitsfrom adding contracts as the this section will demonstrate
B The contract framework
Extensive use of SimulinkStateflow modeling is performedfor system design in the automobile sector It is thus naturalto try reusing this modeling style for defining contractsSince AG contracts of Section VII simply rely on specify-ing assertions regardless of how they are actually describedwe use AG contracts for this AUTOSAR case study SinceSimulinkStateflow diagrams are very flexible contracts canbe expressed for all viewpoints (function timing safety) Inturn reasoning on such contracts is beyond the capability ofautomatic tools Consequently checking for implementationand refinement relations will be performed manually on smallmodels In contrast the powerful contract algebra developedin the meta-theory is fully generic and does not depend onthe nature and complexity of the considered models Themodularity it offers will thus be the main help offered bycontract based design in this case study As another featureof this this study the distinction between ldquohorizontalrdquo andldquoverticalrdquo contracts is used see Section IV-D4 Finally thefollowing variation of AG contracts is used
Assertions consist of a timed extension of the weaklysynchronous model (18) namely
P sube ((Σ 7rarr D) cup R+)lowast cup ((Σ 7rarr D) cup R+)
ω (56)
meaning that the assertion proceeds by a succession of stepsconsisting of either assignment of values to variables (includ-ing the special status absent for multiple-clocked assertions)or time progress Composition is by intersection P1timesP2 =def
P1 and P2 with alphabet equalization by inverse projection asin see Section VII-C Following Section VII-B componentsare tuples M = (ΣinΣout P ) where Σ = Σin cup Σout is thedecomposition of alphabet Σ into its inputs and outputs andP is an assertion following (56) Components must be free ofexception in the sense of Definition 4
A contract is a tuple C = (ΣinΣoutAs AwG) whereΣ = Σin cup Σout is the decomposition of alphabet Σ intoits inputs and outputs As and Aw the strong and weakassumptions and G the guarantees are assertions over ΣThe set EC of the legal environments for C collects all com-ponents E such that E sube A The set MC of all components
implementing C is defined by (As andAw)timesM sube G meaningthat implementations guarantee G under the condition that theenvironment satisfies the stronger condition AsandAw In otherwords in this framework legal environments are constrainedby strong assumptions only whereas the conjunction of strongand weak assumptions is required to guarantee G Weakassumptions are useful for design iterations in case strictobligations for the context of use may not be realizable
To conclude on this framework its difference is onlymethodological since any contract with strong and weakassumptions C = (ΣinΣoutAs AwG) is equivalent to anordinary AG contract (ΣinΣoutAsG or notAw) Thus thereader is referred to Section VII Adding time to the paradigmdoes not change anything to the relations or operators definedin that section
However adding time results in decidability and complexityissues The latter problem can be fixed in part by usingobservers see Sections V-G and VII Other proofs can be car-ried on manuallymdashthis is feasible for undecidable propertieswhen the needed reasoning only involves a small part of theanalyzed system involving few locally interacting componentsThe added value of our contract framework is to supportthe combination of proofs into a validation for the overallsystem taking into account detailed design decisions capturedin system and ECU configurations
C Exterior Light Management System
To illustrate the benefits of contract-based systems engineer-ing in AUTOSAR we consider as an example an excerpt of anExterior Light Management for an automobile55 We focus onthe parts responsible for sensing driver inputs and actuatingthe rear direction indicator lights and brake lights With thisexample we show how requirements can be refined to contractsand discuss the added value of contracts for negotiationsbetween OEM and suppliers We will also illustrate the useof vertical contracts eg to specify the expected latency ofthe communication solution and computations from the timingviewpoint and a failure hypothesis in terms of reliability
1) Function and timing We begin our study by showinghow AUTOSAR models can be enhanced with contracts
System
ext_pedal
ext_lamp
ext_tssext_wls
ext_rlaext_rra
Figure 16 Virtual Functional Bus model
The Virtual Functional Bus model Figure 16 shows the Vir-tual Functional Bus (VFB) model encompassing the exteriorlights management This software composition specifies the
55A case-study from the German SPES2020 project
RR ndeg 8147
Contracts for System Design 52
interfaces exposed by the component to the sensors deliveringdriver inputs (brake pedal warn light button turn signallever) and to the actuators controlling the lights Ports witharrowheads denote an asynchronous data flow interface whichis a SenderReceiverInterface Here it is a special kind calledServiceInterface which means the data is provided by somelocal service located in the BasicSoftware stack of an ECU(Electronic Computing Unit) The requirements document ofthe system contains one timing-related requirementbull R1 If the driver presses the brake pedal the brake lights
must light not later than 25msWe formalize in Table X this requirement as a contract by
using a pattern-based contract specification language (terms inbold-face are keywords)
CR1
As whenever ext_pedal occursext_pedal does not occur during[ext_pedalext_lamp]ext_pedal occurs sporadicwith minperiod 25ms
Aw trueG delay between ext_pedal and
ext_lamp within [0ms25ms]
Table XHORIZONTAL CONTRACT OF VFB MODEL
Indicator
BrakePedalSensor PedalToLamp
TurnSwitchSensor
WarnLightsSensor
SwitchLightActuator
RearLeftActuator
RearRightActuator
BrakeLampActuator
ext_pedal
pos_pedal_out lamp_intensity ext_lamp
ext_tss
ext_wls
tss
wls
ext_rla
ext_rra
rla_signalrra_signal
emcyBrake
pos_pedal_in
Figure 17 Decomposed Virtual Functional Bus model
Decomposed VFB Software composition Figure 17 showsthe decomposed VFB model AssemblySwConnectors link theports of parts of the composition and are subject to commu-nication refinement The components used in the compositionand their functions are as followsbull BrakePedalSensor receives the position of the brake pedal
(ext_pedal) and distributes it to other components
bull PedalToLamp reads the brake pedal position (pos_pedal)and calculates requested brightness of the brake indicatorlights (lamp_intensity)
bull BrakeLampActuator reads the requested brightness of thebrake indicator lights (lamp_intensity) and actuates thebrake lamps accordingly (ext_lamp)
bull TurnSwitchSensor reads the position of the lever and for-wards it (tss)
bull WarnLightsSensor reads status of the warn blink button andforwards it (wls)
bull Indicator reads the status of the warn blink button the leverposition and cyclically toggles the left and right signals(rla_signal rra_signal)
bull Rear(Left|Right)Actuator reads its input signal ((rla|rra)_signal)and actuates the bulb (ext_(rla|rra))
bull SwitchLightActuator reads left and right signals((rla|rra)_signal) and provides feedback on the dashboard
Horizontal (functional) contracts associated to the VFBmodel For the decomposed VFB model we derive horizontalcontracts specifying the desired IO behavior of the parts Asan example for the component BrakePedalSensor we state thecontracts shown in Table XI Contract CfIOBPS
specifies that
CfIOBPS
Afs whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Afw true
Gf whenever ext_pedal occurspos_pedal_out occurs
CfSIGNALBPS
Afs whenever pos_pedal_out occurs
pos_pedal_out does not occur during[pos_pedal_outpos_pedal_in]
Afw true
Gf whenever pos_pedal_out occurspos_pedal_in occurs
Table XIA SAMPLE OF THE HORIZONTAL CONTRACTS OF THE DECOMPOSED VFB
MODEL SUPERSCRIPT f REFERS TO ldquoFUNCTIONrdquo
provided that the pedal is not ldquomultiply pressedrdquo then thepos_pedal message traverses the BrakePedalSensor and then thewire following it with some unspecified delay In particular nomessage is lost due to a miss by this block Similar contractsare stated for all blocks of the VFB model thus resultingin a set Cf
IO of contracts For all AssemblySwConnectors ofthe composition horizontal contracts are specified that aresimilar to that of CfSIGNALBPS
resulting in a set CfSIGNAL
of contracts This contract scheme guarantees a reliable datatransport by each wire of the VFB model no matter how thecommunication is refined
So far we have stated contracts for each block and eachwire of the VFB model Compose the above contracts usingcontract composition (14) ie compute
CfVFB =otimes(otimes
C | C isin CfIO)
otimes(otimesC | C isin Cf
SIGNAL) (57)
RR ndeg 8147
Contracts for System Design 53
The guarantee offered by overall contract CfVFB is the con-junction of the guarantees of the constitutive contracts Hencecontract CfVFB guarantees that messages reliably traverse theVFB model with however an unspecified delay On the otherhand contract composition (14) assumes the conjunction ofall assumptions stated for each blockmdashthe guarantee offeredby CfVFB and the strong assumption of CR1
discharge all ofthese assumptions
At this point we observe that contract CfVFB involves notiming characteristics and thus functional contract CfVFB doesnot refine the initial contract CR1 To overcome this timingcontracts are added in the next step that will complement thisfunctional contract with timing viewpoint based on expectedperformance characteristics of the computing platform
Budgeting time using contracts We now state additionalcontracts such as the ones shown in Table XII Observethat for those contracts weak assumptions are used see Sec-tion XII-B regarding the motivations for doing this Observealso that we repeated the functional strong assumption56
Again stating similar contracts for each block and wire of the
CtIOBPS
Ats whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Atw ext_pedal occurs sporadic
with minperiod 15msGt delay between ext_pedal and
pos_pedal_out within [0ms15ms]
CtSIGNALBPS
Ats whenever pos_pedal_out occurs
pos_pedal_out does not occur during[pos_pedal_outpos_pedal_in]
Atw pos_pedal_out occurs sporadic
with minperiod 2msGt delay between pos_pedal_out and
pos_pedal_in within [0ms2ms]
Table XIITIMING CONTRACT OF DECOMPOSED VFB MODEL SUPERSCRIPT t
INDICATES THAT THESE CONTRACTS DEAL WITH TIMING
VFB model yields two sets CtIO and Ct
SIGNAL of contractsand we consider
CtVFB =otimes
(otimesC | C isin Ct
IO)otimes(otimesC | C isin Ct
SIGNAL)(58)
The next step is to combine for each component (blockor wire) of the VFB model the two functional and timingviewpoints using conjunction ie to compute
CVFB =otimes(otimes[
Cf and Ct]| (Cf Ct) isin CIO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin CSIGNAL
) (59)
where CIO collects for each block the pair of functional andtiming contracts associated with it and similarly for CSIGNAL
56 If we do not do this then when taking the conjunction of functionaland timing contracts the functional strong assumption gets absorbed by thestrong assumption of the timing contract since the latter is equal to T Seethe discussion regarding AssumeGuarantee contracts with variable alphabetsat the end of Section VII-C
At this point we observe that the architecture of the VFBmodel is a directed acyclic graph
Consider the conjunction C = Cf and Ct = (AG) for eachblock or wire As an example focus on block IOBPS whichis the first block of VFB seen as a directed acyclic graphRegarding the combination of strong and weak assumptionswe have A = Afs and Atw which is weaker than As theassumption of CR1
in Table X Regarding guarantees we haveG = Gf and Gt which ensures that messages traverse thecomponent without duplication or loss and with a delay lessthan the ldquominperiodrdquo of the input signal (15ms) Also guar-antee G offered by this block is strong enough to dischargethe assumption of the next wire when performing contractcomposition Reproducing the same reasoning inductivelyalong all blocks and wires of the VFB model seen as an acyclicgraph shows that
CVFB CR1(60)
Consequently submitting the pairs of contracts (Cf Ct) asso-ciated to each component for separate development possiblyby different suppliers will ensure correct integration (providedimplementations by the suppliers are correct with respect totheir contracts) In particular the component BrakePedalSensorbelongs to the chassis domain and is implemented by adifferent supplier than the other components
Discussion The above step of our contract based designmethodology leads to the following important notices
1) So far our proof steps were all manual Our contractbased reasoning however was instrumental in ensuring thatelementary proof steps were combined correctly Reasoningbased on intuition when component composition and view-point combination both occur is very likely to lead to wrongconclusions There is a strong added value in contract basedreasoning even if elementary proof steps are manual
2) Manual reasoning can be complemented by the use ofobservers Again it is important that the use of observerswhen component composition and viewpoint combination bothoccur is performed correctly Our development in Section V-Gprovides the formal support for this For the pattern basedlanguage used here a framework for checking refinement ofcontracts using an observer based strategy is described in [94]
3) The responsibility of establishing the sub-contracts sub-mitted to the different suppliers is assigned to the OEM inaccordance with his role as integrator Components belongingto different domains of a car (engine chassis etc) are likely tooriginate from different vendorssuppliers By using our abovereasoning the OEM can decompose its contract specificationspassing them to supplier(s) For example the componentBrakePedalSensor is the only one in the VFB model that belongsto the chassis domain and other components are developed byone or more different suppliers Thus in decomposition (59)the two sets of contracts CIO and CSIGNAL are partitioned
RR ndeg 8147
Contracts for System Design 54
eg for subcontracting to two different suppliers
Csupplier1VFB =
otimes(otimes[Cf and Ct
]| (Cf Ct) isin C1
IO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin C1
SIGNAL
)Csupplier2VFB =
otimes(otimes[Cf and Ct
]| (Cf Ct) isin C2
IO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin C2
SIGNAL
)Each supplier can then safely develop its own sub-systemindependently We develop this in the next sub-section
Implementation of software components and vertical as-sumptions Each of the software components being part ofthe software system composition (cf Figure 17) is a Compo-sitionSoftwareComponents as this allows the supplier to reusealready designed components We thus consider one suchcomponent with its contract C = Cf and Ct consisting of thefunctional contract Cf in conjunction with the timing contractCt The supplier can then follow two different approaches fordeveloping this component
In a first approach the supplier reuses a composition
C =otimes
iisinI Ci (61)
of off-the-shelf components available from a library Twosituations can then occurbull The easy case is when refinement holds C C This
means that for C = (As Aw G) guarantees are strongenough and assumptions are weak enough to implyrefinement with respect to the contract C specified bythe OEM
bull A more realistic (but also more delicate) case is when thefollowing weaker relations are satisfied
C Cf (62)G sube G (63)
As and Aw supe Afs andAfw (64)
but the conditions requested on timing assumptions forrefinement C C to hold are not satisfied
As and Aw 6supe Ats andAtw (65)
Under (65) composition from library C cannot be usedas such It can however still be used as a valid imple-mentation provided that some additional missing verticalassumption regarding timing is stated such that
As and Aw supe Ats andAtw and Atw︸ ︷︷ ︸for negotiation
(66)
(66) requires a negotiation in which additional verticalassumption Atw is returned back to the OEM as an ad-ditional performance requirement for the ECU platformIf this is accepted by the OEM then development by thesupplier using off-the-shelf components from the library(61) can proceed
The alternative approach is to implement the componentEventually this results in a composition of AtomicSoftwareCom-ponents This component type has an internal behavior specifi-cation comprising so called Runnables which are the smallest
executable entities known to AUTOSAR For each runnableactivation conditions are defined by means of RTEEvents con-trolled by the RuntimeEnvironment on the corresponding ECUand data accesses referring ports of the owning component AnRTEEvent can be configured to occur either cyclically (time-triggered) or by the data arrival on some input port of theowning component (event-triggered)
Figure 18 depicts the internal behavior of componentBrakePedalSensor This component consists of a single
BrakePedalSensor
BPSRunnable
pos_pedal_out
P=10ms
ext_pedal
Figure 18 Internal behavior of BrakePedalSensor-component
CfIBBPS
Afs whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Afw true
Gf whenever ext_pedal occurspos_pedal_out occurs
CtIBBPS
Ats whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Atw ext_pedal occurs sporadic
with minperiod 10msBPSRunnableact occurs each 10msdelay between BPSRunnableact andpos_pedal_out within [0ms10ms]
Gt delay between ext_pedal andpos_pedal_out within [0ms10ms + 10ms]
CprimetIBBPS
Aprimets whenever ext_pedal occursext_pedal does not occur during[ext_pedalpos_pedal_out]
Aprimetw ext_pedal occurs sporadicwith minperiod 10msBPSRunnableact occurs each 10msdelay between BPSRunnableact andpos_pedal_out within [0ms5ms]
Gprimet delay between ext_pedal andpos_pedal_out within [0ms10ms + 5ms]
Table XIIICONTRACTS FOR INTERNAL BEHAVIOR OF
BRAKEPEDALSENSOR-COMPONENT
runnable BPSRunnable which is activated cyclically with aperiod of 10ms Upon its activation it reads the sensorvalues from the ECU abstraction component and writes the
RR ndeg 8147
Contracts for System Design 55
position of the brake pedal on its provided SenderReceiverport The timing behavior of the component owning a time-triggered runnable can be characterized by the contract shownin Table XIII top
We now focus on the second situation in which the supplierwants to reuse components from a library to implementcontract C = CfIOBPS
and CtIOBPS We consider the case where
a component BrakePedalSensor has already been implementedand characterized by C = CfIBBPS
and CtIBBPSNow observe that
relation (62) holds However G 6sube G Taking a closer lookat Atw we see it assumes a worst case response time forBPSRunnable Thus the guarantee Gt can be strengthened ifweak assumption Atw is replaced by Aprimetw ensuring a shorterresponse time The supplier would then consider the con-tract Cprime = CfIBBPS
and CprimetIBBPS where the re-adjusted contract
CprimetIBBPScorresponds to assuming Aprimetw and guaranteeing Gprimet
For that modified contract relations (62ndash65) hold Howeverstrengthening an assumption is not a refinement Thereforeapplying this modification cannot be performed by the supplieron its own but rather requires negotiation with the OEM Ifthe OEM is willing to accept the stronger assumption Aprimetwthe component from the libary can be used and the modifiedcontract of the supplier is refined Cprime Cprimesupplier1
VFB The next process steps in the AUTOSAR methodology called
System configuration and ECU configuration define the targetarchitecture (ECUs and communication network) as well asthe deployment of the application software components onthat distributed architecture Thus satisfaction of the contractsspecified for the application needs to be verified for the givenarchitecture and deployment (cf IV-D4) We develop this inthe next two sub-sections
ECU configuration and vertical contracts During thefollowing discussion we assume that for each componentimplementation a contract similar to Cprime has been specifiedand possibly an associated Aprimetw has been negotiated Observethat Aprimetw may invalidate refinement of system requirements bythe VFB contract Consider the example above Aprimetw assumesan activation of BPSRunnable each 10ms and a worst caseresponse time less than 5ms This additional weak assumptionis now part of Cprimesupplier1
VFB However it is neither dischargedby any guarantee of CprimeVFB nor by the strong assumption ofCR1 Thus we need to verify that 1 all vertical assumptionscollected during previous steps are discharged during system-and ECU configuration and 2 all guarantees are met bysoftware components and connectors For both tasks state-of-the-art verification techniques can be used
As an example focus on the vertical assumption Aprimetw ofthe BrakePedalSensor-component and consider the ECU con-figuration depicted in Figure 19 The ECU hosts the twocomponents BrakePedalSensor and PedalToLamp of the VFBmodel57 These components are integrated with a layered basicsoftware stack on an ECU That stack consists of multipleBasicSoftwareModules (BSWM) Each of these modules has aset of standardized interfaces and is implemented by a set
57To simplify we omit port emcyBrake
RTE
BrakePedal
SensorPedalToLamp
BSW
COMOSt1 t2
Complex
Device
Driver
ext_pedal
pos_pedal_out
pos_pedal_in
lamp_intensity
isr
Figure 19 Extracting platform contracts from ECU configuration
of BswModuleEntities These are analogous to the Runnables ofapplication software components and are either executed by adedicated OS task or interrupt service routine Therefore weexpect BasicSoftwareModules to be characterized by contractsin a way similar to the internal behavior of applicationcomponents (cf contracts in Table XIII) In case a BSWM hasa BswModuleEntity that is not mapped to some task or interruptservice routine that entity is an ldquoordinaryrdquo function calledwithin the context of another BswModuleEntity or Runnable Inthe example ECU configuration two BSWMs are shown
bull A ComplexDeviceDriver which has direct access to thesensor of the ECU that detects position of the brake pedal
bull An AUTOSAR COM module and a CAN interface (notshown here)
The components and BSWMs own a single runnable eachbsw entity respectively The ECU configuration maps BP-SRunnable to task t1 of the operating system (OS) and PTL-Runnable to task t2 The BswModuleEntity of the ComplexDe-viceDriver is mapped to an interrupt service routine while theentity of the COM module is simply a function for sendinga signal That function is used by the AUTOSAR runtimeenvironment (RTE) to realize the communication specified onVFB-level by means of the connectors For each task of theOS the ECU configuration specifies at least its priority andwether it is preemptable The activation of a task is specifiedby linking an alarm of the OS to that task Those alarmscan also be configured to occur cyclically For each cyclicalarm we generate a contract PALARMi
with trivial strongand weak assumptions and as guarantee the cycle time ofthe alarm The example ECU configuration contains a singlealarm whose contract is listed in Table XIV top Furthermore
PALARM1
As trueAw trueG Alarmi occurs each 10ms
PBPSRunnable
As trueAw trueG delay between BPSRunnableact and
pos_pedal_out within [1ms4ms]
Table XIVPLATFORM CONTRACTS OBAINED BY ANALYSIS OF ECU CONFIGURATION
RR ndeg 8147
Contracts for System Design 56
we can extract from the AUTOSAR model of the componentimplementation a set of execution time specifications for eachRunnable owned by the component Again the same appliesto BswModuleEntities With this information we can create atask network and obtain response times for each Runnableand BswModuleEntity (if executed by some task or interruptservice routine) using tools like SymTAS58 or chronVAL59Afterwards we generate for each Runnable and BswModuleEntity(if executed by task or ISR) a contract PRunnablei
with stongand weak assumption T and as guarantee the reponse timeinterval determined by analysis For the ECU configurationsketched in Figure 19 BPSRunnable has a response time thatlies in the interval [1ms 4ms] resulting in the contract shownin Table XIV bottom Similar contracts are stated for all tasksand alarms extracted from the ECU configurations We thencompose these contracts and the contracts of the BSWMswhich yields the contract P characterizing the executionplatform Following the approach outlined in Section IV-D4we compose the VFB contract with the platform contract andcheck for refinement ie
CprimeVFB otimes P CprimeVFB (67)
The vertical assumption Aprimetw is discharged in the compositionof the VFB and platform contracts and refinement holdsFurthermore with Aprimetw being discharged refinement of thesystem requirement holds again
CprimeVFB otimes P CR1(68)
The approach outlined here to analyze the mapping of applica-tion software components and their associated contracts on anECU network by creating contracts from ECU configurationsand results of response time analysis has been implemented ina framework That framework includes a meta-model support-ing contract-based design and enables to 1 specify contractsfor components in foreign models and 2 check for refinementbetween contracts belonging to different models [24]
Inter-ECU communication During system configurationthe leaves of the hierarchical software composition calledAtomicSoftwareComponents are mapped to ECUs of the targetarchitecture Thus we know for each connector of the VFBmodel whether it must be implemented by the communicationnetwork interconnecting the ECUs
For both intra- and inter-ECU communication the designmust be verified against the corresponding contracts of theVFB model ie the set of contracts[
Cf and Ct] ∣∣ (Cf Ct) isin CSIGNAL
(69)
Again available analysis techniques can be used Suppose asignal from the VFB model is mapped to a frame transmittedon a CAN bus The OEM can then for each such contractuse the combination of strong and weak assumptions A =Afs and Atw as specification of the minimal inter-arrival timesof subsequent occurrences of the signal Taking into account
58httpwwwsymtavisioncomsymtashtml59httpwwwinchroncomchronvalhtml
the priority of each CAN frame given by its identifier theresponse time of each signal can be computed and comparedagainst the guarantee G = Gf andGt
If the communication network whose configuration is partof the AUTOSAR system configuration is successfully verifiedagainst the contracts defined in (69) deployment of the VFBmodel on the target architecture is correct with regard tothe VFB contract and the design fulfills the initial systemrequirement CR1
Discussion The above development highlights themethodological value of contracts for system design in AU-TOSAR context at later design stages First both contractconjunction and composition are used Then modificationsthat are not refinements are pinpointed which forces thesupplier to engage on a negotiation with the OEM regardingsystem specifications Without the solid support of contractsand its rules such kind of reasoning would be error prone
2) Safety The virtual function bus (VFB) concept wasintended to enable a distributed development of software com-ponents independently from the underlying hardware architec-ture The specification of the interfaces in the 3x releases didnot support the kind of non functional property necessary todevelop safety aspects of critical systems This fact lead to thedevelopment of the previously mentioned Timing Extensionand Safety Extension to Methodology and Templates Thesafety extension directly addresses the use of contracts forthe specification of safety relevant properties driven by theneed for compliance to the upcoming ISO26262 standardThe ISO26262 not only requires comprehensive checking ofrequirements but also states explicitly the need for usingassumptions on the environment to develop a safety relevantelement on the supplier side (ldquosafety element out of contextrdquo)In particular the standard distinguishes betweenbull A functional safety concept comprising the functional
safety requirements their allocation to architectural el-ements and their interaction necessary to achieve thesafety goals This is used to demonstrate that the risksrelated to an item of a vehicle are addressed by anadequate functional architecture
bull A technical safety concept used to demonstrate that thefunctional safety concept is addressed by an adequatetechnical solution
As a simple example for this approach we take the functionalarchitecture of Figure 20 showing the decomposition of theSafeBrakeIndication function into the ldquonormalrdquo BrakeIndicationfunction and the SignalingFailureDetection safety function in casethe BrakeIndication fails The corresponding safety goal requiresthat a loss of the braking indication function shall be detectedThis is formalized as contract CS0 shown in Table XV Thiscontract states that under a given failure hypothesis (ldquonodouble failurerdquo) either the brake lamp is activated or the driveris warned by the SignalingFailureDetection function This contractis attached to the function SafeBrakeIndication
For the subfunction BrakeIndication we show in Table XVIa contract CS1 stating the correct behavior in the absence
RR ndeg 8147
Contracts for System Design 57
CS0
As trueAw Only one of Fail(BrakeIndication)
and Fail(SignalFailureDetection) occursG Whenever BreakRequest occurs then
BreakIndication or SignalFailureDetection is performed
Table XVHORIZONTAL CONTRACT REPRESENTING FUNCTIONAL SAFETY
REQUIREMENT
ltltFunctiongtgt SafeBrakeIndication
ltltFunctiongtgt BrakeIndication
ltltSafetyFunctiongtgt SignalingFailureDetection
ltltFunctionalExchangegtgt BrakeRequest
ltltFunctionalExchangegtgt Detect(BrakeIndicationFail)
Figure 20 Functional architecture including safety function
of a failure of this function For the SignalingFailureDetection
CS1
As trueAw Absence of Fail(BrakeIndication)G Whenever BrakeRequest occurs then
BrakeIndication is performed
Table XVIHORIZONTAL CONTRACT FOR FUNCTION OF BRAKING LAMP
the associated contract states that a detected failure of thesub-function BrakeIndication is correctly indicated under theassumption that the provided function itself is not impacted bya failure see Table XVII An easy manual inspection shows
CS2
As trueAw Absence of fail(SignalingFailureDetection)G Whenever detect(fail(BrakeIndication))
SignalingFailureDetection is performed
Table XVIIHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
that the composition of CS1 otimes CS2 refines CS0 ie we haveformally validated the functional safety concept
The next step consists in allocating these functions tosoftware components on the VFB and developing a simpletechnical safety concept The corresponding technical architec-ture is shown in Figure 21 For the sake of simplicity we onlyconsider corrupted data while transmitting under failure modeThe affected communication links are marked in blue in Fig-ure 21 Thus fail(BrakeIndication) is mapped to fail(pos_pedal) andfail(lamp_intensity) In the same way fail(SignalingFailureDetection)is mapped to fail(mal_indication) This mapping is not furtherelaborated in this paper
For defining the technical safety concept so-called prop-agation contracts are used Propagation contracts expresshow failures (from the environment of the component) are
BrakePedal Sensor
PedalTo Lamp
BrakeLamp Actuator
MalfunctionIndication
lamp_intensity pos_pedal
ext_pedal mal_indication
ext_lamp
ext_indication
Figure 21 Extract of Indicator System
processed by the component According to the ISO 26262 (seeFigure 22) Faults Errors and Failures are distinguished by thepatterns used for the contracts
Figure 22 The role of Faults Errors and failures
For instance the contract CS4 of Table XVIII states that theerror state of the PedalToLamp component is caused by a failurein the communication
CS4
As trueAw trueG Mode PedalToLampError is caused by
fail(pos_pedal)
Table XVIIIHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
The nominal behavior is again given by the contract with anassumption about the absence of the communication failuresee Table XIX
Similarly the error state of the BreakLampActuator iscaused by a failure on the second communication link(fail(lamp_intensity)) or by a failure propagated from the PedalTo-Lamp component see Table XX The nominal behavior of the
RR ndeg 8147
Contracts for System Design 58
CS5
As trueAw Absence of fail(pos_pedal)G Whenever pos_pedal occurs then
lamp_intensity occurs
Table XIXEXEMPLARY CONTRACT FOR NOMINAL BEHAVIOR SPECIFICATION
BrakePedalSensor and the MalfunctionIndicator is formed similarlyto CS5
CS6
As trueAw trueG Mode BreakLampActuatorError is caused by
fail(lamp_intensity) or mode PedalToLampError
Table XXHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
The composition of contracts CS4 CS7
together with thenot stated simple nominal contracts entails the contract CS8
shown on Table XXI stating the functional safety requirement
CS8
As trueAw only one of faila failb failcG Whenever ext_pedal occurs then
ext_lamp or ext_indication occurs
Table XXICONTRACT STATING THE TECHNICAL SAFETY REQUIREMENT
Contract CS8is directly related to the functional safety goal
and includes the allocation to a technical safety concept Thisway a consistency between the functional and the technicalsafety concept has been established Furthermore thanks tothe formal pattern-based specification language the refinementrelations ensure that the concepts themselves are correct
To conclude let us mention other safety related use-caseswhich benefit from contract based specification such as theautomatic generation of fault-trees or FMEA tables as well asthe safe-state management
D Integrating Contracts in AUTOSAR
An important challenge is to smoothly integrate the use ofcontracts as part of AUTOSAR methodology We advocate amigration in two steps
TodaymdashOffering a Smooth Integration of Contract-BasedSystem Engineering with AUTOSAR The metamodel under-lying the CESAR reference technology platform has beencarefully designed to support a seamless design flow fromthe derivation of high-level requirements of new automotivefunctions to the level of detailed application design defined asthe entry point in the AUTOSAR design methodology The keyfor this smooth integration has been laid by AUTOSAR itselfby enforcing a clean separation between application develop-ment on the one side and deployment to distributed target
architectures on the other side Regarding layered design thejoint scope of CESAR and AUTOSAR ranges from systems-of-systems levels for Car2X applications to the introductionof new automotive functions and down to the detailed designlevel As illustrated in the previous section such phases wouldbuild on established design processes and currently used de-sign tools where contracts and viewpoints are conservativelyadded as additional flavor to existing design methodologiesFull hand-over to AUTOSAR takes place at the detailed designstage where component contracts get implemented using theAUTOSAR component model thus providing the entry pointfor the AUTOSAR design methodology
Following the AUTOSAR flow system configurations andECU configurations describe the detailed target hardware Wecan then automatically extract from system and ECU con-figurations all information for performing real-time analysisVertical assumptions on the component level can be derivedby back-annotation from the underlying target hardware Alter-natively vertical assumptions can be seen as constraining thetarget architecture (regarding its timing characteristics) and canthus be used to constrain the design space for possible targetarchitectures Finally when deploying components to ECUscommunications of the virtual functional bus are mapped to theinter-component communications on the physical architecture
The FuturemdashIntegrating Contracts in AUTOSAR The cur-rent AUTOSAR release is expressive enough to represent real-time contracts Using the concept of timing chains both end-to-end deadlines as well as assumed response times for compo-nent execution and communication can be expressed Howeverthe current release was not designed for extensibility thereis no established notion of viewpoints and hence no anchorto easily migrate from the current setting to one supportingmultiple viewpoints As pointed out before the decision asto which viewpoints should or should not be anchored is abusiness decision However given that ISO 26262 has becomebinding we see the need for a systematic integration of thesafety viewpoint
In fact a safety extension has already been proposed forinclusion in AUTOSAR It allows to use contracts for theencapsulation of Basic SoftWare (BSW) modules applicationsoftware components entities of the hardware architecture(like ECUs and buses) and the characterization of commu-nication services Such encapsulation would for instancedistinguish between BSW modules that (1) contribute to safety(safety mechanisms) and (2) those that could potentiallyimpact systemrsquos safety (by providing their failure propagationbehavior) A typical example for (1) would be the func-tion inhibition manager that maintains function inhibitionswhenever for instance implausible outputs are generated Atypical example for (2) would be an error that occurs inthe communication services or an error that is generated incommunication HW that impacts communication services
The objective of the extension is to provide an ISO 26262compliant traceability This allows for instance to deal withcompliance between functional safety (where functions haz-ards and safety functions are collected in the functional
RR ndeg 8147
Contracts for System Design 59
model) and technical safety of the AUTOSAR architectureinstance (guaranteeing that the AUTOSAR implementationmdashusing given safety functions of the AUTOSAR architecturemdashindeed implements the identified functional safety concept)
Since timing and safety viewpoints will be supported inAUTOSAR it is at least worthwhile to consider introducingthe concepts of viewpoints systematically Doing so will easetheir activation at times when other market factors such aspower-management mandate their introduction
E Summary and discussion
We have proposed a smooth path for integrating contractsin the context of AUTOSAR at the level of detailed designWe believe that the main aspects for consideration whileintroducing contracts are the handling of time budgets andthe specification of failure modes and failure propagation incombination with the functional aspect itself Vertical contractswere instrumental in handling time budgets Such contractsrelate two different layers of the AUTOSAR framework
XIII CONCLUSION
This paper presented past and recent results as well asnovel advances in the area of contracts and their theory Byencompassing (functional and non-functional) behaviors thenotion of contract we considered here represents a significantstep beyond the one originally developed in the softwareengineering community
A What contracts can do for the designer
This paper demonstrates that contracts offer a number ofadvantages
Contracts offer a technical support to legal customer-supplier documents Concurrent developmentmdashboth withinand across companiesmdashcalls for smooth coordination andintegration of the different design activities Properly definingand specifying the different concurrent design tasks is andremains a central difficulty Obligations must therefore beagreed upon together with suspensive conditions seen aslegal documents By clearly establishing responsibilities ourformalization of contracts constitutes the technical counterpartof such legal documents Contracts are an enabling technologyfor concurrent development
Contracts offer support to certification By providing for-mal arguments that can assess and guarantee the qualityof a design throughout all design phases (including earlyrequirements capture) contracts offer support for certificationBy providing sophisticated tools in support of modularityreuse in certification is made easier
Contracts comply with formal and semi-formal approachesThe need for being ldquocompletely formalrdquo has hampered for along time formal verification in many industrial sectors inwhich flexibility and intuitive expression in documentationsimulation and testing were and remain preferred As theAUTOSAR use case of Section XII demonstrated using con-tracts makes semi-formal design safer Small analysis stepsare within the reach of human reasoning A valid system
wide analysis for both component-based and refinement-baseddesigns is typically beyond the reach of human reasoningContract based design enables it
Contracts improve requirement engineering As illustratedin the Parking Garage example of Section XI contracts areinstrumental in decoupling top-level system architecture fromthe architecture used for sub-contracting to suppliers Formalsupport is critical in choosing alternative solutions and migrat-ing between different architectures with relatively small effortOf course contracts are not the only important technologyfor requirements engineeringmdashtraceability is essential anddeveloping domain specific ontologies is also important
Contracts can be used in any design process Contractsoffer a orthogonal support for all methodologies and can beused in any flow as a supporting technology in composing andrefining designs
B Status of research
The area of contracts benefits from many advances inresearch that were not targeted to it Interface theories weredeveloped by the community of game theorymdashcomponent andenvironment are seen as two players in a game Modalitiesaimed to offer more expressive logics were born at theboundary between logics and formal verification Contractsas a philosophy originated both from software engineeringand formal verification communities with the paradigms ofPre-conditionPost-condition or AssumeGuarantee It is notuntil the 2000rsquos that the concept of contracts presented hereas a tool to support system design emerged In this evolutionvarious formalisms and theories were borrowed to developa rigorous framework This paper was intended to show thepower of a unified theoretical background for contracts the useof contracts in present methodologies and the challenges for itseffective applications in future applications The mathematicalelegance of the concepts underpinning this area providesconfidence in a sustained continuation of the research effort
C Status of practice
The use of contract-based techniques in system design isin its infancy in industry Further maturation is needed forits paradigm and concepts to become on one side clearand simple to be widely accepted by engineers in their day-to-day work and on the other side developed enough toallow for the development of tools for automatic verificationand synthesis While powerful contract-based proof-of-concepttools are being experimentedmdashsome of them were presentedin this papermdashthe robustness of the tools and the underlyingtechniques is still weak and contract-based design flows andmethodologies are not yet fully developed nor mature
D The way forward
The ability of contracts to accommodate semi-formal andformal methodologies should enable a smooth and rapid mi-gration from theory and proof-of-concepts to robust flows andmethodologies The need for jointly developing new systemswhile considering issues of intellectual property will make
RR ndeg 8147
Contracts for System Design 60
it attractive to rely on contracts in supplier chains In ouropinion contracts are primarily helpful for early stages ofsystem design and particularly requirement engineering whereformal methods are desperately needed to support distributedand concurrent development by independent actors
We have illustrated in this paper how suppliers can be givensub-contracts that are correct by construction and can be auto-matically generated from top-level specification We believehowever that the semi-assistedsemi-manual use of contractssuch as exemplified by our AUTOSAR case study is alreadya significant help useful for requirements engineering tooAltogether a contract engine (such as the MICA tool presentedin Section XI) can be used in combination with both manualreasoning and dedicated formal verification engines (eg fortargeting the timing viewpoint or the safety viewpoint) as thebasis for future development that will make contracts mainstream
REFERENCES
[1] Martiacuten Abadi and Leslie Lamport Conjoining specifications ACMTrans Program Lang Syst 17(3)507ndash534 1995
[2] Yael Abarbanel Ilan Beer Leonid Gluhovsky Sharon Keidar andYaron Wolfsthal FoCs - Automatic Generation of Simulation Checkersfrom Formal Specifications In E Emerson and A Sistla editors Com-puter Aided Verification volume 1855 of Lecture Notes in ComputerScience pages 538ndash542 Springer Berlin Heidelberg 2000
[3] B Thomas Adler Luca de Alfaro Leandro Dias da Silva MarcoFaella Axel Legay Vishwanath Raman and Pritam Roy Ticc A Toolfor Interface Compatibility and Composition In Proc of the 18thInternational Conference on Computer Aided Verification (CAVrsquo06)volume 4144 of Lecture Notes in Computer Science pages 59ndash62Springer 2006
[4] Albert Benveniste and Benoicirct Caillaud and Jean-Baptiste RacletApplication of Interface Theories to the Separate Compilation ofSynchronous Programs In IEEE Conf on Decision and Control dec2012
[5] Luca De Alfaro and Thomas A Henzinger Interface-based design InIn Engineering Theories of Software Intensive Systems proceedings ofthe Marktoberdorf Summer School Kluwer 2004
[6] Rajeev Alur and David L Dill A theory of timed automata TheoreticalComputer Science 126(2)183ndash235 1994
[7] Rajeev Alur Limor Fix and Thomas A Henzinger A determinizableclass of timed automata In David L Dill editor CAV volume 818 ofLecture Notes in Computer Science pages 1ndash13 Springer 1994
[8] Rajeev Alur Limor Fix and Thomas A Henzinger Event-clockautomata A determinizable class of timed automata Theor ComputSci 211(1-2)253ndash273 1999
[9] Rajeev Alur Thomas A Henzinger and Orna Kupferman Alternating-time temporal logic J ACM 49(5)672ndash713 2002
[10] Rajeev Alur Thomas A Henzinger Orna Kupferman and Moshe YVardi Alternating refinement relations In Proc of the 9th InternationalConference on Concurrency Theory (CONCURrsquo98) volume 1466 ofLecture Notes in Computer Science pages 163ndash178 Springer 1998
[11] Adam Antonik Michael Huth Kim G Larsen Ulrik Nyman andAndrzej Wasowski 20 Years of Modal and Mixed SpecificationsBulletin of European Association of Theoretical Computer Science1(94) 2008
[12] Adam Antonik Michael Huth Kim Guldstrand Larsen Ulrik Nymanand Andrzej Wasowski Complexity of Decision Problems for Mixedand Modal Specifications In FoSSaCS pages 112ndash126 2008
[13] Road vehicles ndash functional safety Standard ISO 26262[14] Christel Baier and Joost-Pieter Katoen Principles of Model Checking
MIT Press Cambridge 2008[15] Felice Balarin Jerry R Burch Luciano Lavagno Yosinori Watanabe
Roberto Passerone and Alberto L Sangiovanni-Vincentelli Con-straints specification at higher levels of abstraction In Proceedingsof the Sixth IEEE International High-Level Design Validation and Test
Workshop (HLDVT01) pages 129ndash133 Monterey CA November 7ndash92001 IEEE Computer Society Los Alamitos CA USA
[16] Felice Balarin Abhijit Davare Massimiliano DrsquoAngelo Douglas Dens-more Trevor Meyerowitz Roberto Passerone Alessandro Pinto Al-berto Sangiovanni-Vincentelli Alena Simalatsar Yoshinori WatanabeGuang Yang and Qi Zhu Platform-based design and frameworksMETROPOLIS and METRO II In Gabriela Nicolescu and Pieter JMosterman editors Model-Based Design for Embedded Systems chap-ter 10 page 259 CRC Press Taylor and Francis Group Boca RatonLondon New York November 2009
[17] Felice Balarin and Roberto Passerone Functional verification method-ology based on formal interface specification and transactor generationIn Proceedings of the Conference on Design Automation and Test inEurope (DATE06) pages 1013ndash1018 Munich Germany March 6ndash102006 European Design and Automation Association 3001 LeuvenBelgium
[18] Felice Balarin and Roberto Passerone Specification synthesis andsimulation of transactor processes IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 26(10)1749ndash1762October 2007
[19] Felice Balarin Roberto Passerone Alessandro Pinto and Alberto LSangiovanni-Vincentelli A formal approach to system level designMetamodels and unified design environments In Proceedings of theThird ACM and IEEE International Conference on Formal Methodsand Models for Co-Design (MEMOCODE05) pages 155ndash163 VeronaItaly July 11ndash14 2005 IEEE Computer Society Los Alamitos CAUSA
[20] Felice Balarin Yosinori Watanabe Harry Hsieh Luciano LavagnoClaudio Passerone and Alberto L Sangiovanni-Vincentelli Metropo-lis An Integrated Electronic System Design Environment IEEEComputer 36(4)45ndash52 2003
[21] Krishnakumar Balasubramanian Aniruddha Gokhale Gabor KarsaiJanos Sztipanovits and Sandeep Neema Developing applicationsusing model-driven design environments IEEE Computer 39(2)33ndash40 2006
[22] Sebastian S Bauer Alexandre David Rolf Hennicker Kim GuldstrandLarsen Axel Legay Ulrik Nyman and Andrzej Wasowski Movingfrom specifications to contracts in component-based design In Juande Lara and Andrea Zisman editors FASE volume 7212 of LectureNotes in Computer Science pages 43ndash58 Springer 2012
[23] Sebastian S Bauer Philip Mayer Andreas Schroeder and Rolf Hen-nicker On Weak Modal Compatibility Refinement and the MIOWorkbench In Proc of 16th International Conference on Tools andAlgorithms for the Construction and Analysis of Systems (TACASrsquo10)volume 6015 of Lecture Notes in Computer Science pages 175ndash189Springer 2010
[24] Andreas Baumgart Eckard Boumlde Matthias Buumlker Werner Damm Guumln-ter Ehmen Tayfun Gezgin Stefan Henkler Hardi Hungar BernhardJosko Markus Oertel Thomas Peikenkamp Philipp Reinkemeier IngoStierand and Raphael Weber Architecture Modeling Technical reportOFFIS March 2011
[25] Nikola Benes Jan Kretiacutenskyacute Kim Guldstrand Larsen and Jiriacute SrbaChecking Thorough Refinement on Modal Transition Systems IsEXPTIME-Complete In Martin Leucker and Carroll Morgan editorsICTAC volume 5684 of Lecture Notes in Computer Science pages112ndash126 Springer 2009
[26] Nikola Benes Jan Kretiacutenskyacute Kim Guldstrand Larsen and Jiriacute SrbaOn determinism in modal transition systems Theoretical ComputerScience 410(41)4026ndash4043 2009
[27] Benoicirct Caillaud and Jean-Baptiste Raclet Ensuring Reachability byDesign In Int Colloquium on Theoretical Aspects of Computing sept2012
[28] Albert Benveniste and Geacuterard Berry The synchronous approach toreactive and real-time systems Proceedings of the IEEE 79(9)1270ndash1282 1991
[29] Albert Benveniste Benoicirct Caillaud Alberto Ferrari LeonardoMangeruca Roberto Passerone and Christos Sofronis Multiple view-point contract-based specification and design In Proceedings of theSoftware Technology Concertation on Formal Methods for Componentsand Objects FMCOrsquo07 volume 5382 of Lecture Notes in ComputerScience pages 200ndash225 Springer October 2008
[30] Albert Benveniste Paul Caspi Stephen A Edwards Nicolas Halb-wachs Paul Le Guernic and Robert de Simone The SynchronousLanguages 12 years later Proceedings of the IEEE 91(1)64ndash83 2003
RR ndeg 8147
Contracts for System Design 61
[31] Luca Benvenuti Alberto Ferrari Leonardo Mangeruca EmanueleMazzi Roberto Passerone and Christos Sofronis A contract-basedformalism for the specification of heterogeneous systems In Proceed-ings of the Forum on Specification Verification and Design Languages(FDL08) pages 142ndash147 Stuttgart Germany September 23ndash25 2008
[32] Gerard Berry The effectiveness of synchronous languages for thedevelopment of safety-critical systems White paper Esterel Technolo-gies 2003
[33] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet A compositional approach on modal specifications for timedsystems In Proc of the 11th International Conference on FormalEngineering Methods (ICFEMrsquo09) volume 5885 of Lecture Notes inComputer Science pages 679ndash697 Springer 2009
[34] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet Modal event-clock specifications for timed component-baseddesign Science of Computer Programming 2011 To appear
[35] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet Modal event-clock specifications for timed component-baseddesign Science of Computer Programming 2012 to appear
[36] Nathalie Bertrand Sophie Pinchinat and Jean-Baptiste Raclet Refine-ment and consistency of timed modal specifications In Proc of the3rd International Conference on Language and Automata Theory andApplications (LATArsquo09) volume 5457 of Lecture Notes in ComputerScience pages 152ndash163 Springer 2009
[37] Antoine Beugnard Jean-Marc Jeacutezeacutequel and Noeumll Plouzeau Makingcomponents contract aware IEEE Computer 32(7)38ndash45 1999
[38] Dirk Beyer Arindam Chakrabarti and Thomas A Henzinger Webservice interfaces In Allan Ellis and Tatsuya Hagino editors WWWpages 148ndash159 ACM 2005
[39] Purandar Bhaduri and S Ramesh Interface synthesis and protocolconversion Formal Aspects of Computing 20(2)205ndash224 2008
[40] Purandar Bhaduri and Ingo Stierand A proposal for real-time interfacesin speeds In Design Automation and Test in Europe (DATErsquo10) pages441ndash446 IEEE 2010
[41] Simon Bliudze and Joseph Sifakis The Algebra of Connectors -Structuring Interaction in BIP IEEE Trans Computers 57(10)1315ndash1330 2008
[42] R Bloem and B Jobstmann Manual for property-based synthesis toolTechnical Report Prosyd D223 2006
[43] Roderick Bloem Alessandro Cimatti Karin Greimel Georg HofferekRobert Koumlnighofer Marco Roveri Viktor Schuppan and RichardSeeber RATSY - A New Requirements Analysis Tool with SynthesisIn Tayssir Touili Byron Cook and Paul Jackson editors CAV volume6174 of Lecture Notes in Computer Science pages 425ndash429 Springer2010
[44] Grady Booch James Rumbaugh and Ivar Jacobson Unified ModelingLanguage User Guide The (2nd Edition) (Addison-Wesley ObjectTechnology Series) Addison-Wesley Professional 2005
[45] Amar Bouali XEVE an Esterel Verification Environment In Alan JHu and Moshe Y Vardi editors CAV volume 1427 of Lecture Notesin Computer Science pages 500ndash504 Springer 1998
[46] Geacuterard Boudol and Kim Guldstrand Larsen Graphical versus logicalspecifications Theor Comput Sci 106(1)3ndash20 1992
[47] Jerry R Burch Trace Algebra for Automatic Verification of Real-Time Concurrent Systems PhD thesis School of Computer ScienceCarnegie Mellon University August 1992
[48] Jerry R Burch Roberto Passerone and Alberto L Sangiovanni-Vincentelli Overcoming heterophobia Modeling concurrency in het-erogeneous systems In Proceedings of the 2nd International Confer-ence on Application of Concurrency to System Design (ACSD01) pages13ndash32 Newcastle upon Tyne UK June 25ndash29 2001 IEEE ComputerSociety Los Alamitos CA USA
[49] Benoicirct Caillaud Mica A Modal Interface Compositional AnalysisLibrary October 2011 httpwwwirisafrs4toolsmica
[50] Benoicirct Caillaud Benoicirct Delahaye Kim G Larsen Axel LegayMikkel Larsen Pedersen and Andrzej Wasowski Compositional designmethodology with constraint Markov chains In Proceedings of the7th International Conference on Quantitative Evaluation of SysTems(QEST) 2010 IEEE Computer Society 2010
[51] Daniela Cancila Roberto Passerone Tullio Vardanega and MarcoPanunzio Toward correctness in the specification and handling ofnon-functional attributes of high-integrity real-time embedded systemsIEEE Transactions on Industrial Informatics 6(2)181ndash194 May 2010
[52] Karlis Cerans Jens Chr Godskesen and Kim Guldstrand LarsenTimed Modal Specification - Theory and Tools In Costas Courcou-betis editor CAV volume 697 of Lecture Notes in Computer Sciencepages 253ndash267 Springer 1993
[53] Pavol Cernyacute Martin Chmelik Thomas A Henzinger and ArjunRadhakrishna Interface simulation distances In Marco Faella andAniello Murano editors GandALF volume 96 of EPTCS pages 29ndash42 2012
[54] Arindam Chakrabarti A Framework for Compositional Design andAnalysis of Systems PhD thesis EECS Department University ofCalifornia Berkeley Dec 2007
[55] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger MarcinJurdzinski and Freddy Y C Mang Interface compatibility checkingfor software modules In Ed Brinksma and Kim Guldstrand Larseneditors CAV volume 2404 of Lecture Notes in Computer Sciencepages 428ndash441 Springer 2002
[56] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger andFreddy Y C Mang Synchronous and Bidirectional Component Inter-faces In Proc of the 14th International Conference on Computer AidedVerification (CAVrsquo02) volume 2404 of Lecture Notes in ComputerScience pages 414ndash427 Springer 2002
[57] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger andMarieumllle Stoelinga Resource Interfaces In Rajeev Alur and InsupLee editors EMSOFT volume 2855 of Lecture Notes in ComputerScience pages 117ndash133 Springer 2003
[58] Edward Y Chang Zohar Manna and Amir Pnueli Characterizationof temporal property classes In Werner Kuich editor ICALP volume623 of Lecture Notes in Computer Science pages 474ndash486 Springer1992
[59] Taolue Chen Chris Chilton Bengt Jonsson and Marta ZKwiatkowska A compositional specification theory for componentbehaviours In Helmut Seidl editor ESOP volume 7211 of LectureNotes in Computer Science pages 148ndash168 Springer 2012
[60] Chris Chilton Marta Z Kwiatkowska and Xu Wang Revisiting timedspecification theories A linear-time perspective In Marcin Jurdzinskiand Dejan Nickovic editors FORMATS volume 7595 of Lecture Notesin Computer Science pages 75ndash90 Springer 2012
[61] E Clarke O Grumberg and D Peled Model Checking MIT Press1999
[62] Edmund M Clarke David E Long and Kenneth L McMillanCompositional model checking In LICS pages 353ndash362 1989
[63] W Damm E Thaden I Stierand T Peikenkamp and H HungarUsing Contract-Based Component Specifications for Virtual Integra-tion and Architecture Design In Proceedings of the 2011 DesignAutomation and Test in Europe (DATErsquo11) March 2011 To appear
[64] Werner Damm and David Harel LSCs Breathing life into messagesequence charts Formal Methods in System Design 19(1)45ndash80 2001
[65] Werner Damm Angelika Votintseva Alexander Metzner BernhardJosko Thomas Peikenkamp and Eckard Boumlde Boosting reuse ofembedded automotive applications through rich components In Pro-ceedings of FIT 2005 - Foundations of Interface Technologies 2005
[66] Werner Damm and Bernd Westphal Live and let die LSC basedverification of UML models Sci Comput Program 55(1-3)117ndash1592005
[67] Abhijit Davare Douglas Densmore Trevor Meyerowitz AlessandroPinto Alberto Sangiovanni-Vincentelli Guang Yang and Qi Zhu Anext-generation design framework for platform-based design In DesignVerification Conference (DVCon) San Josersquo California 2007
[68] Alexandre David Kim G Larsen Axel Legay Ulrik Nyman andAndrzej Wasowski Timed IO automata A complete specificationtheory for real-time systems In Proc of the 13th ACM InternationalConference on Hybrid Systems Computation and Control (HSCCrsquo10)pages 91ndash100 ACM 2010
[69] Alexandre David Kim Guldstrand Larsen Axel Legay Ulrik Nymanand Andrzej Wasowski ECDAR An Environment for CompositionalDesign and Analysis of Real Time Systems In Proc of the 8thInternational Symposium on Automated Technology for Verificationand Analysis (ATVArsquo10) volume 6252 of Lecture Notes in ComputerScience pages 365ndash370 2010
[70] Luca de Alfaro Game Models for Open Systems In VerificationTheory and Practice volume 2772 of Lecture Notes in ComputerScience pages 269ndash289 Springer 2003
[71] Luca de Alfaro Leandro Dias da Silva Marco Faella Axel LegayPritam Roy and Maria Sorea Sociable Interfaces In Proc of
RR ndeg 8147
Contracts for System Design 62
the 5th International Workshop on Frontiers of Combining Systems(FroCosrsquo05) volume 3717 of Lecture Notes in Computer Sciencepages 81ndash105 Springer 2005
[72] Luca de Alfaro and Thomas A Henzinger Interface automata In Procof the 9th ACM SIGSOFT International Symposium on Foundations ofSoftware Engineering (FSErsquo01) pages 109ndash120 ACM Press 2001
[73] Luca de Alfaro and Thomas A Henzinger Interface theories forcomponent-based design In Thomas A Henzinger and Christoph MKirsch editors EMSOFT volume 2211 of Lecture Notes in ComputerScience pages 148ndash165 Springer 2001
[74] Luca de Alfaro Thomas A Henzinger and Marieumllle Stoelinga TimedInterfaces In Proc of the 2nd International Workshop on EmbeddedSoftware (EMSOFTrsquo02) volume 2491 of Lecture Notes in ComputerScience pages 108ndash122 Springer 2002
[75] Benoicirct Delahaye Modular Specification and Compositional Analysisof Stochastic Systems PhD thesis Universiteacute de Rennes 1 2010
[76] Benoicirct Delahaye Benoicirct Caillaud and Axel Legay ProbabilisticContracts A Compositional Reasoning Methodology for the Designof Stochastic Systems In Proc 10th International Conference onApplication of Concurrency to System Design (ACSD) Braga PortugalIEEE 2010
[77] Benoicirct Delahaye Benoicirct Caillaud and Axel Legay Probabilisticcontracts A compositional reasoning methodology for the designof systems with stochastic andor non-deterministic aspects FormalMethods in System Design 2011 To appear
[78] Benoicirct Delahaye Uli Fahrenberg Thomas A Henzinger Axel Legayand Dejan Nickovic Synchronous interface theories and time trig-gered scheduling In Holger Giese and Grigore Rosu editorsFMOODSFORTE volume 7273 of Lecture Notes in Computer Sci-ence pages 203ndash218 Springer 2012
[79] Benoicirct Delahaye Joost-Pieter Katoen Kim G Larsen Axel LegayMikkel L Pedersen Falak Sher and Andrzej Wasowski AbstractProbabilistic Automata In Ranjit Jhala and David A Schmidt editorsVMCAI volume 6538 of Lecture Notes in Computer Science pages324ndash339 Springer 2011
[80] Douglas Densmore Sanjay Rekhi and Alberto L Sangiovanni-Vincentelli Microarchitecture Development via Metropolis SuccessivePlatform Refinement In DATE pages 346ndash351 IEEE ComputerSociety 2004
[81] David L Dill Trace Theory for Automatic Hierarchical Verificationof Speed-Independent Circuits ACM Distinguished Dissertations MITPress 1989
[82] Nicolaacutes DrsquoIppolito Dario Fischbein Marsha Chechik and SebastiaacutenUchitel MTSA The Modal Transition System Analyser In Proc ofthe 23rd IEEEACM International Conference on Automated SoftwareEngineering (ASErsquo08) pages 475ndash476 IEEE 2008
[83] Laurent Doyen Thomas A Henzinger Barbara Jobstmann and TatjanaPetrov Interface theories with component reuse In Proceedings of the8th ACM amp IEEE International conference on Embedded softwareEMSOFTrsquo08 pages 79ndash88 2008
[84] Dumitru Potop-Butucaru and Stephen Edwards and Geacuterard BerryCompiling Esterel Springer V 2007 ISBN 0387706267
[85] Cindy Eisner PSL for Runtime Verification Theory and Practice InOleg Sokolsky and Serdar Tasiran editors RV volume 4839 of LectureNotes in Computer Science pages 1ndash8 Springer 2007
[86] Cindy Eisner Dana Fisman John Havlicek Michael JC GordonAnthony McIsaac and David Van Campenhout Formal Syntax andSemantics of PSL - Appendix B of Accellera LRM January 2003Technical report IBM 2003
[87] Cindy Eisner Dana Fisman John Havlicek Yoad Lustig AnthonyMcIsaac and David Van Campenhout Reasoning with temporal logicon truncated paths In Warren A Hunt Jr and Fabio Somenzi editorsCAV volume 2725 of Lecture Notes in Computer Science pages 27ndash39Springer 2003
[88] Johan Eker Joumlrn W Janneck Edward A Lee Jie Liu Xiaojun LiuJ Ludvig Stephen Neuendorffer S Sachs and Yuhong Xiong Tamingheterogeneity - the ptolemy approach Proc of the IEEE 91(1)127ndash144 2003
[89] G Feuillade Modal specifications are a syntactic fragment of the Mu-calculus Research Report RR-5612 INRIA June 2005
[90] Dario Fischbein and Sebastiaacuten Uchitel On correct and completestrong merging of partial behaviour models In Proc of the 16thACM SIGSOFT International Symposium on Foundations of SoftwareEngineering (SIGSOFT FSErsquo08) pages 297ndash307 ACM 2008
[91] F Fleurey P A Muller and J M Jzquel Weaving executabilityinto object-oriented meta-languages In Proceedgins of the 8th In-ternational Conference on Model Driven Engineering Languages andSystems (MODELS05) October 2005
[92] Freacutedeacuteric Boussinot and Robert de Simone The Esterel languageProceedings of the IEEE 79(9)1293ndash1304 1991
[93] Peter Fritzson Principles of Object-Oriented Modeling and Simulationwith Modelica 21 Wiley 2003
[94] Tayfun Gezgin Raphael Weber and Maurice Girod A RefinementChecking Technique for Contract-Based Architecture Designs InFourth International Workshop on Model Based Architecting andConstruction of Embedded Systems ACES-MBrsquo11 volume 7167 ofLecture Notes in Computer Science Springer October 2011
[95] Jens Chr Godskesen Kim Guldstrand Larsen and Arne Skou Auto-matic verification of real-time systems using Epsilon In Son T Vuongand Samuel T Chanson editors PSTV volume 1 of IFIP ConferenceProceedings pages 323ndash330 Chapman amp Hall 1994
[96] G Goumlssler and J-B Raclet Modal Contracts for Component-basedDesign In Proc of the 7th IEEE International Conference on SoftwareEngineering and Formal Methods (SEFMrsquo09) IEEE Computer SocietyPress November 2009
[97] Susanne Graf and Sophie Quinton Contracts for BIP HierarchicalInteraction Models for Compositional Verification In John Derrick andJuumlri Vain editors FORTE volume 4574 of Lecture Notes in ComputerScience pages 1ndash18 Springer 2007
[98] Orna Grumberg and David E Long Model checking and modularverification ACM Trans Program Lang Syst 16(3)843ndash871 1994
[99] Imene Ben Hafaiedh Susanne Graf and Sophie Quinton Reasoningabout Safety and Progress Using Contracts In Proc of ICFEMrsquo10volume 6447 of LNCS pages 436ndash451 Springer 2010
[100] Nicolas Halbwachs Synchronous programming of reactive systemsKluwer Academic Pub 1993
[101] Nicolas Halbwachs Fabienne Lagnier and Christophe Ratel Program-ming and Verifying Real-Time Systems by Means of the SynchronousData-Flow Language Lustre IEEE Trans Software Eng 18(9)785ndash793 1992
[102] Nicolas Halbwachs Fabienne Lagnier and Pascal Raymond Syn-chronous observers and the verification of reactive systems In MauriceNivat Charles Rattray Teodor Rus and Giuseppe Scollo editorsAMAST Workshops in Computing pages 83ndash96 Springer 1993
[103] Nicolas Halbwachs and Pascal Raymond Validation of synchronousreactive systems From formal verification to automatic testing In P SThiagarajan and Roland H C Yap editors ASIAN volume 1742 ofLecture Notes in Computer Science pages 1ndash12 Springer 1999
[104] David Harel Statecharts A visual formalism for complex systemsSci Comput Program 8(3)231ndash274 1987
[105] David Harel Hillel Kugler Shahar Maoz and Itai Segall Acceleratingsmart play-out In Jan van Leeuwen Anca Muscholl David PelegJaroslav Pokornyacute and Bernhard Rumpe editors SOFSEM volume5901 of Lecture Notes in Computer Science pages 477ndash488 Springer2010
[106] David Harel Robby Lampert Assaf Marron and Gera Weiss Model-checking behavioral programs In Samarjit Chakraborty Ahmed Jer-raya Sanjoy K Baruah and Sebastian Fischmeister editors EMSOFTpages 279ndash288 ACM 2011
[107] David Harel and Rami Marelly Come Letrsquos Play Scenario-BasedProgramming Using LSCs and the Play-Engine Springer-Verlag 2003httpwwwwisdomweizmannacil~harelComeLetsPlaypdf
[108] David Harel Assaf Marron and Gera Weiss Behavioral programmingCommun ACM 55(7)90ndash100 2012
[109] David Harel Assaf Marron Guy Wiener and Gera Weiss Behavioralprogramming decentralized control and multiple time scales InCristina Videira Lopes editor SPLASH Workshops pages 171ndash182ACM 2011
[110] David Harel and Amir Pnueli On the development of reactive systemsIn K R Apt editor Logic and Models for Verification and Specificationof Concurrent Systems volume F13 of NATO ASI Series pages 477ndash498 Springer-Verlag 1985
[111] H Heinecke W Damm B Josko A Metzner H KopetzA Sangiovanni-Vincentelli and M Di Natale Software Componentsfor Reliable Automotive Systems In Design Automation and Test inEurope 2008 DATE rsquo08 pages 549ndash554 march 2008
[112] Thomas A Henzinger and Dejan Nickovic Independent imple-mentability of viewpoints In Radu Calinescu and David Garlan edi-
RR ndeg 8147
Contracts for System Design 63
tors Monterey Workshop volume 7539 of Lecture Notes in ComputerScience pages 380ndash395 Springer 2012
[113] C A R Hoare An axiomatic basis for computer programmingCommun ACM 12(10)576ndash580 1969
[114] INCOSE Incose systems engineering handbook 2010 httpwwwincoseorgProductsPubsproductssehandbookaspx
[115] Cliff B Jones Specification and design of (parallel) programs In IFIPCongress pages 321ndash332 1983
[116] B Jonsson and K G Larsen Specification and refinement ofprobabilistic processes In Logic in Computer Science (LICS) pages266ndash277 IEEE Computer 1991
[117] Gilles Kahn The Semantics of Simple Language for Parallel Program-ming In IFIP Congress pages 471ndash475 1974
[118] S Karris Introduction to Simulink with Engineering ApplicationsOrchard Publications 2006
[119] G Karsai J Sztipanovits A Ledeczi and T Bapty Model-integrated development of embedded software Proceedings of theIEEE 91(1)145ndash164 January 2003
[120] Gabor Karsai Janos Sztipanovitz Akos Ledczi and Ted Bapty Model-integrated development of embedded software Proceedings of theIEEE 91(1) January 2003
[121] Orna Kupferman and Moshe Y Vardi Modular model checking InWillem P de Roever Hans Langmaack and Amir Pnueli editorsCOMPOS volume 1536 of Lecture Notes in Computer Science pages381ndash401 Springer 1997
[122] Leslie Lamport Proving the correctness of multiprocess programsIEEE Trans Software Eng 3(2)125ndash143 1977
[123] C Larman and VR Basili Iterative and incremental developments abrief history Computer 36(6)47ndash56 June 2003
[124] Kim G Larsen and L Xinxin Equation solving using modal transitionsystems In Proceedings of the 5th Annual IEEE Symp on Logic inComputer Science LICSrsquo90 pages 108ndash117 IEEE Computer SocietyPress 1990
[125] Kim Guldstrand Larsen Modal specifications In Automatic Verifica-tion Methods for Finite State Systems volume 407 of Lecture Notes inComputer Science pages 232ndash246 Springer 1989
[126] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski In-terface InputOutput Automata In Jayadev Misra Tobias Nipkowand Emil Sekerinski editors FM volume 4085 of Lecture Notes inComputer Science pages 82ndash97 Springer 2006
[127] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski ModalIO Automata for Interface and Product Line Theories In ProgrammingLanguages and Systems 16th European Symposium on ProgrammingESOPrsquo07 volume 4421 of Lecture Notes in Computer Science pages64ndash79 Springer 2007
[128] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski OnModal Refinement and Consistency In Proc of the 18th InternationalConference on Concurrency Theory (CONCURrsquo07) pages 105ndash119Springer 2007
[129] Kim Guldstrand Larsen Bernhard Steffen and Carsten Weise A con-straint oriented proof methodology based on modal transition systemsIn Proc of the 1st International Workshop on Tools and Algorithmsfor Construction and Analysis of Systems (TACASrsquo95) volume 1019of Lecture Notes in Computer Science pages 17ndash40 Springer 1995
[130] Kim Guldstrand Larsen and Bent Thomsen A Modal Process LogicIn Proceedings of the Third Annual Symposium on Logic in ComputerScience (LICSrsquo88) pages 203ndash210 IEEE 1988
[131] A Ledeczi A Bakay M Maroti P Volgyesi G Nordstrom J Sprin-kle and G Karsai Composing domain-specific design environmentsIEEE Computer 34(11)44 ndash51 November 2001
[132] Akos Ledeczi Miklos Maroti Arpad Bakay Gabor Karsai JasonGarrett Charles Thomason Greg Nordstrom Jonathan Sprinkle andPeter Volgyesi The generic modeling environment In Proceedingsof the IEEE International Workshop on Intelligent Signal Processing(WISP2001) Budapest Hungary May 24ndash25 2001
[133] Edward A Lee Cyber physical systems Design challenges TechnicalReport UCBEECS-2008-8 EECS Department University of Califor-nia Berkeley Jan 2008
[134] Nancy A Lynch Inputoutput automata Basic timed hybrid proba-bilistic dynamic In Roberto M Amadio and Denis Lugiez editorsCONCUR volume 2761 of Lecture Notes in Computer Science pages187ndash188 Springer 2003
[135] Nancy A Lynch and Eugene W Stark A proof of the kahn principlefor inputoutput automata Inf Comput 82(1)81ndash92 1989
[136] Zohar Manna and Amir Pnueli Temporal verification of reactivesystems Safety Springer 1995
[137] Herveacute Marchand Patricia Bournai Michel Le Borgne and Paul LeGuernic Synthesis of Discrete-Event Controllers Based on the SignalEnvironment Discrete Event Dynamic Systems 10(4)325ndash346 2000
[138] Herveacute Marchand and Mazen Samaan Incremental Design of aPower Transformer Station Controller Using a Controller SynthesisMethodology IEEE Trans Software Eng 26(8)729ndash741 2000
[139] B Meyer Applying ldquodesign by contractrdquo IEEE Computer 25(10)40ndash51 October 1992
[140] Bertrand Meyer Touch of Class Learning to Program Well UsingObject Technology and Design by Contract Springer SoftwareEngineering 2009
[141] MW Maier Architecting Principles for Systems of Systems SystemsEngineering 1(4)267ndash284 1998
[142] Walid A Najjar Edward A Lee and Guang R Gao Advances in thedataflow computational model Parallel Computing 25(13-14)1907ndash1929 1999
[143] Radu Negulescu Process Spaces and the Formal Verification ofAsynchronous Circuits PhD thesis University of Waterloo Canada1998
[144] Nicolas Halbwachs and Paul Caspi and Pascal Raymond and DanielPilaud The synchronous data flow programming language LustreProceedings of the IEEE 79(9)1305ndash1320 1991
[145] P Nuzzo A Sangiovanni-Vincentelli X Sun and A PuggelliMethodology for the design of analog integrated interfaces usingcontracts IEEE Sensors Journal 12(12)3329ndash3345 Dec 2012
[146] Object Management Group (OMG) Model driven architecture (MDA)FAQ [online] httpwwwomgorgmda
[147] Object Management Group (OMG) Unified Modeling Language(UML) specification [online] httpwwwomgorgspecUML
[148] Object Management Group (OMG) A UML profile for MARTE beta1 OMG Adopted Specification ptc07-08-04 OMG August 2007
[149] Object Management Group (OMG) System modeling languagespecification v11 Technical report OMG 2008
[150] Object constraint language version 20 OMG Available Specificationformal06-05-01 Object Management Group May 2006
[151] The Design Automation Standards Committee of the IEEE Com-puter Society editor 1850-2010 - IEEE Standard for PropertySpecification Language (PSL) IEEE Computer Society 2010
[152] J Hudak P Feiler D Gluch The Architecture Analysis and DesignLanguage (AADL) An Introduction Software Engineering Institute(SEI) Technical Note CMUSEI-2006-TN-011 February 2006
[153] Roberto Passerone Semantic Foundations for Heterogeneous SystemsPhD thesis Department of Electrical Engineering and Computer Sci-ences University of California Berkeley Berkeley CA 94720 May2004
[154] Roberto Passerone Jerry R Burch and Alberto L Sangiovanni-Vincentelli Refinement preserving approximations for the design andverification of heterogeneous systems Formal Methods in SystemDesign 31(1)1ndash33 August 2007
[155] Roberto Passerone Luca de Alfaro Thomas A Henzinger and AlbertoSangiovanni-Vincentelli Convertibility verification and converter syn-thesis Two faces of the same coin In Proceedings of InternationalConference on Computer Aided Design San Jose CA 2002
[156] Roberto Passerone Imene Ben Hafaiedh Susanne Graf Albert Ben-veniste Daniela Cancila Arnaud Cuccuru Seacutebastien Geacuterard FrancoisTerrier Werner Damm Alberto Ferrari Leonardo Mangeruca Bern-hard Josko Thomas Peikenkamp and Alberto Sangiovanni-VincentelliMetamodels in Europe Languages tools and applications IEEEDesign and Test of Computers 26(3)38ndash53 MayJune 2009
[157] Paul Le Guernic and Thiserry Gautier and Michel Le Borgne andClaude Le Maire Programming real-time applications with SignalProceedings of the IEEE 79(9)1321ndash1336 1991
[158] I Pill B Jobstmann R Bloem R Frank M Moulin B SterinM Roveri and S Semprini Property simulation Technical ReportProsyd D121 2005
[159] Dumitru Potop-Butucaru Benoicirct Caillaud and Albert BenvenisteConcurrency in synchronous systems Formal Methods in SystemDesign 28(2)111ndash130 2006
[160] Dumitru Potop-Butucaru Robert de Simone and Yves Sorel Neces-sary and sufficient conditions for deterministic desynchronization InChristoph M Kirsch and Reinhard Wilhelm editors EMSOFT pages124ndash133 ACM 2007
RR ndeg 8147
Contracts for System Design 64
[161] Terry Quatrani Visual modeling with Rational Rose 2000 and UML(2nd ed) Addison-Wesley Longman Ltd Essex UK UK 2000
[162] R Sudarsan and SJ Fenves and RD Sriram and F Wang A productinformation modeling framework for product lifecycle managementComputer-Aided Design 371399ndash1411 2005
[163] Jean-Baptiste Raclet Quotient de speacutecifications pour la reacuteutilisationde composants PhD thesis Ecole doctorale Matisse universiteacute deRennes 1 November 2007
[164] Jean-Baptiste Raclet Residual for Component Specifications In Procof the 4th International Workshop on Formal Aspects of ComponentSoftware (FACSrsquo07) 2007
[165] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct CaillaudAxel Legay and Roberto Passerone Modal interfaces Unifyinginterface automata and modal specifications In Proceedings of theNinth International Conference on Embedded Software (EMSOFT09)pages 87ndash96 Grenoble France October 12ndash16 2009
[166] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct CaillaudAxel Legay and Roberto Passerone A modal interface theory forcomponent-based design Fundamenta Informaticae 108(1-2)119ndash149 2011
[167] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct Caillaudand Roberto Passerone Why are modalities good for interfacetheories In Proc of the 9th International Conference on Applicationof Concurrency to System Design (ACSDrsquo09) IEEE Computer SocietyPress 2009
[168] Richard Payne and John Fitzgerald Evaluation of ArchitecturalFrameworks Supporting Contract-Based Specification Technical Re-port CS-TR-1233 Computing Science Newcastle University UK Dec2010 available from httpwwwcsnclacukpublicationstrspapers1233pdf
[169] Robert W Floyd Assigning meaning to programs In JT Schwartzeditor Proceedings of Symposium on Applied Mathematics volume 19pages 19ndash32 1967
[170] A Sangiovanni-Vincentelli S Shukla J Sztipanovits G Yang andD Mathaikutty Metamodeling An emerging representation paradigmfor system-level design Special Section on Meta-Modeling IEEEDesign and Test 26(3)54ndash69 2009
[171] Alberto Sangiovanni-Vincentelli Quo vadis sld Reasoning aboutthe trends and challenges of system level design Proc of the IEEE95(3)467ndash506 2007
[172] D Schmidt Model-driven engineering IEEE Computer pages 25ndash31February 2006
[173] German Sibay Sebastian Uchitel and Viacutector Braberman ExistentialLive Sequence Charts Revisited In ICSE 2008 30th InternationalConference on Software Engineering ACM May 2008
[174] Joseph Sifakis Component-Based Construction of HeterogeneousReal-Time Systems in Bip In Giuliana Franceschinis and KarstenWolf editors Petri Nets volume 5606 of Lecture Notes in ComputerScience page 1 Springer 2009
[175] Functional safety of electricalelectronicprogrammable electronicsafety-related systems Standard IEC 61508
[176] Eugene W Stark A proof technique for relyguarantee properties InS N Maheshwari editor FSTTCS volume 206 of Lecture Notes inComputer Science pages 369ndash391 Springer 1985
[177] Stavros Tripakis Ben Lickly Thomas A Henzinger and Edward ALee On relational interfaces In Proc of the 9th ACM amp IEEEInternational conference on Embedded software (EMSOFTrsquo09) pages67ndash76 ACM 2009
[178] Stavros Tripakis Ben Lickly Thomas A Henzinger and Edward ALee A theory of synchronous relational interfaces ACM TransProgram Lang Syst 33(4)14 2011
[179] Sebastiaacuten Uchitel and Marsha Chechik Merging partial behaviouralmodels In Proc of the 12th ACM SIGSOFT International Symposiumon Foundations of Software Engineering (SIGSOFT FSErsquo10) pages43ndash52 ACM 2004
[180] Jos Warmer and Anneke Kleppe The Object Constraint LanguageGetting Your Models Ready for MDA Addison-Wesley LongmanPublishing Co Inc Boston MA USA 2nd edition 2003
RR ndeg 8147
RESEARCH CENTRERENNES ndash BRETAGNE ATLANTIQUE
Campus universitaire de Beaulieu35042 Rennes Cedex
PublisherInriaDomaine de Voluceau - RocquencourtBP 105 - 78153 Le Chesnay Cedexinriafr
ISSN 0249-6399
- Introduction
-
- The Present System Design
- The Future CPS and SoS
- The Need for a Methodological Effort
- Contract based design
- Readers guide
-
- System Design Challenges
-
- Complexity of Systems
- Complexity of OEM-Supplier Chains
- Managing Requirements
- Managing Risks
- System-wide Optimization
-
- How Challenges have been addressed so far
-
- Complexity of Systems and System-wide Optimization
-
- Layered design
- Component-based design
- The V-model process
- Model-Based Design
- Virtual Integration
- Platform Based Design
-
- Complexity of OEM-Supplier Chains Standardization and Harmonization
-
- Standardization of design entities
- Harmonization of processes and certification
-
- Managing Requirements Traceability and Multiple Viewpoints
- Cross-company Shared Risk Management
- The Need for Contracts
-
- Contracts what why where and how
-
- Contracts
-
- Components and their Environment Contracts
-
- Contract Operators
-
- Contract Composition and System Integration
- Contract Refinement and Independent Development
- Contract Conjunction and Viewpoint Fusion
-
- Contracts in requirement engineering
- Contract Support for Design Methodologies
-
- Supporting open systems
- Managing Requirements and Fusing Viewpoints
- Design Chain Management Re-using and Independent Development
- Deployment and Mapping
-
- Bibliographical note
-
- A Mathematical Meta-theory of Contracts
-
- Components and their composition
- Contracts
- Refinement and conjunction
- Contract composition
- Quotient
- Discussion
- Observers
- Bibliographical note
-
- Panorama of concrete theories
- Panorama AssumeGuarantee contracts
-
- Dataflow AG contracts
- Capturing exceptions
- Dealing with variable alphabets
- Synchronous AG contracts
- Observers
- Discussion
- Bibliographical note
-
- Panorama Interface theories
-
- Components as io-automata
- Interface Automata with fixed alphabet
- Modal Interfaces with fixed alphabet
- Modal Interfaces with variable alphabet
- Projecting and Restricting
- Observers
- Bibliographical note
-
- Panorama Timed Interface Theories
-
- Components as Event-Clock Automata
- Modal Event-Clock Specifications
- Bibliographical note
-
- Panorama Probabilistic Interface Theories
-
- Components as Probabilistic Automata
- Simple Modal Probabilistic Interfaces
- Bibliographical note
-
- The Parking Garage an example in Requirements Engineering
-
- The contract framework
- Top level requirements
- Formalizing requirements as contracts
- Sub-contracting to suppliers
- The four ``C
-
- Consistency amp Compatibility
- Correctness
- Completeness
-
- Discussion
-
- Contracts in the context of Autosar
-
- The Autosar context
- The contract framework
- Exterior Light Management System
-
- Function and timing
- Safety
-
- Integrating Contracts in Autosar
- Summary and discussion
-
- Conclusion
-
- What contracts can do for the designer
- Status of research
- Status of practice
- The way forward
-
- References
-
Contrats pour la conception de systegravemesReacutesumeacute Cet article fait le point sur le concept de contrat pour la conception de systegravemes Les contrats que nous proposonsportent non seulement sur des proprieacuteteacutes de typage de leurs interfaces mais incluent une description abstraite de comportementsNous proposons une meacuteta-theacuteorie ou si lrsquoon veut une theacuteorie geacuteneacuterique des contrats qui permet le deacuteveloppement seacutepareacute desous-systegravemes Nous montrons que cette meacuteta-theacuteorie se speacutecialise en lrsquoune ou lrsquoautre des theacuteories connues
Mots-cleacutes conception des systegravemes composant contrat interface
Contracts for System Design 4
CONTENTS
I Introduction 6I-A The Present System Design 6I-B The Future CPS and SoS 6I-C The Need for a Methodological Effort 6I-D Contract based design 7I-E Readerrsquos guide 7
II System Design Challenges 8II-A Complexity of Systems 8II-B Complexity of OEM-Supplier Chains 9II-C Managing Requirements 9II-D Managing Risks 10II-E System-wide Optimization 10
III How Challenges have been addressed so far 10III-A Complexity of Systems and System-
wide Optimization 10III-A1 Layered design 11III-A2 Component-based design 11III-A3 The V-model process 11III-A4 Model-Based Design 12III-A5 Virtual Integration 12III-A6 Platform Based Design 13
III-B Complexity of OEM-Supplier ChainsStandardization and Harmonization 13III-B1 Standardization of design
entities 13III-B2 Harmonization of processes
and certification 14III-C Managing Requirements Traceability
and Multiple Viewpoints 14III-D Cross-company Shared Risk Management 14III-E The Need for Contracts 15
IV Contracts what why where and how 16IV-A Contracts 16
IV-A1 Components and their Envi-ronment Contracts 16
IV-B Contract Operators 17IV-B1 Contract Composition and
System Integration 17IV-B2 Contract Refinement and In-
dependent Development 18IV-B3 Contract Conjunction and
Viewpoint Fusion 18IV-C Contracts in requirement engineering 19IV-D Contract Support for Design Method-
ologies 20IV-D1 Supporting open systems 20IV-D2 Managing Requirements and
Fusing Viewpoints 20IV-D3 Design Chain Management
Re-using and IndependentDevelopment 21
IV-D4 Deployment and Mapping 21IV-E Bibliographical note 23
V A Mathematical Meta-theory of Contracts 24V-A Components and their composition 24V-B Contracts 25V-C Refinement and conjunction 25V-D Contract composition 26V-E Quotient 27V-F Discussion 27V-G Observers 27V-H Bibliographical note 28
VI Panorama of concrete theories 29
VII Panorama AssumeGuarantee contracts 29VII-A Dataflow AG contracts 30VII-B Capturing exceptions 30VII-C Dealing with variable alphabets 31VII-D Synchronous AG contracts 32VII-E Observers 32VII-F Discussion 32VII-G Bibliographical note 32
VIII Panorama Interface theories 33VIII-A Components as io-automata 33VIII-B Interface Automata with fixed alphabet 34VIII-C Modal Interfaces with fixed alphabet 35VIII-D Modal Interfaces with variable alphabet 37VIII-E Projecting and Restricting 38VIII-F Observers 40VIII-G Bibliographical note 40
IX Panorama Timed Interface Theories 42IX-A Components as Event-Clock Automata 42IX-B Modal Event-Clock Specifications 43IX-C Bibliographical note 43
X Panorama Probabilistic Interface Theories 44X-A Components as Probabilistic Automata 44X-B Simple Modal Probabilistic Interfaces 45X-C Bibliographical note 45
XI The Parking Garage an example in Require-ments Engineering 45
XI-A The contract framework 45XI-B Top level requirements 46XI-C Formalizing requirements as contracts 46XI-D Sub-contracting to suppliers 48XI-E The four ldquoCrdquo 49
XI-E1 Consistency amp Compatibility 49XI-E2 Correctness 50XI-E3 Completeness 50
XI-F Discussion 50
RR ndeg 8147
Contracts for System Design 5
XII Contracts in the context of AUTOSAR 50XII-A The AUTOSAR context 50XII-B The contract framework 51XII-C Exterior Light Management System 51
XII-C1 Function and timing 51XII-C2 Safety 56
XII-D Integrating Contracts in AUTOSAR 58XII-E Summary and discussion 59
XIII Conclusion 59XIII-A What contracts can do for the designer 59XIII-B Status of research 59XIII-C Status of practice 59XIII-D The way forward 59
References 60
RR ndeg 8147
Contracts for System Design 6
I INTRODUCTION
A The Present System Design
System companies such as automotive avionics and con-sumer electronics companies are facing significant difficultiesdue to the exponentially raising complexity of their productscoupled with increasingly tight demands on functionalitycorrectness and time-to-market The cost of being late tomarket or of imperfections in the products is staggering aswitnessed by the recent recalls and delivery delays that systemindustries had to bear
In 2010 Toyota had to recall 10 Million cars worldwidefor reasons that ranged from the infamous sticky acceleratorpedals to steering and engine problems The last recall atthe end of August 2010 was for the engine control moduleToyota is not alone in this situation Most of the automotivemakers had one or more major recalls in the recent past(see eg httpwwwautorecallsus) involving electronics aswell as mechanical parts Boeing and Airbus Industries hadsignificant delays in the delivery of their latest planes (787and A380) For the A380 underlying causes were cited asissues in the cabling system configuration management anddesign process In particular the complexity of the cabinwiring (100000 wires and 40300 connectors) was considereda major issue (see httpenwikipediaorgwikiAirbus_A380)The delays caused the departure of both the EADS and AirbusCEOs and of the program manager for the A380 and caused anoverall earning shortfall of 48 Billion Euros Boeing originallyplanned the first flight of the 787 for August 2007 (seehttpenwikipediaorgwikiBoeing_787) but after a streamof delay announcements the actual first flight occurred onDecember 15 2009 The delays were caused by a number ofunfortunate events and design errors and caused at least a 23Billion USD write-off not counting the claim of Air India of1 Billion USD damages for delayed delivery and the revenueshortfalls
These are examples of the devastating effects that designproblems may cause The specific root causes of these prob-lems are complex and relate to a number of issues rangingfrom design processes and relationships with different depart-ments of the same company and with suppliers to incompleterequirement specification and testing
B The Future CPS and SoS
Many products and services require to take into considera-tion the interactions of computational and physical processesSystems where this interaction is tight and needs special careare called Cyber-Physical Systems (CPS) [133] The broadmajority of these new applications can be classified as ldquodis-tributed sense and control systemsrdquo that go substantially be-yond the ldquocomputerdquo or ldquocommunicaterdquo functions traditionallyassociated with information technology These applicationshave the potential to radically influence how we deal with abroad range of crucial problems facing our society today forexample national security and safety including surveillanceenergy management and distribution environment control
efficient and reliable transportation and mobility and effectiveand affordable health care A recurring property of theseapplications is that they engage all the platform componentssimultaneouslymdashfrom data and computing services on thecloud of large-scale servers data gathering from the sensoryswarm and data access on mobile devicesmdashwith significantheterogeneity These large scale systems composed of subsys-tems that are themselves systems are now called Systems ofSystems (SoS) and are heavily investigated
As the complexity of these systems increases our inabilityto rigorously model the interactions between the physical andthe cyber sides creates serious vulnerabilities Systems becomeunsafe with disastrous inexplicable failures that could not havebeen predicted The challenges in the realization and operationof these CPS and SoS are manifold and cover a broad range oflargely unsolved design and run-time problems These includemodeling and abstraction verification validation and testreliability and resiliency multi-scale technology integrationand mapping power and energy security diagnostics andrun-time management Failure to address these challengesin a cohesive and comprehensive way will most certainlydelay if not prohibit the widespread adoption of these newtechnologies
C The Need for a Methodological Effort
We believe the most promising means to address the chal-lenges in systems engineering is to employ structured andformal design methodologies that seamlessly and coherentlycombine the various dimensions of the design space (be itbehavior space or time) that provide the appropriate abstrac-tions to manage the inherent complexity and that can pro-vide correct-by-construction implementations The followingtechnology issues must be addressed when developing newapproaches to the design of complex systems CPS and SoSbull The overall design flows for heterogeneous systemsmdash
meant here both in a technical and also an organiza-tional sensemdashand the associated use of models acrosstraditional boundaries are not well developed and un-derstood Relationships between different teams inside asame company or between different stake-holders in thesupplier chain are not well supported by solid technicaldescriptions for the mutual obligations
bull System requirement capture and analysis is in largepart a heuristic process where the informal text andnatural language-based techniques in use today are facingsignificant challenges Formal requirement engineeringis in its infancy mathematical models formal analysistechniques and links to system implementation must bedeveloped
bull Dealing with variability uncertainty and life-cycle issuessuch as extensibility of a product family are not well-addressed using available systems engineering methodol-ogy and tools
bull Design-space exploration is rarely performed adequatelyyielding suboptimal designs where the architecture se-lection phase does not consider extensibility re-usability
RR ndeg 8147
Contracts for System Design 7
and fault tolerance to the extent that is needed to reducecost failure rates and time-to-market
bull The verification and validation of ldquocomplex systemsrdquoparticularly at the system integration phase where anyinteractions are complicated and extremely costly toaddress is a common need in defense automotive andother industries
The challenge is to address the entire process and not toconsider only point solutions of methodology tools andmodels that ease part of the design
D Contract based design
It is our goal to offer a new approach to the system designproblem that is rigorous and effective in dealing with theproblems and challenges described before and that at thesame time does not require a radical change in the wayindustrial designers carry out their task as it cuts across designflows of different type contract-based design
Contracts in the layman use of the term are establishedwhen an OEM must agree with its suppliers on the subsystemor component to be delivered Contracts involve a legal partbinding the different parties and a technical annex that servesas a reference regarding the entity to be delivered by thesuppliermdashin this work we focus on the technical facet ofcontracts Contracts can also be used through their technicalannex in concurrent engineering when different teams developdifferent subsystems or different aspects of a system within asame company
In this paper we argue that contracts can be actually usedalmost everywhere and at nearly all stages of system designfrom early requirements capture to embedded computinginfrastructure and detailed design involving circuits and otherhardware Contracts explicitly handle pairs of properties re-spectively representing the assumptions on the environmentand the guarantees of the system under these assumptionsIntuitively a contract is a pair
C = (AG) of Assumptions Guarantees
characterizing in a formal way 1) under which context thedesign is assumed to operate and 2) what its obligations areAssumeGuarantee reasoning has been known for quite sometime but it has been used mostly as verification mean for thedesign of software Our purpose is more ambitious contractbased design with explicit assumptions is a philosophy thatshould be followed all along the design with all kinds ofmodels whenever necessary Here the models we mean arerichmdashnot only profiles types or taxonomy of data but alsomodels describing the functions performances of variouskinds (time and energy) and safety The consideration of richcontracts as above in the industry is still in its infancy Tomake contract-based design a technique of choice for systemengineers we must developbull Mathematical foundations for contract representation and
requirement engineering that enable the design of frame-works and tools
bull A system engineering framework and associated method-ologies and tool sets that focus on system requirementmodeling contract specification and verification at mul-tiple abstraction layers The framework should addresscross-boundary and cross-organizational design activities
This paper intends to provide a unified treatment of contractswhere they are precisely defined and characterized so that theycan be used in design with no ambiguity In addition the paperprovides an important link between interfaces and contractsto show similarities and correspondences Examples of the useof contracts in design will be provided as well as in depthanalysis of existing literature
E Readerrsquos guide
The organization of the paper is explained in Table IIn Section II a review of the challenges that are faced by the
system industry is proposed followed in Section III by ananalysis of the design methodologies that have been deployedto cope with them
Section IV develops a primer on contracts by using a verysimple example requiring only elementary mathematical back-ground to be followed Its purpose is to smoothly introducethe different concepts and operations we need for a contractframeworkmdashthe restricted case considered is by no meansrepresentative of the kind of system we can address usingcontracts We then introduce a motivating example repre-sentative of requirement engineering In a third sub-sectionldquorequirementsrdquo on a theory of contracts are identified fromanalyzing what is expected from contract-based design andin particular the support for 1) the development of differentaspects or viewpoints of a system such as its function safetytiming and resource use by different teams and how to fusethese different aspects and 2) the possibility for differentsuppliers to develop independently the different subsystemssubcontracted to them This section concludes with the relatedbibliography
Section V is the cornerstone of this paper and it is a newvista on contracts The so-called ldquometa-theoryrdquo of contractsis introduced and developed in detail By meta-theory wemean the collection of concepts operations and propertiesthat any formal contract framework should offer Conceptsoperations and properties are thus stated in a fairly genericway Every concrete framework compliant with this meta-theory will inherit these generic properties The meta-theoryfocuses on assumptions and guarantees its formalizes howdifferent aspects or viewpoints of a specification can beintegrated and on which basis independent development bydifferent suppliers can be safely performed
So far the meta-theory is non effective in that it is notsaid how component and contracts are effectively representedand manipulated The subsequent series of sections propose apanorama of major concrete contract frameworks Section VIIdevelops the AssumeGuarantee contracts This framework isthe most straightforward instance of the meta-theory It dealswith pairs (AG) of assumptions and guarantees explicitlyA and G being both expressed as properties This framework
RR ndeg 8147
Contracts for System Design 8
Section methodological tutorial fundamental technical applicationSection IIchallengesSection IIIaddressing the challengesSection IVwhy contracts where and how
Section Vcontract meta-theory
Section VIIAssumeGuarantee contractsSection VIIIInterface theoriesSection IXtimedSection Xprobabilistic
Section XIrequirements engineeringSection XIIAUTOSAR
Section IIdarr
Section III Section IV
Section V Section VII mdash Section VIIIdarr darr
Section XII Section XI
Section IX mdash Section Xdarr darr
Section Section
Section IIdarr
Section III Section IV
Section V Section XI Section XII
Table IREADERrsquoS GUIDE CATEGORIZATION OF THE DIFFERENT SECTIONS (TOP) AND
DEPENDENCIES (BOTTOM LEFT IN-DEPTH READING BOTTOM-RIGHT QUICK READING)
is flexible in that it allows for different styles of descriptionof such propertiesmdashcomputational efficiency depends on thestyle adopted Section VIII develops the Interface theoriesin which assumptions and guarantees are specified by meansof a single object the interface Interface theories turn outto include the most effective frameworks They can easily beadapted to encompass timing (Section IX) and probabilistic(Section X) characteristics of systems
In Section XI a toy example in requirements engineeringis developed This example is simple but rich enough to illus-trate the very difficulties in formalizing requirements It alsoillustrates well the added value of contract based requirementsengineering First the different responsibilities (assumptionsversus obligation or guarantees) that requirement implicit referto are made explicit and captured in our contract frameworkSecond contracts offer a formal meaning for documents ofrequirements structured into chapters or viewpoints Contractsoffer formal support for checking important properties suchas consistency compatibility completeness and more Finallycontracts offer significant assistance in the process of deduc-ing from the top specification an architecture of specificationsfor the different sub-systems for independent developmentWhile our application example is a toy one is it neverthelesstoo complex for dealing with it by hand We handle it by usinga proof-of-concept tool for contract management
Finally Section XII develops a case study in the contextof AUTOSAR AUTOSAR is a recently established standardin the automobile sector This standard was developed withthe objective of allowing for better flexibility in componentreuse and OEMsupplier relations This section illustrates howcontracts can be used to break into simple pieces of reasoningthe difficult task of correct system integration
II SYSTEM DESIGN CHALLENGES
Many challenges face the system community to deliverproducts that are reliable and effective We summarize someof them below
A Complexity of Systems
The ever-expanding use of electronic embedded systems tocontrol increasingly many aspects of the real world and thetrend to interconnect more and more such systems (often fromdifferent manufacturers) into a global network are creating achallenging scenario for system designers In this scenario thethree challenges that are taking center stage are as follows
The Hardware Platform Complexity Most system com-panies rely on Components off-the-shelf (COTS) and pro-grammability to implement their applications For companieswho build ldquophysically largerdquo systems such as avionics and au-tomotive companies the complexity of the hardware platform
RR ndeg 8147
Contracts for System Design 9
Design task Tasks Tasks Tasks Tasks Tasks Tasksdelayed delayed delayed causing delay causing delay causing delayautomotive automation medical automotive automation medical
System integration 630 565 667 423 190 375test and verificationSystem architecture 296 261 333 385 429 313design and specificationSoftware application 444 304 750 269 310 250andor middlewaredevelopment and testProject management 370 283 167 538 381 375and planning
Table IIDIFFICULTIES RELATED TO SYSTEM INTEGRATION
is reflected in the number of Electronic Control Units and intheir interconnections For a top-of-the-line automobile thenumber of processors to manage and interconnect is above50 The layout of the cables that connect these processingelements with sensors and actuators is a serious concern Initialproduction of the Airbus A380 was troubled by delays in partattributed to the 530 km (330 mi) of wiring in each aircraft
The Embedded Software Complexity Given the cost andrisks associated to developing hardware solutions system com-panies are selecting hardware platforms that can be customizedby reconfiguration andor by software programmability Inparticular software is taking the lionrsquos share of the implemen-tation budgets and cost In cell phones more than 1 millionlines of code is standard today while in automobiles theestimated number of lines by 2010 is in the order of hundredsof millions and in the Boeing 787 is in the order of 20 millionlines However as this happens the complexity explosion ofthe software component causes serious concerns for the finalquality of the products and the productivity of the engineeringteams
The Integration Complexity A standard technique to dealwith complexity consists in decomposing top-down the systeminto subsystems This approach which has been customar-ily adopted by the semiconductor industry for years has alimitation as a designer or a group of designers has to fullycomprehend the entire system and to partition appropriately itsvarious parts a difficult task given the enormous complexityof todayrsquos systems
Hence the future is one of developing systems by compos-ing pieces that all or in part have already been predesignedor designed independently by other design groups or evencompanies This has been done routinely in vertical designchains for example in the avionics and automotive sectorsalbeit in a heuristic and ad hoc way The resulting lack of anoverall understanding of the interplay of the subsystems and ofthe difficulties encountered in integrating very complex partscause system integration to become a nightmare in the systemindustry as demonstrated by Table II1
In addition heterogeneity comes into play Integration of
1VDC research Track 3 Embedded Systems Market Statistics Exhibit II-13from volumes on automotiveindustrial automationmedical 2008
electronic and mechanical design tools and frameworks will beessential in the near future Integration of chemical electronicand biology tools will be essential in the further future fornano-systems Data integration and information flow amongthe companies forming the chain have to be supported Inother words it is essential that the fundamental steps of systemdesign (functional partitioning allocation on computationalresources integration and verification) be supported acrossthe entire design development cycle and across different dis-ciplines
B Complexity of OEM-Supplier Chains
The source of the above problems is clearly the increase incomplexity It is however also the difficulty of the OEMs inmanaging the integration and maintenance process with sub-systems that come from different suppliers who use differentdesign methods different software architectures and differenthardware platforms
There are also multiple challenges in defining technicalannexes to commercial contracts between OEM and suppli-ers Specifications used for procurement should be preciseunambiguous and complete However a recurrent reason forfailures causing deep iterations across supply chain boundariesrests in incomplete characterizations of the environment ofthe system to be developed by the supplier such as missinginformation about failure modes and failure rates missing in-formation on possible sources for interferences through sharedresources and missing boundary conditions This highlightsthe need to explicate assumptions on the design context inOEM-supplier commercial contracts In light of an increasedsharing of hardware resources by applications developed bymultiple suppliers a contract-based approach seems indispens-able for resolving liability issues and allowing applicationswith different criticality levels to co-exist (such as ASILlevels[175] [13] in automotive)
C Managing Requirements
We argued that the design chains should connect seamlesslyto minimize design errors and time-to-market delays Yet theboundaries among companies and between different divisionsof the same company are often not as clean as needed anddesign specs move from one company (or one division) to the
RR ndeg 8147
Contracts for System Design 10
next in non-executable and often unstable and imprecise formsthus yielding misinterpretations and consequent design errorsIn addition errors are often caught only at the final integrationstep as the specifications were incomplete and imprecisefurther nonfunctional specifications (eg timing power con-sumption size) are difficult to trace Further it is commonpractice to structure system level requirements into severalldquochaptersrdquo ldquoaspectsrdquo or ldquoviewpointsrdquo Examples include thefunctions safety timing and energy viewpoints Quite oftenthese different viewpoints are developed by different teamsusing different skills frameworks and tools Yet they are notunrelated as we already mentioned Without a clean approachto handle multiple viewpoints the only sensible way is tocollect these viewpoints into a single requirements documentwhich is then seen as a flat collection of requirements forsubsequent design Since this is clearly impracticable thecommon practice instead is to discard some of the viewpointsin a first stage eg by considering only functions and safetyDesigns are then developed based on these only viewpointsOther viewpoints are subsequently taken into account (timingenergy) thus resulting in late and costly modifications andre-designs
Requirement engineering is a discipline that aims at improv-ing this situation by paying close attention to the managementof the requirement descriptions and traceability support (egusing commercial tools such as DOORS2 in combinationwith Reqtify3) and by inserting whenever possible preciseformulation and analysis methods and tools Research in thisarea is active but we believe more needs to be done to makethis essential step a first class citizen in system design Indeedif the specification quality is low then the entire design processis marred since the very beginning The overall system productspecification is somewhat of an art today since to verify itscompleteness and its correctness there is little that it can beused to compare with
D Managing Risks
System design processes are highly concurrent distributedand typically multi-domain often involving more than onehundred sub-processes The complexity of the entire designprocess and of the relationships between players in the supplychain creates the need to elaborate risk sharing and riskmanagement plans because of the potential enormity of theimpact that design errors and supplier solidity may have onthe economics of a company Risk management has thusbecome a requirement of most of public companies as fi-nancial social and political risks are analyzed and appropriatecountermeasures have to be prepared as a requirement fromthe regulatory bodies Risk mitigation measures typically coverall phases of design processes ranging from assuring highquality initial requirements to early assessments of risks inmeeting product requirements during the concept phase toenforcing complete traceability of such requirements with
2 httpwww-01ibmcomsoftwareawdtoolsdoorsproductline3httpetc
requirements management tools to managing consistency andsynchronization across concurrent sub-processes using PLMtools4 If we will be able to change the design processalong the lines of more formal approaches better complexityhandling better requirement engineering then risks will besubstantially lower than they are today
E System-wide Optimization
We believe that since the design process is fragmentedproduct optimization is rarely carried out across more thanone company boundary and even then it is limited due tobull The lack of appropriate models encompassing both func-
tional and non-functional (Quality of Service) aspectscovering both internal use and export outside the com-pany
bull The time pressure to meet the product deadlinesbull The functional description that is over-constrained by
architectural considerations which de facto eliminate po-tentially interesting implementation alternatives
If the design process were carried out as in a unique well-integrated virtual company including all the players shownabove the overall ecosystem would greatly benefit The issuehere is to allow a reasonably efficient design space explorationby providing a framework where different architectures couldbe quickly assembled and evaluated at each layer of abstractioncorresponding to the design task being considered in the chain
III HOW CHALLENGES HAVE BEEN ADDRESSED SO FAR
In this section we present a review and a critical analysisof the design methodologies that have been deployed to copewith the challenges exposed in the previous section
A Complexity of Systems and System-wide Optimization
Multiple lines of attack have been developed by researchinstitutions and industry to cope with the exponential growth insystems complexity starting from the iterative and incrementaldevelopment several decades ago [123] Among them ofparticular interest to the development of embedded controllersare Layered design Component-based design the V-modelprocess model-based development virtual integration andPlatform-Based Design (PBD) There are two basic princi-ples followed by these methods abstractionrefinement andcompositiondecomposition Abstraction and refinement areprocesses that relate to the flow of design between differentlayers of abstraction (vertical process) while compositionand decomposition operate at the same level of abstraction(horizontal process) Layered design the V-model processand model-based development focus on the vertical processwhile component-based design deals principally with the hor-izontal process PBD combines the two aspects in a unifiedframework and hence subsumes and can be used to integrated
4 PLM Product Lifecycle Management PLM centric design is used incombination with virtual modeling and digital mockups PLM acts as a database of virtual system components PLM centric design is for exampledeployed at Dassault-Aviation httpwwwdassault-aviationcomenaviationinnovationthe-digital-companydigital-designplm-toolshtmlL=1
RR ndeg 8147
Contracts for System Design 11
the other methodologies Contracts are ideal tools to solidifyboth vertical and horizontal processes providing the theoreticalbackground to support formal methods
1) Layered design Layered design copes with complexityby focusing on those aspects of the system pertinent to supportthe design activities at the corresponding level of abstractionThis approach is particularly powerful if the details of alower layer of abstraction are encapsulated when the designis carried out at the higher layer Layered approaches are wellunderstood and standard in many application domains Asan example consider the AUTOSAR standard5 This standarddefines several abstraction layers Moving from ldquobottomrdquoto ldquotoprdquo the micro-controller abstraction layer encapsulatescompletely the specifics of underlying micro-controllers thesecond layer abstracts from the concrete configuration of theElectronic Control Unit (ECU) the employed communicationservices and the underlying operating system whereas the(highest) application layer is not aware of any aspect ofpossible target architectures and relies on purely virtual com-munication concepts in specifying communication betweenapplication components Similar abstraction levels are definedby the ARINC standard in the avionic domains
The benefits of using layered design are manifold Using theAUTOSAR layer structure as example the complete separationof the logical architecture of an application (as represented bya set of components interconnected using the so-called virtualfunction bus) and target hardware is a key aspect of AUTOSARin that it supports decoupling of the number of automotivefunctions from the number of hardware components In par-ticular it is flexible enough to mix components from differentapplications on one and the same ECU This illustrates thedouble role of abstraction layers in allowing designers to focuscompletely on the logic of the application and abstracting fromthe underlying hardware while at the same time imposing aminimal (or even no) constraint on the design space of possiblehardware architectures In particular these abstractions allowthe application design to be re-used across multiple platformsvarying in number of bus-systems andor number and class ofECUs These design layers can in addition be used to matchthe boundaries of either organizational units within a companyor to define interfaces between different organizations in thesupply chain The challenge then rests in providing the properabstractions of lower-level design entities
2) Component-based design Whereas layered designs de-compose complexity of systems ldquoverticallyrdquo component-basedapproaches reduce complexity ldquohorizontallyrdquo whereby designsare obtained by assembling strongly encapsulated design enti-ties called ldquocomponentsrdquo equipped with concise and rigorousinterface specifications Re-use can be maximized by findingthe weakest assumptions on the environment sufficient to es-tablish the guarantees on a given component implementationWhile these interface specifications are key and relevant forany system the ldquoquality attributerdquo of perceiving a subsystemas a component is typically related to two orthogonal criteria
5See httpwwwautosarorg
that of ldquosmall interfacesrdquo and that of minimally constrainingthe deployment context so as to maximize the potential for re-use ldquoSmall interfacesrdquo ie interfaces which are both smallin terms of number of interface variables or ports as wellas ldquologically smallrdquo in that protocols governing the invoca-tion of component services have compact specifications notrequiring deep levels of synchronization constitute evidenceof the success of encapsulationmdashstill small interfaces mustencompass dynamic properties of the system The secondquality attribute is naturally expressible in terms of interfacespecifications where re-use can be maximized by finding theweakest assumptions on the environment sufficient to establishthe guarantees on a given component implementation
One challenge then for component-based design of em-bedded systems is to provide interface specifications that arerich enough to cover all phases of the design cycle Thiscalls for including non-functional characteristics as part ofthe component interface specifications which is best achievedby using multiple viewpoints Current component interfacemodels in contrast are typically restricted to purely functionalcharacterization of components and thus cannot capitalize onthe benefits of virtual integration testing as outlined above
The second challenge is related to product line designwhich allows for the joint design of a family of variants of aproduct The aim is to balance the contradicting goals of striv-ing for generality versus achieving efficient component im-plementations Methods for systematically deriving ldquoquotientrdquospecifications to compensate for ldquominorrdquo differences betweenrequired and offered component guarantees by composing acomponent with a wrapper component (compensating for suchdifferences as characterized by quotient specifications) existsfor restricted classes of component models [155]
3) The V-model process A widely accepted approach todeal with complexity of systems in the defense and trans-portation domain is to structure product development processesalong variations of the V diagram originally developed fordefense applications by the German DoD6
Its characteristic V-shape splits the product developmentprocess into a design and an integration phase Specificallyfollowing product level requirement analysis subsequent stepswould first evolve a functional architecture supporting productlevel requirements Sub-functions are then re-grouped takinginto account re-use and product line requirements into alogical architecture whose modules are typically developed bydifferent subsystem suppliers The realization of such modulesoften involves mechanical hydraulic electrical and electronicsystem design Subsequent phases would then unfold thedetailed design for each of these domains such as the designof the electronic subsystem involving among others the designof electronic control units These design phases are paralleledby integration phases along the right-hand part of the Vsuch as integrating basic- and application software on theECU hardware to actually construct the electronic control unitintegrating the complete electronic subsystems integrating the
6See eg httpwwwv-model-xtde
RR ndeg 8147
Contracts for System Design 12
mechatronic subsystem to build the module and integratingmultiple modules to build the complete product Not shownbut forming an integral part of V-based development processesare testing activities where at each integration level test-suites developed during the design phases are used to verifycompliance of the integrated entity to their specification
This presentation is overly simplistic in many ways Thedesign of electronic components in complex systems suchas aircrafts inherently involves multi-site multi-domain andcross-organizational design teams reflecting eg a partition-ing of the aircraft into different subsystems (such as primaryand secondary flight systems cabin fuel and wing) differentdomains such as the interface of the electronic subsystem tohydraulic andor mechanical subsystems control-law designtelecommunications software design hardware design diag-nostics and development-depth separated design activities car-ried out at the OEM and supplier companies This partitioningof the design space (along perspectives and abstraction layers)naturally lends itself to a parallelization of design activitiesa must in order to achieve timely delivery of the overallproduct leading often into the order of hundreds of concurrentdesign processes To summarize while being popular andwidely referenced the V-model process has become a ldquosloganrdquohiding the complexity of actual design processes In realitylarge system companies develop their own processes and thenstruggle for their application both in-house and across thesupplier chain
4) Model-Based Design Model-based design (MBD) is to-day generally accepted as a key enabler to cope with complexsystem design due to its capabilities to support early require-ment validation and virtual system integration MBD-inspireddesign languages and tools such as SysML7 [149] andorAADL [152] for system level modeling Catia and Model-ica [93] for physical system modeling Matlab-Simulink [118]for control-law design and UML8 [44] [147] Scade [32]and TargetLink for detailed software design depend on de-sign layer and application class The state-of-the-art in MBDincludes automatic code-generation simulation coupled withrequirement monitoring co-simulation of heterogeneous mod-els such as UML and Matlab-Simulink model-based analy-sis including verification of compliance of requirements andspecification models model-based test-generation rapid pro-totyping and virtual integration testing as further elaboratedbelow
In MBD today non-functional aspects such as performancetiming power or safety analysis are typically addressed indedicated specialized tools using tool-specific models withthe entailed risk of incoherency between the correspond-ing models which generally interact To counteract theserisks meta-models encompassing multiple views of designentities enabling co-modeling and co-analysis of typicallyheterogeneous viewpoint specific models have been developedExamples include the MARTE UML [148] profile for real-time
7httpwwwomgorgspecSysML8httpwwwomgorgspecUML
system analysis the SPEEDS HRC metamodel [156] and theMetropolis semantic meta-model [19] [67] [16] [170] InMetropolis multiple views are accommodated via the conceptof ldquoquantitiesrdquo that annotate the functional view of a designand can be composed along with subsystems using a suitablealgebra The SPEEDS meta-model building on and extendingSysML has been demonstrated to support co-simulation andco-analysis of system models for transportation applicationsallowing co-assessment of functional real-time and safety re-quirements It forms an integral part of the meta-model-basedinter-operability concepts of the CESAR reference technologyplatform9
Meta-modeling is also at the center of the model driven(software) development (MDD) methodology MDD is basedon the concept of the model-driven architecture (MDA) whichconsists of a Platform-Independent Model (PIM) of the ap-plication plus one or more Platform-Specific Models (PSMs)and sets of interface definitions MDA tools then supportthe mapping of the PIM to the PSMs as new technologiesbecome available or implementation decisions change [146]The Vanderbilt University group [119] has evolved an em-bedded software design methodology and a set of tools basedon MDD In their approach models explicitly represent theembedded software and the environment it operates in andcapture the requirements and the design of the applicationsimultaneously using domain-specific languages (DSL) Thegeneric modeling environment (GME) [119] provides a frame-work for model transformations enabling easy exchange ofmodels between tools and offers sophisticated ways to sup-port syntactic (but not semantic) heterogeneity The KerMetametamodeling workbench [91] is similar in scope
5) Virtual Integration Rather than ldquophysicallyrdquo integratinga system from subsystems at integration stages model-baseddesign allows systems to be virtually integrated based on themodels of their subsystem and the architecture specificationof the system Such virtual integration thus allows detectingpotential integration problems up front in the early designphases Virtual system integration is often a source of het-erogeneous system models such as when realizing an aircraftfunction through the combination of mechanical hydraulicand electronic systems Heterogeneous composition of modelswith different semantics was originally addressed in Ptolemy[88] Metropolis [20] [67] [16] [48] and in the SPEEDSmeta-model of heterogeneous rich components [65] [29] [31]albeit with different approaches Virtual integration involvesmodels of the functions the computer architecture with itsextra-functional characteristics (timing and other resources)and the physical system for control Some existing frameworksoffer significant support for virtual integration Ptolemy IIMetropolis and RT-Builder Developments around Catia andModelica as well as the new offer SimScape by Simulinkprovide support for virtual integration of the physical part atan advanced level
9wwwcesarprojecteu
RR ndeg 8147
Contracts for System Design 13
6) Platform Based Design Platform-based design was in-troduced in the late 1980s to capture a design process thatcould encompass horizontal (component-based design virtualintegration) and vertical (layered and model-based design)decompositions and multiple viewpoints and in doing sosupport the supply chain as well as multi-layer optimization
The idea was to introduce a general approach that couldbe shared across industrial domain boundaries that wouldsubsume the various definition and design concepts and thatwould extend it to provide a framework to reason aboutdesign Indeed the concepts have been applied to a variety ofvery different domains from automotive to System-on-Chipfrom analog circuit design to building automation to syntheticbiology
The basic tenets of platform-based design are as followsThe design progresses in precisely defined abstraction layersat each abstraction layer functionality (what the system issupposed to do) is strictly separated from architecture (howthe functionality could be implemented) This aspect is clearlyrelated to layered design and hence it subsumes it
Each abstraction layer is defined by a design platform Adesign platform consists ofbull A set of library components This library not only con-
tains computational blocks that carry out the appropriatecomputation but also communication components that areused to interconnect the computational components
bull Models of the components that represent a characteri-zation in terms of performance and other non-functionalparameters together with the functionality it can supportNot all elements in the library are pre-existing com-ponents Some may be ldquoplace holdersrdquo to indicate theflexibility of ldquocustomizingrdquo a part of the design that isoffered to the designer In this case the models representestimates of what can be done since the components arenot available and will have to be designed At times thecharacterization is indeed a constraint for the implementa-tion of the component and it is obtained top-down duringthe refinement process typical of layered designs Thislayering of abstractions based on mathematical models istypical of model-based methods and the introduction ofnon-functional aspects of the design relates to viewpoints
bull The rules that determine how the components can beassembled and how the the functional and non-functionalcharacteristics can be computed given the ones of thecomponents to form an architectureThen a platformrepresents a family of designs that satisfies a set ofplatform-specific constraints [15] This aspect is relatedto component-based design enriched with multiple view-points
This concept of platform encapsulates the notion of re-use asa family of solutions that share a set of common features (theelements of the platform) Since we associate the notion ofplatform to a set of potential solutions to a design problem weneed to capture the process of mapping a functionality (whatthe system is supposed to do) with the platform elements thatwill be used to build a platform instance or an ldquoarchitecturerdquo
(how the system does what it is supposed to do) The strictseparation between function and architecture as well as themapping process have been highly leveraged in AUTOSARThis process is the essential step for refinement and provides amechanism to proceed towards implementation in a structuredway Designs on each platform are represented by platform-specific design models A design is obtained by a designerrsquoscreating platform instances (architectures) via composing plat-form components (process that is typical of component-baseddesign) by mapping the functionality onto the components ofthe architecture and by propagating the mapped design in thedesign flow onto subsequent abstraction layers that are dealtwith in the same way thus presenting the design process asan iterative refinement This last point dictates how to moveacross abstraction layers it is an important part of design spaceexploration and offers a way of performing optimization acrosslayers In this respect PBD supports multiple viewpoints in ageneral way
B Complexity of OEM-Supplier Chains Standardization andHarmonization
So far the main answer to the complexity of OEM-supplierchains has been standardization Standardization concerns boththe design entities and the design processes particularlythrough the mechanism of certification
1) Standardization of design entities By agreeing on (do-main specific) standard representations of design entitiesdifferent industrial domains have created their own linguafranca thus enabling a domain wide shared use of designentities based on their standardized representation Exam-ples of these standards in the automotive sector include therecently approved requirement interchange format standardRIF10 the AUTOSAR11 de-facto standard the OSEK12 operat-ing system standard standardized bus-systems such as CAN13
and Flexray14 standards for ldquocar2Xrdquo communication andstandardized representations of test supported by ASAM15Examples in the aerospace domain include ARINC stan-dards16 such as the avionics applications standard interfaceIMA RTCA17 communication standards In the automationdomain standards for interconnection of automation devicessuch as Profibus18 are complemented by standardized designlanguages for application development such as Structured Text
As standardization moves from hardware to operating sys-tem to applications and thus crosses multiple design layersthe challenge increases to incorporate all facets of designentities required to optimize the overall product while atthe same time enabling distributed development in complex
10httpwwww3org2005ruleswikiRIF_Working_Group11httpwwwautosarorg12httpwwwosek-vdxorg13httpwwwisoorgisosearchhtmqt=Controller+Area+
NetworkampsearchSubmit=Searchampsort=relamptype=simpleamppublished=true14httpwwwflexraycom15httpwwwasamnet16httpwwwaeec-amc-fsemccomstandardsindexhtml17httpwwwrtcaorg18httpwwwprofibuscom
RR ndeg 8147
Contracts for System Design 14
supply chains As an example to address the different view-points required to optimize the overall product AUTOSARextended in transitioning from release 31 to 4 its capabilityto capture timing characteristics of design entities a keyprerequisite for assessing alternate deployments with respectto their impact on timing More generally the need for overallsystem optimization calls for the standardization of all non-functional viewpoints of design entities an objective yet tobe achieved in its full generality in order to allow crosslayer optimization Within the EDA domain such richnessof design interface specifications is industrial practice Withinthe systems domain the rich component model introduced inthe Integrated Projects SPEEDS tackles this key objective incovering multiple design layers (from product requirements todeployment on target architectures) and in providing means ofassociating multiple viewpoints with each design entity it isexpressive enough to allow for cross-supply chain optimizationof product developments This approach is further elaboratedand driven towards standardization in the Artemis flagshipproject CESAR
2) Harmonization of processes and certification Harmo-nizing or even standardizing key processes (such as devel-opment processes and safety processes) provides for a fur-ther level of optimization in interactions across the supplychain As an example Airbus Directives and Procedures(ADBs) provide requirements for design processes of equip-ment manufactures Often harmonized processes across thesupply chain build on agreed maturity gates with incrementalacceptance testing to monitor progress of supplier developmenttowards final acceptance often building on incremental proto-types Shared use of Product Lifcycle Management (PLM)19
databases across the supply chain offers further potentialsfor cross-supply chain optimization of development processesAlso in domains developing safety related systems domainspecific standards clearly define the responsibilities and dutiesof companies across the supply chain to demonstrate func-tional safety such as in the ISO 2626220 for the automotivedomain IEC 6150821 for automation its derivatives CenelecEN 50128 and 5012622 for rail and Do 178 B23 for civilavionics
Yet the challenge in defining standards rests in balancingthe need for stability with the need of not blocking processinnovations As an example means for compositional con-struction of safety cases are seen as mandatory to reducecertification costs in the aerospace and rail domains Similarlythe potential of using formal verification techniques to copewith increasing system complexity is considered in the movefrom DO 178 B to DO 178 C standards
19See [162] and also footnote 420httpwwwisoorgisocatalogue_detailhtmcsnumber=4346421httpwwwiecchfunctionalsafety22httpwwwceneleceuCenelecCENELEC+in+actionWeb+Store
Standardsdefaulthtm23httpwwwdo178sitecom
C Managing Requirements Traceability and Multiple View-points
Depending on application domains up to 50 of all er-rors result from imprecise incomplete or inconsistent andthus unfeasible requirements Requirements are inherently illstructured They must address all aspects of the system andthus cannot be constrained by the lingua franca of a partic-ular domain They are fragmented in the form of large andsometimes huge DOORS files24 structured into viewpointsTwo issues have thus been identified by systems industries asessential for requirement management powerful and flexibletraceability tools to relate requirements between them and tolink them to tests for validation purposes and the developmentof domain specific ontologies as part of the PLM suiteFurther based on an assessment by the system companiesprocesses in the CESAR project25 and the German EmbeddedSystems Innovation alliance26 and building on the finding ofthe Integrated Project SPEEDS27 multiple viewpoints havebeen categorized into perspectives and aspects to provide asolid requirement and property modeling scaffold Perspectivesare viewpoints relevant to architecture modeling as carriedout by different stake-holders during the development processAspects are viewpoints that are orthogonal to the systemstructure Aspects are used to demonstrate compliance of thearchitecture to end-user concerns Example of aspects aresafety cost maintainability performance and weight Themeta-model underlying the CESAR RTP is able to maintainlinks such as the satisfy derive verify refine and allocaterelationships between design artifacts of different perspectivesand across abstraction layers
In addition to cope with the inherently unstructured prob-lem of (in)completeness of requirements industry has setup domain- and application-class specific methodologies Asparticular examples we mention learning process such asemployed by Airbus to incorporate the knowledge base ofexternal hazards from flight incidents the Code of Practiceproposed by the Prevent Project28 using guiding questions toassess the completeness of requirements in the concept phaseof the development of advanced driver assistance systemsUse-case analysis methods as advocated for UML baseddevelopment process follow the same objective All togetherrequirement engineering misses the support of formal ap-proaches for its structuring and analysis
D Cross-company Shared Risk Management
The realization of complex systems calls for design pro-cesses that mitigate risks in highly concurrent distributedand typically multi-domain engineering processes often in-volving more than one hundred sub-processes Risk mitigation
24Typical sub-systems in aeronautics would have a few thousands top-levelrequirements An aircraft can have up to several hundred thousands of them
25wwwcesarprojecteu26httpspes2020informatiktu-muenchende27httpwwwspeedseucom28Albert http
RR ndeg 8147
Contracts for System Design 15
measures typically cover all phases of design processes rang-ing from ensuring high quality initial requirements to earlyassessments of risks in realizability of product requirementsduring the concept phase to enforcing complete traceabilityof such requirements with requirements management tools tomanaging consistency and synchronization across concurrentsub-processes using PLM tools A key challenge rests inbalancing risk reduction versus development time and effortcompletely eliminating the risks stemming from concurrentengineering essentially requires a complete synchronizationalong a fine-grained milestone structure which would kill anydevelopment project due to the induced delays Another keychallenge is the ldquonot my faultrdquo syndrome in the OEM-supplierchain when errors call for costly re-design and the issue ofpenalties arises Properly assigning responsibilities to risks isstill out of reach today
E The Need for Contracts
The way system design challenges have been addressed sofar leaves huge opportunities for improvements by relying oncontract-based design In this section we briefly summarizefor each existing approach to address the design challengeshow contracts could improve the current situation
Contribution 1 Addressing Complexity of Systems andSystem-wide OptimizationWhile layered design (Section III-A1) and component baseddesign (Section III-A2) have been critical steps in breakingsystems complexity they do not by themselves provide theultimate answer When design is being performed at a consid-ered layer implicit assumptions regarding other layers (egcomputing resources) are typically invoked by the designerwithout having these explicated Hence actual properties ofthese other layers cannot be confronted against these hiddenassumptions Similarly when components or sub-systems areabstracted via their interfaces in component based design itis generally not true that such interfaces provide sufficientinformation for other components to be safely implementedbased on this sole interface Contract-based design providesthe due discipline concepts and techniques to cope with thesedifficulties
Model-based development (Section III-A4) has reached sig-nificant maturity by covering nearly all aspects of the system(physics functions computing resources) albeit not yet in afully integrated way To offer a real added value any newlyproposed technology should be rich enough for encompassingall these aspects as well Contract-based design offers in largepart this desirable feature
Virtual integration and virtual modeling (Section III-A5) isa step beyond basic model-based development by offering anintegrated view of all the above different aspects eg physics+ functions + performances Contract-based design supportsthe fusion of different systems aspects
Contract-based design is compliant with the V-model pro-cess (Section III-A3) just because it does not impose anyparticular design process Using contracts only imposes a
small set of rules that any process should accommodate seeSection IV-D for a discussion of this
Finally Platform-Based Design (PBD Section III-A6)which is being deployed in some large systems industries suchas United Technologies Corporation (UTC) is a systematicand comprehensive methodology that unifies the various de-sign methodologies that have been described in this sectionContracts offer theory and methodological support for boththe successive refinement aspect the composition aspect andthe mapping process of PBD allowing formal analysis andsynthesis processes
Contribution 2 Addressing the Complexity of OEM-Supplier ChainsThe problems raised by the complexity of OEM-SupplierChains (Section II-B) are indeed the core target of contract-based design By making the explication of implicit assump-tions mandatory contracts help assigning responsibilities toa precise stake holder for each design entity By supportingindependent development of the different sub-systems whileguaranteing smooth system integration they orthogonalize thedevelopment of complex systems Contracts are thus adequatecandidates for a technical counterpart of the legal bindingsbetween partners involved in the distributed and concurrentdevelopment of a system
Contribution 3 Managing RequirementsSo far the task of getting requirements right and managingthem well (Section III-C) has only got support for sortingthe complexity out (traceability services and ontologies whichis undoubtely necessary) However requirements can only betested on implementations and it is not clear whether properdistinctions are made when performing tests regarding thefollowing fusing the results of tests associated to differentchapters or viewpoints of a requirement document versusfusing the results of tests associated to different sub-systemstesting a requirement under the responsibility of the designerof the considered sub-system versus testing a requirementcorresponding to an assumption regarding the context of useof this sub-systemmdashsuch distinctions should be made as weshall see Also requirements are barely executable and cannotin general be simulated Requirements engineering is the otherprimary target of contract-based design the above issues areproperly handled by contracts and contracts offer improvedsupport for evidencing the satisfaction of certification con-straints
Contribution 4 Managing RisksRisk metrics and risk mitigation measures are the essentialtools in managing risks (Section III-D) By offering improvedsupport for sub-contracting and distributing design to differentteams contracts are likely to significantly reduce the ldquonot myfaultrdquo syndrome
Contribution 5 Addressing CertificationAs explained in Section III-B2 the design of critical sys-tems is subject to a number of certification standards Whilecertification steps are mostly concerned with the processesnot the designs themselves the recent move from DO 178Bto DO 178C for level A critical systems in aeronautics has
RR ndeg 8147
Contracts for System Design 16
shown for the first time the consideration of formal proofsor validations as valid evidences We believe that the samewill eventually hold for contracts In particular by providingadequate formal support for completeness consistency com-patibility and more for sets of requirements contracts wouldprovide a valuable contribution to certification
IV CONTRACTS WHAT WHY WHERE AND HOWAs we argued in the previous section there are two basic
principles followed by design methods so far developed ab-stractionrefinement and compositiondecomposition Abstrac-tion and refinement are processes that relate to the flow of de-sign between different layers of abstraction (vertical process)while composition and decomposition operate at the same levelof abstraction (horizontal process) In this section we presentbriefly contracts and the basic operations they support andthen me make the point that contracts are ideal tools to solidifyboth vertical and horizontal processes providing the theoreticalbackground to support formal methods We conclude thesection by providing a (non exhaustive) bibliography on thegeneral concept of contract
A Contracts
Here we propose a ldquoprimerrdquo on contracts using a simpleexample as the reference for their use
1) Components and their Environment Contracts We startfrom a model that consists of a universal set M of com-ponents each denoted by the symbol M A component Mis typically an open system ie it contains some inputsthat are provided by other components in the system or theexternal world and it generates some outputs This collectionof other components and the exterior world is referred to as theenvironment of the component The environment is often notcompletely known when the component is being developedAlthough components cannot constrain their environment theyare designed to be used in a particular context
In the following example we define a component M1 thatcomputes the division between two real inputs x and y andreturns the result through the real output z The underlyingassumption is that M1 will be used within a design contextthat prevents the environment from giving the input y = 0Since M1 cannot constrain its input variables we handle theexceptional input y = 0 by generating an arbitrary output
M1
variables
inputs x y
outputs z
types x y z isin Rbehaviors (y 6= 0rarr z = xy) and (y = 0rarr z = 0)
A contract contract denoted by the symbol C is a de-scription of a component with the following characteristicproperties
1) Contracts are intentionally abstract2) Contracts distinguish responsibilities of a component
from that of its environmentProperty 1) of a contract highlights the goal of handlingcomplexity of the systems Thus contracts expose enough
information about the component but not more than necessaryfor the intended purpose We can see a contract as an under-specified description of a component that can be either veryclose to the actual component or specify only a singleproperty of a componentrsquos behavior Regarding Property 2)and in contrast to components a contract explicitly makes adistinction between assumptions made about the environmentand guarantees provided mirroring different roles and respon-sibilities in the design of systems
A contract can be implemented by a number of differentcomponents and can operate in a number of different envi-ronments Hence we define a contract C at its most abstractlevel as a pair C = (EC MC ) of subsets of components thatimplement the contract and of subsets of environments inwhich the contract can operate We say that a contract C isconsistent if MC 6= empty and compatible if EC 6= empty
This definition of contracts and the implementation relationis very general and as such it is not effective In concretecontract- based design theories a contract needs to have afinite description that does not directly refer to the actualcomponents and the implementation relation needs to beeffectively computable and establish the desired link betweena contract and the underlying components that implement it
For our present simple example of static systems wepropose the following way to specify contracts
C1
variables
inputs x y
outputs z
types x y z isin Rassumptions y 6= 0
guarantees z = xy
C1 defines the set of components having as variablesinputs x y output z of type real and whose behaviorssatisfy the implication
ldquoassumptionsrArr guaranteesrdquo
ie for the above example y 6= 0rArr z = xy Intuitivelycontract C1 specifies the intended behavior of components thatimplement division It explicitly makes the assumption that theenvironment will never provide the input y = 0 and leaves thebehavior for that input undefined
This contract describes an infinite number of environmentsin which it can operate namely the set EC1
of environmentsproviding values for x and y with the condition that y 6=0 Itdescribes an infinite number of components that implementthe above specification where the infinity comes from theunderspecified case on how an implementation of C1 shouldcope with the illegal input y = 0 In particular we have thatM1 implements C1 Thus contract C1 is consistent We nowshow a variant of contract C1 that is not consistent
Cprime1
variables
inputs x y
outputs z
types x y z isin Rassumptions T
guarantees z = xyRR ndeg 8147
Contracts for System Design 17
where symbol T denotes the boolean constant ldquotruerdquo Incontrast to C1 the contract Cprime1 makes no assumption on valuesof the input y Hence every component that implements Cprime1has to compute the quotient xy for all values of y includingy = 0 which makes no sense
B Contract Operators
There are three basic contract operators that are used insupport of the design methodologies we presented previouslycomposition refinement and conjunction
1) Contract Composition and System Integration Intu-itively the composition operator supports component-baseddesign and in general horizontal processes The compositionoperator that we denote by the symbol times is a partial functionon components The composition is defined with respect to acomposability criterion where two components M and M prime
are composable if their variable types match Composabilityis a syntactic property on pairs of components that definesconditions under which the two components can interactComposition times must be both associative and commutative inorder to guarantee that different composable components maybe assembled together in any order
Consider the component M2 defined as follows
M2
variables
inputs x
outputs y
types x y isin Rbehaviors y = ex
The component M2 computes the value of the output variabley as the exponential function of the input variable x M1 andM2 are they are composable since both common variables xand y have the same type x is an input variable to both M1
and M2 and the output variable y of M2 is fed as an input toM1 It follows that their composition M1 timesM2 has a singleinput variable x and computes the output z as a function ofx that is z = xex
Now consider component M prime2 that consists of an inputvariable x and an output variable z both of type real wherez = abs(x)
M prime2
variables
inputs x
outputs z
types x z isin Rbehaviors z = abs(x)
The component M prime2 is not composable with M1 becausethe two components share the same output variable z Theircomposition is illegal as it would result in conflicting rulesfor updating z
We now lift the above concepts to contracts The compo-sition operator between two contracts denoted by otimes shallbe a partial function on contracts involving a more subtlecompatibility criterion Two contracts C and Cprime are compatibleif their variable types match and if there exists an environmentin which the two contracts properly interact The resultingcomposition C otimes Cprime should specify through its assumptions
this set of environments By doing so the resulting contractwill expose how it should be used Unlike component com-posability contract compatibility is a combined syntactic andsemantic property
Let us formalize this For C a contract let AC and GC beits assumptions and guarantees and define
GC1otimesC2 = GC1andGC2
AC1otimesC2 = max
A∣∣∣∣∣∣AandGC2rArrAC1andAandGC1rArrAC2
(1)
where ldquomaxrdquo refers to the order of predicates by implica-tion thus AC1otimesC2 is the weakest assumption such that thetwo referred implications hold Thus this overall assumptionwill ensure that when put in the context of a componentimplementing the second contract then the assumption ofthe first contract will be met and vice-versa Since the twoassumptions were ensuring consistency for each contract theoverall assumption will ensure that the resulting compositionis consistent This definition of the contract compositiontherefore meets our previously stated requirements The twocontracts C1 and C2 are called compatible if the assumptioncomputed as in (1) differs from F the ldquo falserdquo predicate
Consider contracts C2 and Cprime2 that we define as follows
C2
variables
inputs u
outputs x
types u x isin Rassumptions T
guarantees x gt u
Cprime2
variables
inputs v
outputs y
types v y isin Rassumptions T
guarantees y = minusv
C2 specifies components that for any input value u generatesome output x such that x gt u and Cprime2 specifies componentsthat generate the value of the output variable y as functiony = minusv of the input v Observe that both C2 and Cprime2 areconsistent A simple inspection shows that C1 and C2 can becomposed and their composition yields
C1 otimes C2
variables
inputs u y
outputs x z
types x y u z isin Rassumptions y 6= 0
guarantees x gt u and z = xy
C1 and Cprime2 can also be composed and their composition yields
C1 otimes Cprime2
variables
inputs v x
outputs y z
types v x y z isin Rassumptions v 6= 0
guarantees y = minusv and z = xyRR ndeg 8147
Contracts for System Design 18
Both compositions possess a non-empty assumption (observealso that they are both free of exception) reflecting that thetwo pairs (C1 C2) and (C1 Cprime2) are compatible
In our example we require that compositions C1otimes(C2otimesC3)and (C1 otimes C2) otimes C3 result in equivalent contracts as well ascompositions C1otimesC2 and C2otimesC1 thus providing support forincremental system integration
A quotient operation can be defined that is dual to thecomposition operation Given a system-wide contract C anda contract C1 that specifies pre-existing components and theirinteractions the quotient operation CC1 defines the part ofthe system-wide contract that still needs to be implementedIt formalizes the practice of ldquopatchingrdquo a design to make itbehave according to another contract
2) Contract Refinement and Independent DevelopmentIn all vertical design processes the notions of abstractionand refinement play a central role The concept of contractrefinement must ensure the following if contract Cprime refinescontract C then any implementation of Cprime should 1) implementC and 2) be able to operate in any environment for C Hencethe following definition for refinement pre-order betweencontracts we say that the contract Cprime refines the contract C ifECprime supe EC andMCprime subeMC Since is a pre-order refinementis a transitive relation For our current series of examples andusing previous notations Cprime C amounts to requiring that 1AC implies ACprime and 2 ACprimerArrGCprime implies ACrArrGC
In Figure 4 we start with the contract C1 that representsthe general system-wide requirements We decompose theserequirements into requirements of three subsystems resultingin three contracts C11 C12 and C13 with the property thatC11otimesC12otimesC13 C1 Now these three contracts can be handedto different design teams and refined further independentlyIn particular C12 is further decomposed into contracts C121
and C122 such that C121 otimes C122 C12 and similarly C13 isfurther decomposed into contracts C131 and C132 such thatC131 otimes C132 C13
For all contracts C1 C2 Cprime1 and Cprime2 if C1 is compatible withC2 and Cprime1 C1 and Cprime2 C2 then Cprime1 is compatible with Cprime2and Cprime1 otimes Cprime2 C1 otimes C2
We now give a concrete example where we start withvery abstract requirements for a component that implementsa function z = xex Consider contracts Cprimeprime1 and Cprimeprime2 that wedefine as follows
Cprimeprime1
variables
inputs y
outputs z
types y z isin Rassumptions y 6= 0
guarantees z isin R
Cprimeprime2
variables
inputs x
outputs y
types x y isin Rassumptions T
guarantees y gt 0
The contract Cprimeprime1 formalizes the most crude and abstractrequirements for a divider It requires that the denominatorvalue (input variable y) is not equal to 0 and only ensuresthat the output value of z is any real Note that the contractCprimeprime1 does not declare the nominator input variable x Thecontract Cprimeprime2 specifies components that have an input variablex and an output variable of type y The only requirement onthe behavior of Cprimeprime2 is that y is strictly greater than 0 Thecomposition Cprimeprime1 otimes Cprimeprime2 is well defined The contract C1 refinesCprimeprime1 since it allows more inputs (the nominator input variable x)and restricts the behavior of the output variable z by definingits behavior as the division xy It follows that C1 is alsocompatible with Cprimeprime2 and that C1 otimes Cprimeprime2 Cprimeprime1 otimes Cprimeprime2 Finally wehave that M1 and M2 are implementations of their respectivecontracts It follows that M1 timesM2 implements C1 otimes Cprimeprime2
3) Contract Conjunction and Viewpoint Fusion We nowintroduce the conjunction operator between contracts denotedby the symbol and Conjunction is complementary to composi-tion
1) In the early stages of design the system-level speci-fication consists of a requirements document that is aconjunction of requirements
2) Full specification of a component can be a conjunctionof multiple viewpoints each covering a specific (func-tional timing safety etc) aspect of the intended designand specified by an individual contract see Figure 4 foran illustration
3) Conjunction supports reuse of a component in differentparts of a design see Figure 5 for an illustration
We state the desired properties of the conjunction operatoras follows Let C1 and C2 be two contracts If C1 and C2 areshared refinable then C1 andC2 C1 and C1 andC2 C2 and forall contracts C if C C1 and C C2 then C C1 and C2
To illustrate the conjunction operator we consider a contractCT1 that specifies the timing behavior associated with C1 Forthis contract we introduce additional ports that allow us tospecify the arrival time of each signal
CT1
variables
inputs tx ty
outputs tz
types tx ty tz isin R+
assumptions Tguarantees tzlemax(tx ty) + 1
The contract CT1 is shared refinable with C1 Their conjunctionC1 and CT1 yields a contract that guarantees in addition to C1itself a latency with bound 1 (say in ms) for it Becausethere are no assumptions this timing contract specifies thesame latency bound also for handling the illegal input y = 0In fact the contract says more because it does not mentionthe input y it assumes any value of y is acceptable Asa result the conjunction inherits the weakest T assumptionof the timing contract and cancels the assumption of C1This however is clearly not the intent since the timingcontract is not concerned with the values of the signals andis a manifestation of the weakness of this simple contract
RR ndeg 8147
Contracts for System Design 19
framework in dealing with contracts with different alphabetsof ports and variables We will further explain this aspect andshow how to address this problem in Section VII For themoment we can temporarily fix the problem by introducing yin the interface of the contract and use it in the assumptionsas in the following contract CT2
CT2
variables
inputs y tx ty
outputs tz
types y isin R tx ty tz isin R+
assumptions y 6=0guarantees tzlemax(tx ty) + 1
Note that this timing contract does not specify any bound forhandling the illegal input y = 0 since the promise is notenforced outside the assumptions
So far this example was extremely simple In particularit was stateless Extension of this kind of AssumeGuaranteecontracts to stateful contracts will be indeed fully developedin the coming sections and particularly in Section VII
C Contracts in requirement engineering
In this section we introduce a motivating example that isrepresentative of early requirements capturemdashthe specificationof a parking garage Its full development requires technicalmaterial that we introduce later and we thus defer it toSection XI This example illustrates the following features ofcontract based requirements capture namelybull Top-level system specification is by writing a require-
ments document Different formalisms may be used fordifferent kinds of requirements Here we illustrate thisby blending textual requirements written in constrainedEnglish (possibly obtained using boilerplates) with smallsized automata
bull The document itself is structured into chapters describingvarious aspects of the system such as how gates shouldbehave how payment should proceed plus some overallrules
bull Some requirements are under the responsibility of thesystem under development they contribute to specifyingthe guarantees that the system offers Other requirementsare not under the responsibility of the system underdevelopment they contribute to defining the assumptionsregarding the context in which the system should operateas specified
bull Requirements are written in constrained English languageor by using automata
We now begin with the top-level requirements The systemunder specification is a parking garage subject to paymentby the user At its most abstract level the requirementsdocument comprises the different chapters gate payment andsupervisor see Table III The gate chapter will collect thegeneric requirements regarding entry and exit gates Thesegeneric requirements will then be specialized for entry andexit gates respectively
Focus on the ldquogaterdquo chapter It consists of the three require-ments shown on Table III Requirement Rg1 is best described
gateRg1ldquovehicles shall not pass when gate is closedrdquo see Fig 7Rg2 after vehicle_pass vehicle_pass is forbiddenRg3 after gate_open gate_open is forbidden and
after gate_close gate_close is forbiddenpaymentsupervisor
Table IIITHE TOP-LEVEL SPECIFICATION WITH CHAPTER gate EXPANDED
REQUIREMENTS WRITTEN IN italics ARE ASSUMPTIONS UNDER WHICHgate SHOULD OPERATE
0
gate_close
1gate_opengate_close
vehicle_passgate_open
Figure 1 Requirement Rg1 specified as an io-automaton Prefix ldquordquoindicates an input and prefix ldquordquo indicates an output
by means of an io-automaton shown in Figure 1mdashwe providean informal textual explanation for it between quotes Supposethat some requirement says ldquogate_open never occursrdquo Thisis translated by having no mention of gate_open in thecorresponding io-automaton To express this ldquonegativerdquo factwe must keep track of the fact that gate_open belongs tothe alphabet of actions of the io-automaton Thus when per-forming the translation the explicit list of inputs and outputsshould be explicitly given To avoid such additional notationalburden we have cheated by omitting this unless necessaryThe other two requirements are written using constrainednatural language which can be seen as a boilerplate styleof specification Prefix ldquordquo indicates an input and prefix ldquordquoindicates an output
The first two requirements are not under the responsibilityof the system since they rather concern the car driver Thus itdoes not make sense to include them as part of the guaranteesoffered by the system Should we remove them This wouldbe problematic If drivers behave the wrong way unexpectedthings can occur for sure The conclusion is that 1) we shouldkeep requirements Rg1 and Rg2 and 2) we should handlethem differently than Rg3 which is a guarantee offered by thesystem Indeed Rg1 and Rg2 are assumptions under whichthe gate operates as guaranteed We take the convention thatassumptions are written in italics
So far we have specified gate as a list of requirementsRequirement Rg1 specified as an io-automaton can be con-sidered formal Requirements Rg2 and Rg3 are formulatedin constrained natural language and are ready for subsequentformalization eg as io-automata Are we done Not yetWe need to give a formal meaning to what it means to havea collection of requirements and what it means to distinguishassumptions from guarantees Similarly we must give a formalmeaning to what it means to combine different chapters of arequirements document Intuitively all requirements must be
RR ndeg 8147
Contracts for System Design 20
met for a chapter to be satisfied and similarly all chaptersmust be satisfied for the whole specification to be correctlyimplemented Thus we propose to write the top-level specifi-cation C as the following conjunction
C = Cgate and Cpayment and Csupervisor
As we said formally defining what conjunction and is requirestechnical material that is developed later in this paper Thefollowing issues arise regarding this top-level specificationFirst of all since a conjunction operator is involved in theconstruction of C there is a risk of formulating contradictingrequirementsmdashthis is referred to as the issue of consistencySecond are we sure that the top-level specification C iscomplete ie precise enough to rule out undesirable imple-mentations One good way of checking for completeness is tobe able to execute or simulate this top-level specification CWe provide answers to all these issues in Section XI wherethis example is fully developed
request enter
ticket issue
entry gate open
entry gate closeEntryGate
vehicle enter
vehicle exit
exit ticket insert ExitGateexit gate open
exit gate close
ticket insert payment
coin insert paymentPaymentMachine exit ticket issue
Figure 2 System architecture as specified by the designer
Having the top-level specification C at hand the designerthen specifies an architecture ldquoagrave la SysMLrdquo as shown onFigure 2 Some comments are in order regarding this archi-tecture The considered instance of a parking garage consistsof one entry gate one exit gate and one payment machineCompare with the top-level specification of Table III Thelatter comprises a generic gate a payment machine and asupervisor each one with its set of requirements In contrastthe architecture of Figure 2 involves no supervisor Thesupervisor is meant to be distributed among the two gatesThe architecture of Figure 2 seems to be very loosely coupledFirst the PaymentMachine seems to be totally independent Infact the ticket that is inserted in the exit gate must coincidewith the one issued by the PaymentMachine It turns out thatthis reflects a missing assumption regarding the environmentof the system (namely the user of the parking) Then thetwo gates seem to have the shared input ldquovehicle exitrdquo astheir only interaction But this shared input is involved in
requirement Rs3 which forbids the entry if the parking isfull
The next step in the design consists in subcontractingthe development of each of the three sub-systems of thearchitecture of Figure 2 This amounts to specifying threesubcontracts CEntryGate CExitGate and CPaymentMachinesuch that
CEntryGate otimes CExitGate otimes CPaymentMachine C (2)
The symbol in (2) means that any implementation of theleft hand side is also a valid implementation of the top-level C Then the contract composition operator otimes ensuresthat each supplier can develop its sub-system based on itsown sub-contract only and still integrating the so designedsub-systems yields a correct implementation of the top-levelspecification Once the three sub-contracts are found checkingthat they satisfy (2) requires formalizing the contract compo-sition operator otimes Furthermore guessing such sub-contractsis a difficult task In our development of this example inSection XI we propose adequate answers to these issues
D Contract Support for Design Methodologies
The three operators introduced above fit naturally in anydesign methodology developed so far In particular contractcomposition and conjunction supports horizontal processesand contract refinement supports vertical processes We showhow this is so by first analyzing the use of contract conjunc-tion for requirement management then of composition andrefinement for design chain management re-use and indepen-dent development to close with conjunction composition andrefinement for deployment and mapping
1) Supporting open systems When designing componentsfor reuse their context of use is not fully known in advanceWe thus need a specification of components exposing boththe guarantees offered by the component and the assumptionson its possible context of usemdashits ldquoenvironmentrdquo This stateswhat contracts should be
2) Managing Requirements and Fusing Viewpoints Re-ferring to Section III-C complex systems involve a numberof viewpoints (or aspects) that are generally developed bydifferent teams using different skills As a result there is aneed for fusing these viewpoints in a mathematically soundway Structuring requirements or specifications is a desirableobjective at each step of the design Finally we must formal-ize some key properties that must be evidenced as part ofcertification processes
This process is illustrated in Figure 3 In this figure weshow three viewpoints the behavioral viewpoint where thefunctions are specified the timing viewpoint where timingbudgets are allocated to the different activities and the safetyviewpoint where fault propagation effect and handling arespecified Typically different viewpoints are developed bydifferent teams using different frameworks and tools Devel-opment of each viewpoint is performed under assumptionsregarding its context of use including the other viewpoints To
RR ndeg 8147
Contracts for System Design 21
VIEWPOINT VIEWPOINT VIEWPOINTBEHAVIORAL TIMING SAFETY
is a conjunctionevery contract
C =and
i Ci
CB1 CB2 CT CS1 CS2
CB1 and CB2 and CT and CS1 and CS2
Figure 3 Conjunction of requirements and viewpoints in top-level design
get the full system specification the different viewpoints mustbe fused As the notations of Figure 3 suggest conjunctionis used for fusing viewpoints thus reflecting that the systemunder design must satisfy all viewpoints Similarly eachviewpoint is itself a conjunction of requirements seen as theldquoatomicrdquo contractsmdashall requirements must be met
3) Design Chain Management Re-using and IndependentDevelopment In Figure 4 we show three successive stages ofthe design At the top level sits the overall system specificationas developed by the OEM As an example it can be obtained asthe conjunction of several viewpoints as illustrated on Figure 3
is delegated forimplementation by a supplier
is delegated forimplementation by a supplier
C11 otimes (C121 otimes C122)otimes (C131 otimes C132)
C11
C12
C13
C11
C121 C122 C131 C132
C121 otimes C122 C131 otimes C132
C11 otimes C12 otimes C13
C1
is refined by the OEM
Figure 4 Stepwise refinement
As a first design step the OEM decomposes its system intoan architecture made of three sub-systems for independentdevelopment by (possibly different) suppliers For each ofthese sub-systems a contract C1j j = 1 2 3 is developedA contract composition denoted by the symbol ldquootimesrdquo
C11 otimes C12 otimes C13
mirrors the composition of sub-systems that defines the archi-tecture For our method to support independent development
this contract composition operator must satisfy the following
if designs are independently performed for eachsub-contract C1j j = 1 2 3 then integratingthese sub-systems yields an implementation thatsatisfies the composed contract C11 otimes C12 otimes C13
(3)
This contract composition must then be qualified against thetop-level contract C1 This qualification must ensure that anydevelopment compliant with C11 otimes C12 otimes C13 should alsocomply with C1 To ensure substitutability in any legal contextcompliance concerns both how the system behaves and whatits allowed contexts of use are any legal context for C1 shouldbe also legal for C11otimesC12otimesC13 and under any legal contextthe integrated system should behave as specified by C1 This isformalized as the refinement relation denoted by the symbol
C11 otimes C12 otimes C13 C1 (4)
Overall the satisfaction of (4) guarantees the correctness ofthis first design step performed by the OEM
Obtaining the three sub-contracts C11 C12 and C13 is the artof the designer based on architectural considerations Contracttheories however offer the following services to the designerbull The formalization of parallel composition and refinement
for contracts allows the designer to firmly assess whether(4) holds for the decomposition step or not
bull In passing the compatibility of the three sub-contractsC11 C12 and C13 can be formally checked
bull Using contracts as a mean to communicate specificationsto suppliers guarantees that the information provided tothe supplier is self-contained the supplier has all theneeded information to develop its sub-system in a waythat subsequent system integration will be correct
Each supplier can then proceed with the independent devel-opment of the sub-system it is responsible for For instance asupplier may reproduce the above procedure
Alternatively this supplier can develop some sub-systemsby reusing off-the-shelf components For example contractC121 would be checked against the interface specification of apre-defined component M121 available from a library and thefollowing would have to be verified does component M121
satisfy C121 In this context shared implementations are ofinterest This is illustrated on Figure 5 where the same off-the-shelf component implements the two referred contracts
To conclude on this analysis the two notions of refinementdenoted by the symbol ldquordquo and composition of contractsdenoted by the symbol ldquootimesrdquo are key Condition (3) ensuresindependent development holds
4) Deployment and Mapping Here we address a specificbut important point related to Contribution 1 At some pointin the design of the system specifications must be realized byusing resources Resources can be pre-defined sub-systems orcomponents or they can consist of computing resources com-prising computing units and communication media (networksbusses and protocols) This methodology was advocated and
RR ndeg 8147
Contracts for System Design 22
C11
C121 C122 C131 C132
C11 otimes (C121 otimes C122)otimes (C131 otimes C132)
C121 otimes C122 C131 otimes C132
C122 and C132
Figure 5 Conjunction for component reuse
systematically exploited in Platform Based Design [171] orPLM-centric design see footnote 4 in Section II How sucha step can be captured in contract based design is explainednext
When deploying an application over a computing plat-form in addition to the functional viewpoint non-functionalviewpoints (safety timing energy and possibly other) areof importance as well The safety viewpoint is concernedwith the risk of primary faults and failures how they couldpropagate throughout the system and what the consequencesfor the resilience of the overall system would be in termsof failure probability The timing viewpoint collects timingrequirements regarding the application (requirements on la-tencies throughput jitter and schedulability) The effectivesatisfaction of safety or timing viewpoints by a considereddeployment depends on 1) the supporting execution platformand 2) the mapping of the application to this executionplatform We thus need to formalize what ldquomappingrdquo meansThe reader is referred to Figure 6 for the following discussion
M4M3
M5M6
M1
M2
M3
M1
M4
M2
M5
M6x34
xd63 xo
63
x34
C2 C1
C3
P
C
xo63
xd63
Figure 6 Mapping the application to the execution platform as C and P
Suppose one has a virtual model of the execution platform
as an architecture composed of several components Suchcomponents would in the context of Figure 6 consist of adescription of the available computing units a descriptionof the bus protocol and frame structure andor a library ofRTOS (Real-Time Operating System) services The resultingcomponents are enhanced with timing information (for thetiming viewpoint) and fault propagation information (for thesafety viewpoint) Application contracts are attached to thedifferent sub-systems or components as described on the toppart of the figure Similarly platform contracts are attachedto the different sub-systems or components of the executionplatform as described on the bottom part of the figureAccordingly we assume
C =andk
(otimesiisinIk Cik
)P =
otimesjisinJ
(and`isinLj
Pj`)
where
bull The overall platform contract P decomposes asotimes
jisinJ Pj(eg the bus and the different computing units inFigure 6) where each Pj is the conjunction of its differentviewpoints (the function what can be computed and theassociated performance how much time it takes and howmuch energy it consumes)
bull The overall application contract is the conjunction ofits different viewpoints Ci with their own architecturaldecomposition
In Figure 6 we only show a single viewpoint29 and we assumethat distant communication between C2 and C3 has alreadybeen refined to a communication medium compliant with thecommunication resources offered by the execution platform
The mapping of the application over the architecture ismodeled by the conjunction CandP defined by the following setof synchronization tuples30 depicted in red in the Figure 6
bull The wire x34 linking M3 to M4 in the application issynchronized in the deployment P with the variablex34 of the left computing unit where x34 represents theoutput of the module implementing M3 and the input ofthe module implementing M4 And similarly for the wirelinking M5 to M6
bull In the deployment the wire x63 linking M6 to M3
must traverse the bus To capture this we first refinethe application architecture by distinguishing the originxo63 of this wire from its destination xd63 In the refinedapplication architecture we assume that xo63 and xd63 arerelated by some buffer of bounded size The deploymentis then captured by synchronizing xo63 with the output xo63
of the module implementing M6 in the right computingunit and by synchronizing xd63 with the input xd63 of themodule implementing M3 in the left computing unit
29Here we assume that the different application viewpoints are developedfor the whole application and then combined by conjunctionmdashthis is just amethodological proposal we could proceed differently
30In in a synchronization tuple both occurrences and values of the differentelements are unified
RR ndeg 8147
Contracts for System Design 23
This formalizes the deployment as the conjunction
C and P =[and
k
(otimesiisinIk Cik
) ]and [otimesjisinJ(and
`isinLjPj`) ]
ensuring that C and P refines C by construction There ishowever no free lunch The formula C and P expressing de-ployment involves a conjunction and is as such a possiblesource of inconsistencies If this happens then C and P cannotbe implemented Finding an execution platform P causingno inconsistency in C and P requires a good understanding ofthe application and its needs The more advanced techniquesdeveloped in Section XI provide assistance for this
Since C and P relates application and computing platformmdashwhich sit at different layers of the designmdashwe call suchcontracts vertical contracts Contracts that are not vertical aresometimes called horizontal in that they are meant to relatecomponents sitting at a same level of the design hierarchymdashapplication level or computing platform level or ECU (Elec-tronic Computing Unit) level
Techniques of mapping application to its execution platformthat are similar to the above one are used in the RT-Buildertool 31 and in the Metropolis platform [20] [80]
E Bibliographical note
Having collected the ldquorequirementsrdquo on contract theories itis now timely to confront these to the previous work referringto or related to the term ldquocontractrdquo
It is difficult to write a comprehensive bibliography onthe general aspects of contract based design The topic ismulti faceted and has been addressed by several communitiessoftware engineering language design system engineeringand formal methods in a broad sense We report here a partialand limited overview of how this paradigm has been tackledin these different communities While we do not claim beingexhaustive we hope that the reader will find her way to thedifferent literatures
Contracts in SW engineering This part of the biblio-graphical note was inspired by the report [168] Design byContract is a software engineering technique popularized byBertrand Meyer [139] [140] following earlier ideas fromFloyd-Hoare logic [169] [113] Floyd-Hoare logic assignsmeaning to sequential imperative programs in the form oftriples of assertions PCQ consisting of a preconditionon program states and inputs a command and a postcondi-tion on program states and outputs Meyerrsquos contracts weredeveloped for Object-Oriented programming They exposethe relationships between systems in terms of preconditionsand postconditions on operations and invariants on states Acontract on an operation asserts that given a state and inputswhich satisfy the precondition the operation will terminatein a state and will return a result that satisfy the postcondi-tion and respects any required invariant properties Contractscontribute to system substitutability Systems may be replacedby alternative systems or assemblies that offer the same or
31httpwwwgeensoftcomenarticlertbuilder
substitutable functionality with weaker or equivalent precon-ditions and strongerequivalent postconditions With the aimof addressing service oriented architectures Meyerrsquos contractswere proposed a multiple layering by Beugnard et al [37]The basic layer specifies operations their inputs outputs andpossible exceptions The behavior layer describes the abstractbehavior of operations in terms of their preconditions andpostconditions The third layer synchronisation correspondsto real-time scheduling of component interaction and messagepassing The fourth quality of service (QoS) level detailsnon-functional aspects of operations The contracts proposedby Beugnard et al are subscribed to prior to service invo-cation and may also be altered at runtime thus extendingthe use of contracts to Systems of Systems [141] So farcontracts consisting of prepostconditions naturally fit imper-ative sequential programming In situations where programsmay operate concurrently interference on shared variablescan occur RelyGuarantee rules [115] were thus added tointerface contracts Rely conditions state assumptions aboutany interference on shared variables during the execution ofoperations by the systemrsquos environment Guarantee conditionsstate obligations of the operation regarding shared variables
The concepts of interface and contract were subse-quently further developed in the Model Driven Engineering(MDE) [120] [172] [131] In this context interfaces aredescribed as part of the system architecture and comprisetyped ports parameters and attributes Contracts on interfacesare typically formulated in terms of constraints on the en-tities of components using the Object Constraint Language(OCL) [150] [180] Roughly speaking an OCL statementrefers to a context for the considered statement and expressesproperties to be satisfied by this context (eg if the context isa class a property might be an attribute) Arithmetic or set-theoretic operations can be used in expressing these propertiesThis method however does not account for functional andextra-functional properties of interfaces ie for behavior andperformance To account for behavior the classical approachin MDE consists in enriching components with methods thatcan be invoked from outside andor state machines Likewiseattributes on port methods have been used to represent non-functional requirements or provisions of a component [51]The effect of a method is made precise by the actual codethat is executed when calling this method The state machinedescription and the methods together provide directly animplementation for the component mdash actually several MDErelated tools such as GME and Rational Rose automaticallygenerate executable code from this specification [21] [132][161] The notion of refinement is replaced by the concept ofclass inheritance From a contract theory point of view thisapproach has several limitations Inheritance for instance isunable to cover aspects related to behavior refinement Noris it made precise what it means to take the conjunctionof interfaces which can only be approximated by multipleinheritance or to compose them
In a continuing effort since his joint work with W Dammon Life Sequence Charts (LSC) in 2000 [64] with its Play-
RR ndeg 8147
Contracts for System Design 24
Engine implementation [107] David Harel has developed theconcept of behavioral programming [108] [106] [109] whichputs in the forefront scenarios as a program developmentparadigmmdashnot just a specification formalism In behavioralprogramming b-threads generate a flow of events via anenhanced publishsubscribe protocol Each b-thread is a pro-cedure that runs in parallel to the other b-threads When ab-thread reaches a point that requires synchronization it waitsuntil all other b-threads reach synchronization points in theirown flow At synchronization points each b-thread specifiesthree sets of events requested events the thread proposes thatthese be considered for triggering and asks to be notifiedwhen any of them occurs waited-for events the thread doesnot request these but asks to be notified when any of themis triggered and blocked events the thread currently forbidstriggering any of these events When all b-threads are at asynchronization point an event is chosen (according to somepolicy) that is requested by at least one b-thread and is notblocked by any b-thread The selected event is then triggeredby resuming all the b-threads that either requested it or arewaiting for it This mechanism was implemented on top ofJava and LSCs The execution engine uses planning and modelchecking techniques to prevent the system from falling intodeadlock where all requested events are blocked Behavioralprogramming is incremental in that new threads can be addedto an existing program without the need for making any changeto this original program new deadlocks that are created bydoing so are pruned away by the execution engine Whilebehavioral programming cannot be seen as a paradigm ofcontracts it shares with contracts the objectives of incrementaldesign and declarative style of specification
Our focusmdashcontracts for systems and CPS The frame-works of contracts developed in the area of Software En-gineering have established as useful paradigms for compo-nent based software system development In this paper wetarget the wider area of computer controlled systems morerecently referred to as Cyber-Physical systems where reactivesystems [104] [110] [100] [136] are encountered that issystems that continuously interact with some environmentas opposed to transformational systems [100] considered inObject-Oriented programming For reactive systems model-based development (MBD) is generally accepted as a keyenabler due to its capabilities to support early validationand virtual system integration MBD-inspired design lan-guages and tools include SysML [149] or AADL [152] forsystem level modeling Modelica [93] for physical systemmodeling Matlab-Simulink [118] for control-law design andScade [144] [32] and TargetLink for detailed software designUML-related standardisation efforts in this area also includethe MARTE UML32 profile for real-time systems Contracttheories for model based development were considered inthe community of formal verification They were initiallydeveloped as specification formalisms able to refuse certaininputs from the environment Dill proposed asynchronous
32 wwwomgmarteorg
trace structures with failure behaviors [81] A trace structureis a representation of a component or interface with two setsof behaviors The set of successes are those behaviors whichare acceptable and guaranteed by the component Converselythe set of failures are behaviors which drive the componentinto unacceptable states and are therefore refused This workfocuses primarily on the problem of checking refinement anddoes not explore further the potentials of the formalism froma methodological point of view The work by Dill was laterextended by Wolf in the direction of synchronous systemsNegulescu later generalizes the algebra to Process Spaceswhich abstract away the specifics of the behaviors and derivesnew composition operators [143] This particular abstractiontechnique was earlier introduced by Burch with Trace Algebrasto construct conservative approximations [47] and later gen-eralized by Passerone and Burch [154] to study generic tracestructures with failure behaviors and to formalize the problemof computing the quotient (there called mirror) [153] Thispaper aims at proposing for model based design of systemsand CPS a new vista on contracts In the next section wepropose an all encompassing meta theory of contracts
V A MATHEMATICAL META-THEORY OF CONTRACTS
In software engineering meta-models are ldquomodels of mod-elsrdquo ie formal ways of specifying a certain family ofmodels Similarly we call here meta-theory a way to specifya particular family of theories In this section we proposea meta-theory of contracts This meta-theory is summarizedin Table IV It comes as a few primitive concepts on topof which derived concepts can be built A number of keyproperties can be proved about the resulting frameworkThese properties demonstrate that contracts are a convenientparadigm to support incremental development and independentimplementability in system design The meta-theory will serveas a benchmark for our subsequent review of concrete contracttheories
The meta-theory we develop here is novel There are veryfew attempts of that kind In fact the only ones we are awareof are the recent works by Bauer et al [22] and Chen et al [59]which follow a different (and complementary) approach Thediscussion of this work is deferred to the bibliographicalsection V-H
A Components and their composition
To introduce our meta-theory we start from a universe Mof possible components each denoted by the symbol M orE and a universe of their abstractions or contracts eachdenoted by the symbol C Our meta-theory does not presumeany particular modeling style neither for components nor forcontractsmdashwe have seen in Section IV an example of a (verysimple) framework for static systems More generally someframeworks may represent components and contracts with setsof discrete time or even continuous time traces other theoriesuse logics or state-based models of various kinds and so on
We assume a composition M1 timesM2 acting on pairs ofcomponents Component composition times is partially not to-
RR ndeg 8147
Contracts for System Design 25
Concept Definition and generic properties What depends on the particulartheory of contracts
Primitive
Component Components are denoted by M they can be open or closed How components are specified
Composabilityof components A type property on pairs of components (M1M2) How this type property is defined
Compositionof components
M1timesM2 is well defined if and only if M1 and M2 are composableIt is required that times is associative and commutative The definition of the composition
Environment An environment for component M is a componentE such that EtimesM is defined and closed
Derived
Contract A contract is a pair C = (EC MC ) where MC is a subsetof components and EC a subset of legal environments
Which family C of contractscan be expressed andhow they are expressedunless otherwise specifiedquantifying is implicitly over C isin C
Consistency C is consistent iff it has at least one component MC 6= empty How consistency is checked
Compatibility C is compatible iff it has at least one environment EC 6= empty How compatibility is checked
Implementation M |=M C if and only if M isinMCE |=E C if and only if E isinEC
How implementation is checked
Refinement Cprime C iff ECprime supe EC and MCprime subeMC Property 1 holds How refinement is checked
GLB andLUBof contracts
C1andC2 = Greatest Lower Bound (GLB) for we assume GLB existC1orC2 = Least Upper Bound (LUB) for we assume LUB exist
Property 2 holds
Whether and howGLB and LUB can beexpressed and computed
Compositionof contracts
C1otimesC2 is defined if M1 |=M C1M2 |=M C2
rArr (M1M2) composable
C1otimesC2 =andC
∣∣∣∣∣∣M1 |=M C1 and M2 |=M C2 and E |=E C
dArrM1 timesM2 |=M C and EtimesM2 |=E C1 and EtimesM1 |=E C2
Assumption 1 is in force Properties 3 4 and 5 holdSay that C1 and C2 are compatible if so is C1otimesC2
How composition isexpressed and computed
Quotient C1C2 =or C | C otimes C2 C1 Property 6 holds How quotient is
expressed and computed
Table IVSummary of the meta-theory of contracts We first list primitive concepts and then derived concepts introduced by the meta-theory
tally defined Two components that can be composed arecalled composable Composability of components is meantto be a typing property In order to guarantee that differentcomposable components may be assembled together in anyorder it is required that component composition times is asso-ciative and commutative Components that exhibit no meansfor interacting with the outside world are called closed othercomponents are open An environment for a component Mis another component E composable with M and such thatM times E is closed
B Contracts
In our primer of Section IV we have highlighted the im-portance of the legal environments associated with contractsfor which an implementation will operate satisfactorily At theabstract level of the meta-theory we make this explicit next
Definition 1 A contract is a pair C = (EC MC ) where
bull MC subeM is the set of implementations of C andbull EC subeM is the set of environments of C
For any pair (EM) isin EC times MC E is an environmentfor M Hence MtimesE must be well defined and closed Acontract possessing no implementation is called inconsistentA contract possessing no environment is called incompatibleWrite
M |=M C and E |=E C
to express that M isinMC and E isin EC respectivelyIn concrete theories of contracts both components and con-tracts are described in some finite (preferably concise) wayIn turn it is not true that every set Mprime subeM of componentscan be represented as Mprime = MC for some contract C andsimilarly for sets of environments To highlight this
we assume a family C of expressible contracts (5)
Only contracts belonging to this family can be consideredThis is made explicit in Table IV
C Refinement and conjunctionTo support independent implementability the concept of
contract refinement must ensure the following if contract Cprime
RR ndeg 8147
Contracts for System Design 26
refines contract C then any implementation of Cprime should 1)implement C and 2) be able to operate in any environment forC Hence the following definition for refinement preorder between contracts Cprime refines C written Cprime C if and onlyif MCprime sube MC and ECprime supe EC As a direct consequence thefollowing property holds which justifies the use of the termldquorefinementrdquo for this relation
Property 1 (refinement)1) Any implementation of Cprime is an implementation of C
M |=M Cprime rArrM |=M C and2) Any environment of C is an environment of Cprime
E |=E C rArr E |=E CprimeThe conjunction of contracts C1 and C2 written C1 and C2 isthe greatest lower bound (GLB) of these two contracts withrespect to refinement ordermdashwe assume such a GLB existsThe intent is to define this conjunction as the intersection ofsets of implementations and the union of sets of environmentsHowever due to (5) not every set of components is thecharacteristic set of a contract The best approximation consistsin taking the greatest lower bound for the refinement relationThe following immediate properties hold
Property 2 (shared refinement)1) Any contract that refines C1 and C2 also refines C1 and C2
Any implementation of C1 and C2 is a shared implementa-tion of C1 and C2 Any environment of C1 or C2 is anenvironment of C1 and C2
2) For C sube C a subset of contractsandC is compatible if
and only if there exists a compatible C isin C
The conjunction operation formalizes the intuitive notion of aldquoset of contractsrdquo or a ldquoset of requirementsrdquo
D Contract composition
The objective of contract composition is to ensure that1) composing respective implementations of each contract
yields an implementation for the composition and2) composing an environment for the resulting composition
with an implementation for C2 yields an environment forC1 and vice-versa
These two properties are essential in supporting top-downdesign by successive decompositions and refinements of con-tracts Contract composition C1 otimes C2 is thus defined on topof component composition as indicated in Table IV with thefollowing assumption in force throughout this meta-theory
Assumption 1 The following condition holds
C1 otimes C2 isin CC1otimesC2
(Note that this assumption is non trivial since it is not true foran arbitrary set C sube C that
andCisinC C isin C) The condition
for C1 otimes C2 to be defined is that every pair (M1M2) ofrespective implementations is composable so that M1 timesM2
is well definedmdashrecall that component composability is atyping property Consequently if E is an environment forM1timesM2 E is composable with both M1 and M2 and EtimesM1
is an environment for M2 and vice-versa Referring to the
formula defining C1 otimes C2 denote by CC1otimesC2 sube C the set ofcontracts specified in the brackets The following lemma willbe instrumental
Lemma 1 Let four contracts be such that Cprime1 C1Cprime2 C2 and C1 otimes C2 is well defined Then so is Cprime1 otimes Cprime2and CCprime1otimesCprime2 supe CC1otimesC2
Proof Since C1otimesC2 is well defined it follows that every pair(M1M2) of respective implementations of these contracts is acomposable pair of components Hence Cprime1otimesCprime2 is well definedaccording to the formula of Table IV Next since Cprime1 C1 andCprime2 C2 and using Assumption 1 M1 |=M Cprime1 and M2 |=M Cprime2implies M1 |=M C1 and M2 |=M C2 similarly E timesM2 |=E C1and EtimesM1 |=E C2 implies EtimesM2 |=E Cprime1 and EtimesM1 |=E Cprime2Therefore replacing in the big brackets defining the contractcomposition C1 by Cprime1 and C2 by Cprime2 can only increase the setCC1otimesC2 2
To conform to the usage we say that C1 and C2 arecompatible contracts if their composition C1 otimes C2 is definedand compatible in the sense of Table IV The followingproperties are a direct corollary of Lemma 1
Property 3 (independent implementability) For all con-tracts C1 C2 Cprime1 and Cprime2 if
1) C1 is compatible with C22) Cprime1 C1 and Cprime2 C2 hold
then Cprime1 is compatible with Cprime2 and Cprime1 otimes Cprime2 C1 otimes C2
Thus compatible contracts can be independently refined Thisproperty holds in particular if Cprime1 and Cprime2 are singletons
Corollary 1 Compatible contracts can be independentlyimplemented
Property 3 is fundamental particularly in top-down designTop-down incremental design consists in iteratively decom-posing a system-level contract C into sub-system contractsCi i isin I for further independent development To ensure thatindependent development will not lead to integration problemsit is enough to verify that
otimesiisinI Ci C We insist that since
contracts are purposely abstract and subsystems are not manythe composition of contracts Ci will not typically result in stateexplosion33
The following property is essential as it states that contractcomposition can be performed in any order and changesin architecture (captured by changes in parenthesizing) areallowed
Property 4 (associativity and commutativity) For all con-tracts C1 C2 C3 and C4 if C1 and C2 are compatible C3 andC4 are compatible and C1otimesC2 is compatible with C3otimesC4 thenC1 is compatible with C3 C2 is compatible with C4 C1 otimes C3is compatible with C2 otimes C4 and
(C1 otimes C2)otimes (C3 otimes C4) = (C1 otimes C3)otimes (C2 otimes C4) (6)
33 This is unlike in compositional verification where timesiisinIMi |=M Pis to be checked where Mi are detailed implementations and P is aproperty In this case the composition timesiisinIMi typically gives raise to stateexplosion Techniques have thus been proposed to verify such properties inan incremental way [176] [62] [98] [1] [121]
RR ndeg 8147
Contracts for System Design 27
Proof To shorten notations write C12 instead of C1 otimesC2 andsimilarly for any subset of 1 2 3 4 By Assumption 1 andthe associativity and commutativity of component composi-tion C1234 is characterized by the following two propertieswhere index i ranges over the set 1 4
Mi |=M Ci rArr M1times timesM4 |=M C1234
E |=E C1234 rArr Etimes (timesj 6=iMj) |=E Ci(7)
Observe that (7) is fully symmetric which proves (6) Nextusing the assumptions regarding compatibility we derive theexistence of at least one environment E satisfying the premiseof the second implication of (7) Since (7) is fully symmetricthis proves the conclusions of Property 4 regarding compati-bility 2
Property 5 (distributivity) If the following contract compo-sitions are all well defined then the following holds
[(C11 and C21)otimes (C12 and C22)] [(C11 otimes C12) and (C21 otimes C22)] (8)
Proof By Lemma 1 C(C11andC21)otimes(C12andC22) supe CC11otimesC12 Taking the GLB of these two sets thus yields[(C11 and C21)otimes (C12 and C22)] (C11 otimes C12) and similarlyfor (C21 otimes C22) Thus (8) follows 2
The use of distributivity is best illustrated in the followingcontext Suppose the system under design decomposes intotwo sub-systems labeled 1 and 2 and each subsystem hastwo viewpoints associated with it labeled by another indexwith values 1 or 2 Contract (C11 and C21) is then the contractassociated with sub-system 1 and similarly for sub-system 2Thus the left hand side of (8) specifies the set of imple-mentations obtained by first implementing each sub-systemindependently and then composing these implementationsProperty 5 states that by doing so we obtain an implemen-tation of the overall contract obtained by first getting thetwo global viewpoints (C11 otimes C12) and (C21 otimes C22) andthen taking their conjunction This property supports inde-pendent implementation for specifications involving multipleviewpoints Observe that only refinement not equality holdsin (8)
E Quotient
The quotient of two contracts is defined in Table IV It isthe adjoint of the product operation otimes in that C1C2 is themost general context C in which C2 refines C1 It formalizesthe practice of ldquopatchingrdquo a component to make it behavingaccording to another specification From its definition inTable IV we deduce the following property
Property 6 (quotient) The following holds
C C1C2 hArr C otimes C2 C1
Proof Immediate from the definition 2
F Discussion
By inspecting Table IV the different notions can be classi-fied into the following two categories
bull Primitive notions that are assumed by the meta-theoryThis category comprises components component com-posability and composition
bull Derived notions comprise contract refinement conjunc-tion composition and quotient consistency and com-patibility for contracts The derived notions follow fromthe primitive ones through set theoretic non effectivedefinitions
The meta-theory offers by itself a number of fundamentalproperties that underpin incremental development and inde-pendent implementability Concrete theories will offer defini-tions for the primitive notions as well as effective means toimplement (or sometimes approximate) the derived notionsObservers and then abstract interpretation we develop nextprovide generic approaches to recover effectiveness
G Observers
Notion Observer
C = (EC MC )(bEC b
MC)
C = C1andC2 bEC = bE
C1 or bEC2 b
MC = bM
C1 and bMC2
C = C1orC2 bEC = bE
C1 and bEC2 b
MC = bM
C1 or bMC2
C = C1otimesC2bEC(E) =
bMC1 (M1) and bM
C2 (M2)
dArrbEC2 (EtimesM1) and bE
C1 (EtimesM2)
bMC(M1 timesM2) = bM
C1 (M1) and bMC2 (M2)
Table VMirroring the algebra of contracts with observers
A typical obstacle in getting finite (or more generallyeffective) representations of contracts is the occurrence ofinfinite data types and functions having infinite domains Thesecan be dealt with by using observers which originate from thebasic notion of test for programs
Definition 2 Let C be a contract An observer for Cis a pair (bE
C bMC) of non-deterministic boolean functions
M 7rarr F T called verdicts such that
bEC(M) outputs F =rArr M 6isin ECbMC(M) outputs F =rArr M 6isin MC
(9)
The functions M 7rarr bEC(M) and M 7rarr bM
C(M) being bothnon-deterministic accounts for the fact that the outcome of atest depends on the stimuli from the environment and possiblyresults from internal non-determinism of the tested componentitself Note the single-sided implication in (9) which reflectsthat tests only provide semi-decisions
Relations and operations of the meta-theory can be mirroredby relations and operations on observers as explained inTable Vmdashwe omit the formulas for the quotient as semi-effectiveness of testing makes it useless Despite GLB andLUB can be mirrored using the formulas of the table nothingcan be said about the relationship of observers for contractsbased on the fact that they are in a refinement ordering Dually
RR ndeg 8147
Contracts for System Design 28
nothing can be inferred in terms of their refinement fromsuch a relationship between the observers Still the followingweaker result holds which justifies how GLB and LUB arerepresented using observers in Table V
Lemma 2 Let (bEC b
MC) be an observer for C and let Cprime C
Then any pair (bE bM) satisfying bE ge bEC and bM le bM
C is anobserver for CprimeThe following immediate results hold regarding consistencyand compatibility
Lemma 31) If bE
C(E) outputs F for all tested environment E then Cis incompatible
2) If bMC(M) outputs F for all tested component M then C
is inconsistent
To summarize Definition 2 provides semi-decision proceduresto check whether a component or an environment are validfor a contract Lemma 3 provides semi-decision proceduresfor checking consistency and compatibility Finally Table Vindicates how operations from the contract algebra can bereflected into operations on observers
Due to the need for exercising all components or environ-ments using observers for checking consistency or compat-ibility is still non-effective For concrete theories exhibitingsome notion of ldquostrongestrdquo environment or component for theconsidered contract a reinforcement of Lemma 3 will ensureeffectiveness
In Section VI where concrete theories are reviewed weindicate for each theory how observers can be constructedand how Lemma 3 specializes
H Bibliographical note
Abstract contract theories and features of our presen-tation Our presentation here is new There is only a smallliterature providing an abstract formalization of the notion ofcontracts The only attempts we are aware of are the recentworks by Bauer et al [22] and Chen et al [59] albeit withdeeply different and complementary approaches
The publication [22] develops an axiomatization of thenotion of specification from which contracts can be derivedin a second step More precisely specifications are abstractentities that obey the following list of axioms it possesses arefinement relation that is a preorder which induces a notionof equivalence of specifications and a parallel compositionthat is associative commutative (modulo equivalence) andmonotonic with respect to refinement It is assumed thatif two specifications possess a common lower bound thenthey possess a greatest lower bound A quotient is alsoassumed which is the residuation of the parallel composi-tion From specifications contracts are introduced as pairs ofspecifications very much like AssumeGuarantee contracts wedevelop in Section VII are pairs of assertions Sets of legalenvironments and sets of implementations are associated tocontracts Finally modal contracts are defined by borrowingideas from modal specifications we discuss in Section VIIIThis abstract theory nicely complements the one we develop
here in that it shows that both specifications and contracts canbe defined as primitive entities and be used to build moreconcrete theories
The work [59] develops the concept of declarative speci-fication which consists of a tuple P = (ΣinΣout TΣ FΣ)where Σin and Σout are input and output alphabets of actionsΣ = Σin ] Σout and TΣ FΣ sube Σlowast such that FΣ sube TΣ
are sets of permissible and inconsistent traces respectivelymdashthis approach find its origins in earlier work by Dill [81]and Negulescu [143] Outputs are under the control of thecomponent whereas inputs are issued by the environmentThus after any successful interaction between the componentand the environment the environment can issue any input αeven if it will be refused by the component If α is refusedby the component after the trace t isin TΣ tα isin FΣ is aninconsistent trace capturing that a communication mismatchhas occurred An environment is called safe if it can preventa component from performing an inconsistent trace For Qto be used in place of P it is required that Q must existsafely in any environment that P can exist in safely this isthe basis on which refinement is defined Alphabet extensionis used by which input actions outside the considered alphabetare followed by an arbitrary behavior for the declarativespecification A conjunction is proposed that is the GLB forrefinement order A parallel composition is proposed whichis monotonic with respect to refinement A quotient is alsoproposed which is the residuation of parallel composition
Observers Observers being related to the wide areaof software and system testing have been widely studiedA number of existing technologies support the design ofobservers and we review some of them now
Synchronous languages [28] [100] [30] are a formalism ofchoice in dealing with observers The family of SynchronousLanguages comprises mainly the imperative language Es-terel [92] [84] and the dataflow languages Lustre [144] andSignal [157] The family has grown with several childrenoffering statecharts-like interfaces and blending dataflow andstatechart-based styles of programming such as in Scade V634Synchronous languages support only systems governed bydiscrete time not systems with continuous time dynamics(ODEs) They benefit from a solid mathematical semantics Asa consequence executing a given program always yields thesame results (results do not depend on the type of simulator)The simulated or analysed program is identical to the codefor embedding Thanks to these unique features specificationscan easily be enhanced with timing andor safety viewpointsThe RT-Builder35 tool on top of Signal is an example offramework supporting the combination of functional and tim-ing viewpoints while analyzing an application deployed overa virtual architecture (see Section IV-D4) The widely usedSimulinkStateflow36 tool by The Mathworks offers similarfeatures One slight drawback is that its mathematical seman-
34httpwwwesterel-technologiescomproductsscade-suite35httpwwwgeensoftcomenarticlertbuilder36httpwwwmathworkscomproductssimulink
RR ndeg 8147
Contracts for System Design 29
tics is less firmly defined (indeed results of executions maydiffer depending on the code executed simulation or generatedC code) On the other hand Simulink supports continuoustime dynamics in the form of systems of interconnectedODEs (Ordinary Differential Equations) thus supporting themodeling of the physical part of the system Using Simulinkpossibly enhanced with SimScape37 allows for includingphysical system models in observers eg as part of the systemenvironment The same comment holds regarding Modelica38
Actually observers have been proposed and advocated in thecontext of Lustre and Scade [101] [102] [103] Esterel [45]and Signal [137] [138] More precisely Scade advocatesexpressing tests using Scade itself Tests can then easily beevaluated at run time while executing a Scade program Toconclude observe that synchronous languages and formalismsdiscussed in this section are commercially available and widelyused
Another good candidate for expressing observers is theProperty Specification Language (PSL) PSL is an industrialstandard [151] [86] [85] for expressing functional (or behav-ioral) properties targeted mainly to digital hardware designWe believe that PSL is indeed very close to several lessestablished but more versatile formalisms based on restrictedEnglish language that are used in industrial sectors otherthan digital hardware eg in aeronautics automobile orautomation Consider the following property
ldquo For every sequence that starts with an a imme-diately followed by three occurrences of b and endswith a single occurrence of c d holds continuouslyfrom the next step after the end of the sequence untilthe subsequent occurrence of e rdquo
This property is translated into its PSL version
[]ab[3]c |=gt (d until e)
PSL is a well-suited specification language for expressingfunctional requirements involving sequential causality of ac-tions and events Although we are not aware of the usageof PSL in the particular context of contract-based design wemention the tool FoCS [2] that translates PSL into checkersthat are attached to designs The resulting checker takes theform of an observer if the PSL specification is properlypartitioned into assumption and guarantee properties More re-cently PSL was also used for the generation of transactors thatmay adapt high-level requirements expressed as transaction-level modules to the corresponding register-transfer implemen-tation [18] [17] It follows that the existing tool support forPSL makes this specification language suitable in the contract-based design using observers We note that the availabilityof formal analysis tools allows the design to be checkedexhaustivelymdashthis is of course at the price of restrictionson data types Another benefit in using PSL as an observer-based interface formalism is an existing methodology for user-guided automated property exploration built around this lan-
37httpwwwmathworkscomproductssimscape38httpswwwmodelicaorg
guage [158] [42] that is supported by the tool RATSY [43]As previously stated PSL is built on top of LTL and regularexpressions One can thus express liveness properties in PSLwhich are not suitable for online monitoring There are twoorthogonal ways to avoid this potential issue (1) restrictingthe PSL syntax to its safety fragment or (2) adapting the PSLsemantics to be interpreted over finite traces [87] A survey ofusing PSL in runtime verification can be found in [85]
Another relevant formalism for building observers consistsof the Live Sequence Charts (LSC) [64] [107] [105] LSCare a graphical specification language based on scenarios thatis an extension of Message Sequence Charts (MSC)39 Atypical LSC consists of a prechart and a main chart Thesemantics is that whenever the prechart is satisfied in a run ofthe system eventually the main chart must also be satisfiedPrecharts should not be confused with assumptions howeverthey are rather sort of ldquoprerequisitesrdquo LSCs are multi-modalin that any construct in the language can be either cold orhot with a semantics of ldquomay happenrdquo or ldquomust happenrdquorespectively If a cold element is violated (say a conditionthat is not true when reached) this is considered a legalbehavior and some appropriate action is taken Violation ofa hot element however is considered a violation of thespecification and is not allowed to happen in an executionLSC are executable The execution of a set of LSCs is calledplay out by the authors [107] Play out is useful for checkingan LSC specification against a property [66] LSC can beused as (expressive) tests to monitor the execution of a designover non-terminating runs While doing so the same rules asabove are applied except that the design controls the emissionof events and the LSC specification is used to react in caseof violation of the specification This is manifested by theabsence of rules explaining the occurrence of some event atrun-time This procedure is called play in by the authors Toconclude LSCs are well suited to express observers
VI PANORAMA OF CONCRETE THEORIES
For the coming series of sections where concrete contracttheories are reviewed the reader is referred to Table IV ofSection V where the meta-theory of contracts is developedWe will illustrate how various concrete contract theories canbe developed by specializing the meta-theory
VII PANORAMA ASSUMEGUARANTEE CONTRACTS
Our static example of Section IV provided an exampleof contract specified using Assumptions and Guarantees As-sumeGuarantee contracts (AG-contracts) Assumptions char-acterize the valid environments for the considered compo-nent whereas the Guarantees specify the commitments ofthe component itself when put in interaction with a validenvironment Various kinds of AG-contract theories can beobtained by specializing the meta-theory in different waysVariations concern how the composition of components isdefined We will review some of these specialization and relatethem to the existing literature
39httpwwwsdl-forumorgMSCindexhtm
RR ndeg 8147
Contracts for System Design 30
In general AG contract theories build on top of componentmodels that are assertions ie sets of behaviors or tracesassigning successive values to variables As we shall seedifferent kinds of frameworks for assertions can be consid-ered including asynchronous frameworks of Kahn ProcessNetworks (KPN) [117] and synchronous frameworks in whichbehaviors are sequences of successive reactions assigningvalues to the set of variables of the considered system We firstdevelop the theory for the simplest case of a fixed alphabetThen we develop the other cases
A Dataflow AG contracts
For this simplest variant all components and contractsinvolve a same alphabet Σ of variables possessing identical40
domain DWith this simplification a component M identifies with an
assertion
P sube Σ 7rarr Dlowast cupDω (10)
ie a subset of the set of all finite or infinite behaviors overalphabet Σ such a behavior associates to each symbol x isin Σa finite or infinite flow of values The flows are not mutuallysynchronized and there is no global clock or logical step Wediscuss in Section VII-D variants of this framework with moresynchronous models of behaviors For convenience we feelfree to use both set theoretic and boolean notations for therelations and operations on assertions
Two components are always composable and we definecomponent composition by the intersection of their respectiveassertions
P1timesP2 = P1andP2 (11)
Formulas (10) and (11) define a framework of asynchronouscomponents with no global clock and no notion of reac-tion Instead a component specifies a relation between thehistories of its different flows When input and output portsare considered as in Section VII-B and components are in-putoutput functions we obtain the model of Kahn ProcessNetworks [117] widely used for the mapping of synchronousprograms over distributed architectures [159] [160]
Definition 3 A contract is a pair C = (AG) of assertionscalled the assumptions and the guarantees The set EC of thelegal environments for C collects all components E such thatE sube A The set MC of all components implementing C isdefined by AtimesM sube GThus any component M such that M le G or notA is animplementation of C and MC = G or notA is the maximalimplementation Observe that two contracts C and Cprime withidentical input and output alphabets identical assumptionsand such that Gprime or notAprime = G or notA possess identical sets ofimplementations MC =MCprime According to our meta-theorysuch two contracts are equivalent Any contract C = (AG)is equivalent to a contract in saturated form (AGprime) such that
40This is only an assumption intended to simplify the notations It is by nomeans essential
Gprime supe notA or equivalently G or A = T the true assertionto exhibit Gprime just take Gprime = G or notA A saturated contractC = (AG) is consistent if and only if G 6= empty and compatibleif and only if A 6= empty
Next for C and Cprime two saturated contracts with identicalinput and output alphabets
refinement Cprime C holds iffAprimegeAGprimeleG (12)
Conjunction follows from the refinement relation for C1 andC2 two saturated contracts with identical input and outputalphabets C1 and C2 = (A1orA2 G1andG2)
Focus now on contract composition C = C1 otimes C2 for twosaturated contractsmdashthis is no loss of generality as we haveseen Contract composition instantiates through the followingformulas cf (1) in Section IV
G = G1andG2
A = max
A∣∣∣∣∣∣AandG2rArrA1
andAandG1rArrA2
(13)
which satisfies Assumption 1 of the meta-theory If further-more contracts are saturated then (13) reformulates as theformulas originally proposed in [29]
G = G1 andG2
A = (A1 andA2) or not(G1 andG2)(14)
Observe that the so obtained contract (AG) is saturatedG orA = (G1 andG2) or (A1 andA2) or not(G1 andG2) = T
No quotient operation is known for AssumeGuaranteecontracts
We finish this section by observing that the two contractsC1 and Cprime1 of Section IV-A1 satisfy Cprime1 C1 according to thetheory of this section guarantees are identical but assumptionsare relaxed
B Capturing exceptions
Referring to the primer of Section IV-A1 and its staticsystem example dividing by zero may raise an exception Forinstance a careless designer may consider instead of M1 aslight variation M prime1 of it where the behaviors are only partiallydefined
M prime1 behaviors (y 6= 0rarr z = xy)
leaving what happens if a value 0 is submitted for y unspeci-fied In practice y = 0 would raise an exception leading to anunpredictable outcome and possibly a crash unless exceptionhandling is offered as a rescue by the execution platform
In this section we show how a mild adjustment of ourtheory of AG contracts can capture exceptions and theirhandling To simplify we develop this again for the case ofa fixed alphabet Σ We only present the add-ons with respectto the previous theories the parts that remain unchanged arenot repeated
Since exceptions are undesirable events caused by the com-ponent itself and not by its inputsmdashfor our simple example the
RR ndeg 8147
Contracts for System Design 31
exception is the improper handling of the division by zeromdashweneed to include inputs and outputs as part of our frameworkfor components
A component is thus a tuple M = (ΣinΣout P ) whereΣ = Σin cup Σout is the decomposition of alphabet Σ intoits inputs and outputs and P sube (Σ 7rarr (Dlowast cupDω)) is anassertion Whenever convenient we shall denote by Σin
M QM PM etc the items defining component M Components M1
and M2 are composable if Σout1 cap Σout
2 = empty If so thenM1timesM2 = (ΣinΣout P ) is well defined with Σout =Σout
1 cup Σout2 Σin = Σminus Σout and P = P1 cap P2
Let us now focus on exceptions To capture improper re-sponse (leading to a ldquocrashrdquo) we distinguish a special elementfail isin D We assume that crash is not revertible ie inany behavior of the component any variable remains at failwhen it reaches that value Referring to the static example ofSection IV we would then set x0 = fail for any x We arenow ready to formalize what it means for a component to befree of exception
Definition 4 A component M is free of exception if1) It accepts all inputs
prΣinM
(PM ) = ΣinM 7rarr (DlowastcupDω)
2) It does not cause by itself the occurrence of fail in itsbehaviors for any behavior σ isin PM if the projectionprΣin
M(σ) of σ to the input alphabet Σin
M does not involvefail then neither does σ
Exception freeness defined in this way is such that if M1 andM2 are both composable and free of exception then M1timesM2
is also free of exception Hence we are free to restrict ouruniverse of components to exception free componentsmdashthusDefinition 4 defines our family of components AG contractsare re-defined accordingly
Definition 5 A contract is a tuple C = (ΣinΣout AG)where Σin and Σout are the input and output alphabets andA and G are assertions over Σ called the assumptions andthe guarantees The set EC of the legal environments for C areall free of exception components E such that Σin
E = ΣoutC
ΣoutE = Σin
C and PE sube A The set MC of all componentsimplementing C is defined by M is free of exception Σin
M =ΣinC and Σout
M = ΣoutC and PEtimesM sube G for every environment
E of CFocus now on the issue of consistency and compatibility forcontracts The following holds
Property 7 Let C = (ΣinΣout AG) be a contract satis-fying the following conditions
prΣinC
(G) = ΣinM 7rarr (DlowastcupDω) (15)
prΣoutC
(A) = ΣoutM 7rarr (DlowastcupDω) (16)
fail does not occur in G andA (17)
Then C is consistent and compatibleProof By condition (15) the component M = (ΣinΣout G)satisfies condition 4 of Definition 4 It may not satisfy condi-tion 2 however To achieve this we must modify in M the
behaviors not belonging to A to avoid fail to occur PreservingM on A will ensure that implementation of C is preservedTo get M prime replace any behavior σ isin G and notA by a behaviorσprime such that prΣin
C(σprime) = prΣin
C(σ) and prΣout
C(σprime) 63 fail
Component M prime obtained in this way is free of exception andimplements C showing that C is consistent Consider next thecomponent E = (ΣoutΣin A) If E is free of exception thenit is an environment for C If this is not the case then we canmodify E on AandnotG as we did for obtaining M prime This yieldsan environment Eprime for C showing that C is compatible 2
Conditions (15) and (16) express that assumptions andguarantees are both input enabled Condition (17) is the keyone Observe that now contract Cprime1 of Section IV-A1 isinconsistent since it has no implementationmdashimplementationsmust be free of exception In turn contract C1 is consistentThis is in contrast to the theory of Section VII-A whereboth contracts were considered consistent (crashes were notruled out) Indeed contract C1 of Section IV-A1 satisfies theconditions of Property 7 whereas Cprime1 does not Addressingexceptions matters
C Dealing with variable alphabets
Since contracts aim at capturing incomplete designs wecannot restrict ourselves to a fixed alphabetmdashit is not known inadvance what the actual alphabet of the complete design willbe Thus the simple variants of Sections VII-A and VII-B haveno practical relevance and we must extend them to dealingwith variable alphabets In particular components will now bepairs M = (ΣM PM ) where ΣM is the alphabet of M andPM is an assertion over ΣM Similarly contracts are triplesC = (ΣC AC GC) where assumptions AC and guarantees GCare assertions over alphabet ΣC
Key to dealing with variable alphabet this is the operationof alphabet equalization that we introduce next For P an as-sertion over alphabet Σ and Σprime sube Σ we consider its projectionprΣprime(P ) over Σprime which is simply the set of all restrictionsto Σprime of all behaviors belonging to P We will also need theinverse projection prminus1
Σprimeprime (P ) for Σprimeprime supe Σ which is the set ofall behaviors over Σprimeprime projecting to Σ as behaviors of P For(Σi Pi) i = 1 2 we call alphabet equalization of (Σ1 P1)and (Σ2 P2) the two assertions (Σprminus1
Σ (Pi)) i = 1 2 whereΣ = Σ1 cup Σ2
We also need to define alphabet equalization when thealphabet Σ decomposes as Σ = Σin ] Σout Equalizing theabove decomposition to a larger alphabet Σprimeprime supe Σ yieldsΣprimeprimeout = Σout whence Σprimeprimein = Σprimeprime Σprimeprimeout follows
Alphabet equalization serves as a preparation step to reusethe framework of Section VII-A when alphabets are variable
This being defined all operations and relations introducedin Section VII-A are extended to the case of variable alphabetsby 1) applying alphabet equalization to the involved assertionsand 2) reusing the operation or relation as introduced inSection VII-A
As pointed out in [29] this generalization yields a contracttheory that is a valid instantiation of the meta-theory (up tothe missing quotient) It is not satisfactory from the practical
RR ndeg 8147
Contracts for System Design 32
standpoint however The reason is that the conjunction oftwo contracts with disjoint alphabets yields a trivial assump-tion T which is very demandingmdashany environment must beaccommodatedmdashand does not reflect the intuition (more onthis will be discussed in Section VIII-D
To summarize Sections VII-A VII-B and VII-C togetherdefine a framework for asynchronous AssumeGuarantee con-tracts where components are of Kahn Process Network type
D Synchronous AG contracts
We obtain variants of this framework of AssumeGuaranteecontracts by changing the concrete definition of what anassertion is and possibly revisiting what the component com-position is We can redefine assertions as
P sube (Σ 7rarr D)lowast cup (Σ 7rarr D)ω (18)
Compare (18) with (10) In both cases assertions are sets ofbehaviors With reference to (10) behaviors were tuples offinite or infinite flows one for each symbol of the alphabetIn contrast in (18) behaviors are finite or infinite sequencesof reactions which are the assignment of a value to eachsymbol of the alphabet By having a distinguished symbolperp isin D to model the absence of an actual data we getthe multiple-clocked synchronous model used by synchronouslanguages [30] Definition (18) for assertions correspond to thesynchronous model of computation whereas (10) correspondsto the Kahn Process Network type of model [117] [142] Thematerial of Sections VII-A VII-B and VII-C can be adaptedto this new model of component composition thus yielding aframework of synchronous AssumeGuarantee contracts
E Observers
The construction of observers for this case is immediate Wedevelop it for the most interesting case in which exceptions arehandled see Sections VII-A and VII-B Let P be an assertionaccording to (10) P defines a verdict bP by setting
bP (σ) = T if and only if σ isin P (19)
Observers must return their verdict in some finite amount oftime Hence on-line interpretation based on Definition 3 isappropriate With this interpretation for C = (ΣinΣout AG)a contract its associated observer is obtained as follows withreference to Definition 2
bull bEC(E) is performed by drawing non-deterministically a
behavior σ of E and then evaluating bA(σ)bull bMC(M) is performed by drawing non-deterministically a
behavior σ of M and then evaluating bA(σ)rArr bM (σ)
Lemma 3 for generic observers specializes to the followingeffective semi-decision procedure
Lemma 4
1) If bA outputs F then C is incompatible2) If bA rArr bG outputs F then C is inconsistent
F Discussion
AssumeGuarantee contracts are a family of instantiationsof our meta-theory This family is flexible in that it canaccommodate different models of communication and differentmodels of exceptions AssumeGuarantee contracts are anadequate framework for use in requirements capture Indeedrequirements are naturally seen as assertions When categoriz-ing requirements into assumptions (specifying the context ofuse of the system under development) and guarantees (that thesystem offers) formalizing the resulting set of requirements asan AG contract seems very natural
Regarding exceptions the special value fail that we intro-duced to capture exceptions is not something that is given inpractice Value fail may subsume various run time errors Al-ternatively for the synchronous AssumeGuarantee contractsfail can capture the failure of a component to be input enabled(able in each reaction to accept any tuple of inputs)
In its present form the framework of AssumeGuaranteecontracts (synchronous or asynchronous) suffers from theneed to manipulate negations of assertions an operation thatis generally not effective except if the framework is restrictedto finite state automata and finite alphabets of actions Forgeneral frameworks using observers or abstract interpretationcan mitigate this in part
G Bibliographical note
By explicitly relying on the notions of Assumptions andGuarantees AG-contracts are intuitive which makes themappealing for the engineer In AG-contracts Assumptions andGuarantees are just properties The typical case is when theseproperties are languages or sets of traces which includes theclass of safety properties [122] [58] [136] [14] [61] AG-contracts were advocated by the SPEEDS project [29] Theywere further experimented in the framework of the CESARproject [63] with the additional consideration of weak andstrong assumptions The theory developed in [29] turns outto be closest to this presentation still exceptions were nothandled in [29] The presentation developed in this paperclarifies the design choices in AG-contract theories
Inspired by [126] another form for AG-contract was pro-posed by [97] [99] when designs are expressed using theBIP programming language [41] [174] To achieve separatedevelopment of components and to overcome the problemsthat certain models have with the effective computation ofthe operators the authors avoid using parallel compositionotimes of contracts Instead they replace it with the concept ofcircular reasoning which states as follows in its simplestform if design M satisfies property G under assumptionA and if design N satisfies assumption A then M times Nsatisfies G When circular reasoning is sound it is possibleto check relations between composite contracts based ontheir components only without taking expensive compositionsIn order for circular reasoning to hold the authors deviserestricted notions of refinement under context and show howto implement the relations in the contract theory for the BIP
RR ndeg 8147
Contracts for System Design 33
framework Compatibility is not addressed and this proposaldoes not consider conjunction
Regarding extensions a notion of contract for real-timeinterfaces is proposed in [40] Sets of tasks are associated tocomponents which are individually schedulable on a processorAn interface for a component is an ω-language containing alllegal schedules Schedulability of a set of components on asingle processor then corresponds to checking the emptinessof their intersection The interface language considered isexpressive enough to specify a variety of requirements likeperiodicity the absence or the presence of a jitter etc An as-sumeguarantee contract theory for interfaces is then developedwhere both assumptions and guarantees talk about boundson the frequency of task arrivals and time to completionsDependencies between tasks can also be captured Refinementand parallel product of contracts are then defined exactly asin the SPEEDS generic approach
In [145] a platform-based design methodology that usesAG analog contracts is proposed to develop reliable ab-stractions and design-independent interfaces for analog andmixed-signal integrated circuit design Horizontal and verti-cal contracts are formulated to produce implementations bycomposition and refinement that are correct by constructionThe effectiveness of the methodology is demonstrated on thedesign of an ultra-wide band receiver used in an intelligenttire system an on-vehicle wireless sensor network for activesafety applications
AG-contracts have been extended to a stochastic setting byDelahaye et al [75] [76] [77] In this work the implementa-tion relation becomes quantitative More precisely implemen-tation is measured in two ways reliability and availabilityAvailability is a measure of the time during which a systemsatisfies a given property for all possible runs of the system Incontrast reliability is a measure of the set of runs of a systemthat satisfy a given property Following the lines of the contracttheories presented earlier satisfaction is assumption-dependentin the sense that runs that do not satisfy the assumptions areconsidered to be ldquocorrectrdquo the theory supports refinementstructural composition and logical conjunction of contractsand compositional reasoning methods have been proposedwhere the stochastic or non-stochastic satisfaction levels canbe budgeted across the architecture For instance assume thatimplementation Mi satisfies contract Ci with probability αifor i = 1 2 then the composition of the two implementationsM1timesM2 satisfies the composition of the two contracts C1otimesC2
with probability at least α1 + α2 minus 1Features of our presentation This presentation of AG-
contracts is new in may respects For the first time it iscast into the meta-theory of contracts with the advantage ofclarifying the definition of refinement and parallel compositionof contractsmdashthis involved some hand waving in the originalwork [29] Also this allowed us to handle exceptions properly
VIII PANORAMA INTERFACE THEORIES
Interface theories are an interesting alternative to As-sumeGuarantee contracts They aim at providing a merged
specification of the implementations and environments associ-ated to a contract via the description of a single entity calledan interface We review some typical instances of interfacetheories with emphasis on interface automata and modalinterfaces Interface theories generally use (a mild variation of)Lynch InputOutput Automata [135] [134] as their frameworkfor components and environments As a prerequisite we thusrecall the background on InputOutput Automata io-automatafor short
A Components as io-automataAn io-automaton is a tuple M = (ΣinΣout Q q0rarr)
wherebull Σin and Σout are disjoint finite input and output alpha-
bets set Σ = Σin cup Σoutbull Q is a finite set of states and q0isinQ is the initial statebull rarr sube QtimesΣtimesQ is the transition relation as usual we
write q αminusrarr qprime to mean (q α qprime) isin rarr and qαminusrarr to
indicate the existence of a qprime such that q αminusrarr qprimeBy concatenation transition relation rarr extends to a relationrarrlowast on Q times Σlowast times Q where Σlowast is the set of all finite wordsover Σ Say that a state qprime is reachable from q if there existssome word m such that q mminusrarrlowast qprime To considerably simplifythe development of the theory we restrict ourselves to
deterministic io-automata ie such thatq
αminusrarr q1 and q αminusrarr q2 implies q2 = q1(20)
Two io-automata M1 and M2 having identical alphabet Σare composable if the usual inputoutput matching conditionholds Σout
1 capΣout2 = empty and their composition M = M1timesM2
is given by
Σin = Σin1 cap Σin
2
Σout = Σout1 cup Σout
2
Q = Q1 timesQ2 and q0 = (q10 q20)
and the transition relation rarr is given by
(q1 q2)αminusrarr (qprime1 q
prime2) iff qi
αminusrarri qprimei i = 1 2
An io-automaton is said closed whenever Σin = empty and openotherwise For Mi i = 1 2 two io-automata and two statesqi isin Qi say that q1 simulates q2 written q2leq1 if
forallα qprime2 such that q2αminusrarr2 qprime2 rArr
q1
αminusrarr1 qprime1
and qprime2leqprime1(21)
Say that
M1 simulates M2 written M2leM1 if q20leq10 (22)
Observe that simulation relation (2122) does not distinguishinputs from outputs neither it distinguishes the componentfrom its environment It is the classical simulation relationmeant for closed systems Due to condition (20) of determin-ism simulation coincides with language inclusion
Variable alphabet is again dealt with using the mechanismof alphabet equalization For M = (ΣinΣout Q q0rarr) anio-automaton and Σprime sup Σ we define
MuarrΣprime
=(Σin cup (Σprime Σ)Σout Q q0rarrprime
)RR ndeg 8147
Contracts for System Design 34
whererarrprime is obtained by adding torarr for each state and eachadded action a self-loop at this state labeled with this action
Componentsmdashand consequently environmentsmdashfor use ininterface theories will be receptive io-automata (also termedinput enabled) ie they should react by proper response toany input stimulus in any state41
M is receptive iff forallq isin Qforallα isin Σin qαminusrarr (23)
Receptiveness is stable under parallel composition
B Interface Automata with fixed alphabet
For reasons that will become clear later we restrict thepresentation of interface automata to the case of a fixedalphabet Σ We begin with the definition of Interface Automatawhich are possibly non-receptive io-automata Moreover wegive their interpretation as contracts according to the meta-theory
Definition 6 An Interface Automaton is a tuple C =(ΣinΣout Q q0rarr) where ΣinΣout Qrarr are as inio-automata
The initial state q0 however may not satisfy q0isinQ If q0isinQholds Interface Automaton C defines a contract by fixing apair (EC MC ) as followsbull The set EC of the legal environments for C collects all
components E such that1) Σin
E = Σout and ΣoutE = Σin Thus E and C seen as
io-automata are composable and E timesC is closed2) For any output action α isin Σin of environment E
such that qEαminusrarrE and any reachable state (qE q)
of E times C then (qE q)αminusrarrEtimesC holds
There exists a unique maximal environment EC isin EC inthat EC timesC simulates EtimesC in the sense of (22) for anyE isin EC EC = (ΣoutΣin Q cup gt q0rarrEC ) where(a) the restriction to Qtimes ΣtimesQ of transition relationrarrEC coincides with rarr
(b) forallq isin Q q αminusrarrEC gt holds if and only if not[qαminusrarr ]
and α isin Σout(c) gt αminusrarrEC gt holds for any α isin Σ
bull The setMC of the implementations of C collects all com-ponents M such that io-automaton C simulates ECtimesMin the sense of (22)
Condition 2) means that environment E is only willing toemit an output if it is accepted as an input by C in thecomposition E times C Regarding the existence and uniquenessof EC observe first that conditions (a) and (b) together implythat EC is receptive Also by (a) and (b) EC times C is strictlyidentical with (emptyΣ Q q0rarr) ie it is obtained from Cseen as an io-automaton by simply turning inputs to outputsConsequently Condition 2) holds and thus EC isin EC By (b)and (c) EC is maximal
The above definition of Interface Automata is heterodoxcompare with the original references [72] [5] Definition 6
41In fact receptiveness is assumed in the original notion of io-automatonby Nancy Lynch [135] [134] We use here a relaxed version of io-automatonfor reasons that will become clear later
introduces the two sets EC and MC whereas no notionof implementation or environment is formally associated toan Interface Automaton in the original definition Also thehandling of the initial state is unusual Failure of q0isinQ tohold typically arises when the set of states Q is emptyOur Definition 6 allows to cast Interface Automata in theframework of the meta-theory of Table IV
Corresponding relations and operations must be instantiatedand we do this next As a first immediate result
Lemma 5 q0 isin Q is the necessary and sufficient conditionfor C to be both consistent and compatible in the sense of themeta-theory ie EC 6= empty and MC 6= empty
Refinement and conjunction Contract refinement as de-fined in Table IV is equivalent to alternate simulation [10]defined as follows for Ci i = 1 2 two contracts say that tworespective states qi i = 1 2 are in alternate simulation writtenq2q1 if
forallα isin Σout2 qprime2 st q2
αminusrarr2 qprime2 rArr
α isin Σout
1
q1αminusrarr1 qprime1
qprime2qprime1
forallα isin Σin1 q
prime1 st q1
αminusrarr1 qprime1 rArr
α isin Σin
2
q2αminusrarr2 qprime2
qprime2qprime1
(24)
Say that C2 refines C1 written C2C1 if q20q10 The firstcondition of (24) reflects the inclusionMC2
subeMC1 whereas
the second condition of (24) reflects the opposite inclusionEC2supe EC1
Alternate simulation can be effectively checkedsee [70] for issues of computational complexity Unfortunatelyno simple formula for the conjunction of contracts is knownSee [83] for the best results in this direction
Parallel composition and quotient Contract compositionC2otimesC1 as defined in the meta-theory is effectively computedas follows for Ci two Interface Automata satisfying the con-ditions of Lemma 5 Consider as a first candidate for contractcomposition the composition C2timesC1 where Ci i = 1 2 areseen as io-automata This first guess does not work becauseof the condition involving environments in the contract compo-sition of the meta-theory More precisely by the meta-theorywe should have
E |=E C rArr [EtimesM2 |=E C1 and EtimesM1 |=E C2]
which requires forallα isin Σouti qi
αminusrarri rArr (q1 q2)αminusrarrC2timesC1
Pairs (q1 q2) not satisfying this are called illegal In words apair of states (q1 q2) is illegal when one Interface Automatonwants to submit an output whereas the other one refuses toaccept itmdashreferring to AssumeGuarantee contracts one couldinterpret this as a mismatch of assumptions and guaranteesin this pair of interfaces Illegal pairs must then be prunedaway Pruning away illegal pairs from C2timesC1 together withcorresponding incoming transitions may cause other illegalpairs to occur The latter must also be pruned away untilfixpoint occurs The result is the contract composition C2otimesC1
RR ndeg 8147
Contracts for System Design 35
As a result of this pruning it may be the case that theresulting contract has empty set of states which by Lemma 5expresses that the resulting composition of the two interfacesis inconsistent and incompatiblemdashin the original literature onInterface Automata [72] [5] it is said that the two interfacesC1 and C2 are incompatible
In [39] incremental design of deterministic Interface Au-tomata is studied Let Cdarr be the interface C with input andoutput actions interchanged Given two Interface Automata C1and C2 the greatest interface compatible with C2 such that theircomposition refines C1 is given by (C2 C1darr)darr Hence the partregarding quotient in the meta-theory is correctly addressed fordeterministic Interface Automata
Dealing with variable alphabets So far we have pre-sented the framework of interface automata for the case of afixed alphabet The clever reader may expect that dealing withvariable alphabets can be achieved by using the mechanismof alphabet equalization via inverse projections42 This is acorrect guess for contract composition It is however not clearif it is also adapted for conjunction for which no satisfactoryconstruction exists as previously indicated
In contrast alphabet equalization and conjunction are el-egantly addressed by the alternative framework of ModalInterfaces we develop now
C Modal Interfaces with fixed alphabet
Modal Interfaces inherit from both the Interface Au-tomata and the originally unrelated notion of Modal Automa-ton (or Modal Transition System) see the bibliographicalnote VIII-G As Interface Automata Modal Interfaces usereceptive io-automata as their components and environmentsThe presentation of Modal Interfaces we develop here isaligned with our meta-theory and thus differs from classicalpresentations Again we begin with the case of a fixedalphabet Σ
Definition 7 We call Modal Interface a tuple of the formC = (ΣinΣout Q q0rarr 99K) where ΣinΣout Q q0 are asin Interface Automata and rarr 99Ksube Q times Σ times Q are twotransition relations called must and may respectively
A Modal Interface C such that q0isinQ induces two (possiblynon receptive) io-automata
and Cmust = (ΣinΣout Q q0rarr)and Cmay = (ΣinΣout Q q0 99K)
A Modal Interface is deterministic if Cmay is deterministic inthe sense of 20 C defines a contract by fixing a pair (EC MC )as follows
The set EC of the legal environments for C collects allcomponents E such that
1) ΣinE = Σout and Σout
E = Σin consequently E andCmust seen as io-automata are composable and E timesCmust is closed the same holds with Cmay in lieu ofCmust
42The inverse projection of an io-automaton is simply achieved by addingin each state a self-loop for each missing symbol
2) For any α isin Σin such that qEαminusrarrE and any reachable
state (qE q) of E times Cmay (qE q)αminusrarrEtimesCmust
There exists a unique maximal environment EC isin EC in thatEC times Cmay simulates E times Cmay in the sense of (22) for anyE isin EC EC = (ΣoutΣin Q cup gt q0rarrEC ) where(a) the restriction to QtimesΣintimesQ of transition relationrarrEC
coincides with rarr the restriction to Q times Σout times Q oftransition relation rarrEC coincides with 99K
(b) for any q isin Q q αminusrarrEC gt holds if and only if not[qα99K ]
and α isin Σout(c) gt αminusrarrEC gt holds for any α isin Σ
The set MC of the implementations of C collects all compo-nents M such that
3) ECtimesCmay simulates ECtimesM in the sense of (22)[only may transitions are allowed for ECtimesM ]
4) for any reachable state (qE qM ) of ECtimesM and (qE q)of ECtimesCmay such that (qE qM )le(qE q) and any ac-tion α isin Σout
M such that q αrarr then (qE qM )αminusrarrECtimesM
[must transitions are mandatory in ECtimesM ]
The first paragraph is a verbatim of the original definition ofModal Interfaces [166] Definition 7 introduces the two setsEC and MC whereas the classical theory of Modal Interfacesconsiders and develops a different notion of model (oftenalso called ldquoimplementationrdquo which is unfortunate) As forInterface Automata in Section VIII-B the handling of initialstate q0 is heterodox Our Definition 7 allows to cast ModalInterfaces in the framework of the meta-theory
To justify the existence and uniqueness of EC observe firstthat conditions (a) and (b) together imply that EC is receptiveCondition (2) follows from (a) Maximality in the sense of(22) follows from (b) and (c)
Consistency and Compatibility We begin with consis-tency Say that state q isin Q of C is consistent if q αrarr impliesq
α99K otherwise we say that it is inconsistent Assume thatC has some inconsistent state q isin Q meaning that for someaction α q αrarr holds but q
α99K does not hold By conditions 3)
and 4) of Definition 7 for any environment E and anyimplementation M of C no state (qE qM ) of EtimesM satisfies(qE qM )leq Hence all may transitions leading to q can bedeleted from C without changing MC Performing this makesstate q unreachable in Cmay thus Condition 2 of Definition 7is relaxed and the set of environments is possibly augmentedSince we have removed may transitions some more stateshave possibly become inconsistent So we must repeat thesame procedure Since the number of states is finite thisprocedure eventually reaches a fixpoint At fixpoint the setQ of states partition as Q = Qcon ]Qincon where Qincon
collects all states that were or became inconsistent as a resultof this procedure and Qcon only collects consistent statesIn addition since the fixpoint has been reached Qincon isunreachable from Qcon As a final step we delete Qincon andcall [C] the so obtained contract The following result holds
Lemma 6
RR ndeg 8147
Contracts for System Design 36
1) Modal Interface [C] satisfies
M[C]
=MC and E[C]supe EC (25)
where the inclusion is strict unless C possesses noinconsistent state
2) [C] offers the smallest set of environments among theModal Interfaces satisfying (25)
3) C is consistent and compatible if and only if Qcon 3 q0In the sequel unless otherwise specified we will only considerModal Interfaces that are consistent and compatible
Refinement and conjunction Conjunction and refinementare instantiated in a very elegant way in the theory of ModalInterfaces Contract refinement in the sense of the meta-theoryis instantiated by the effective notion of Modal refinement weintroduce now Roughly speaking modal refinement consistsin enlarging the must relation (thus enlarging the set of legalenvironments) and restricting the may relation (thus restrictingthe set of implementations) The formalization requires the useof simulation relations
For C a Modal Interface and qisinQ a state of it introducethe following may and must sets
may(q) = α isin Σ | q α99K
must(q) = α isin Σ | q αrarr
Definition 8 (modal refinement) Let Ci i = 1 2 be twoModal Interfaces and let qi be a state of Ci for i = 1 2Say that q2 refines q1 written q2 q1 if
may2(q2) sube may1(q1)must2(q2) supe must1(q1)
and forallα isin Σ
q1
α99K1 qprime1
q2α99K2 qprime2
=rArr qprime2 qprime1
Say that C2 C1 if q20 q10
The following result relates modal refinement with contractrefinement as defined in the meta-theory It justifies the con-sideration of modal refinement Its proof follows by direct useof Definition 7 and Lemma 6
Lemma 7 For C1 and C2 two Modal Interfaces the follow-ing two properties are equivalent(i) MC2
sube MC1and EC2
supe EC1 meaning that contract C2
refines contract C1 following the meta-theory(ii) [C2] [C1] ie [C2] refines contract [C1] in the sense of
modal refinementThe conjunction of two Modal Interfaces is thus the GreatestLower Bound (GLB) with respect to refinement order Itscomputation proceeds in two steps In a first step we wildlyenforce the GLB and compute a pre-conjunction by takingunion of must sets and intersection of may sets
Definition 9 The pre-conjunction43 C1andC2 of two ModalInterfaces is only defined if Σin
1 = Σin2 and Σout
1 = Σout2
43Pre-conjunction was originally denoted by the symbol amp in [164] [167][166]
and is given by Σin = Σin1 Σout = Σout
1 Q = Q1timesQ2q0 = (q10 q20) and its two transition relations are given by
must(q1 q2) = must1(q1) cupmust2(q2)may(q1 q2) = may1(q1) capmay2(q2)
(26)
Due to (26) C1andC2 may involve inconsistent states and thusin a second step the pruning introduced in Lemma 6 must beapplied
C1 and C2 = [C1andC2] (27)
Say that the two Modal Interfaces C1 and C2 are consistent44
if C1 and C2 is consistent in the sense of Lemma 6Parallel composition and quotient For Modal Interfaces
we are able to define both parallel composition and quotient inthe sense of the meta-theory As it was the case for InterfaceAutomata parallel composition for Modal Interfaces raisescompatibility issues and thus a two-step procedure is againfollowed for its computation
Definition 10 The pre-composition C1otimesC2 of two ModalInterfaces is only defined if Σout
1 capΣout2 = empty and is given by
Σout = Σout1 cup Σout
2 Q = Q1timesQ2 q0 = (q10 q20) and itstwo transition relations are given by
must(q1 q2) = must1(q1) capmust2(q2)may(q1 q2) = may1(q1) capmay2(q2)
(28)
Say that a state (q1 q2) of C1otimesC2 is illegal if
may1(q1) cap Σin2 6sube must2(q2)
or may2(q2) cap Σin1 6sube must1(q1)
Illegal states are pruned away from C1otimesC2 as follows Removefrom Cmay
1 times Cmay2 all transitions leading to (q1 q2) As
performing this may create new illegal states the same isrepeated until fixpoint is reached As a final step we delete thestates that are not may-reachable This finally yields C1otimesC2which no more possesses illegal states
The above construction is justified by the following resultLemma 8 C1otimesC2 as defined in Definition 10 instantiates
the contract composition from the meta-theory
Proof (sketch) E is an environment for C iff for any reachablestate (qE q1 q2) of E times Cmay
1 times Cmay2 we have
rs(qE ) sube must1(q1) capmust2(q2) (29)
where rs(q) the ready set of state q is the subset of actionsα such that q αminusrarr holds Let M1 be any implementation ofC1 and consider EtimesM1 We need to prove that EtimesM1 is anenvironment for C2 ie satisfies Condition 2 of Definition 7(we must also prove the symmetric property) Let (qE q1 q2)be a reachable state of EtimesM1timesCmay
2 We must prove
rs(qE ) cap rsM1 (q1 ) cap Σ in2 sube must2(q2)
By (29) it suffices that the following property holds
rsM1(q1 ) cap Σ in
2 sube must2(q2) (30)
44This is the usual wording in the literature
RR ndeg 8147
Contracts for System Design 37
However we only know that rsM1(q1 ) sube may1 (q1 ) Hence
to guarantee (30) we must prune away illegal pairs of statesTo this end we use the same procedure as before we makestate (q1 q2) unreachable in Cmay
1 timesCmay2 by removing all may
transitions leading to that state We complete the reasoning aswe did for the study of consistency 2
Definition 11 The quotient C1C2 of two modal interfacesC1 and C2 is only defined if Σin
1 cap Σout2 = empty and is defined
according to the following two steps procedure First defineC as follows Σout = Σout
1 Σout2 Q = Q1 times Q2 q0 =
(q10 q20) and its two transition relations are given by
must(q1 q2) = must1(q1)
may(q1 q2) = not [may1(q1) cap notmust1(q1)] cupnot [must1(q1) capmust2(q2)] cupnot [may1(q1) cupmay2(q2)]
These formulas may give raise to inconsistent states and thusin a second step we set C1C2 = [C]This definition is justified by the following result [166]showing that Definition 11 instantiates the meta-theory
Lemma 9 C1 otimes C2 C if and only if C2 CC1
Now it may be that (C1C2)otimesC2 possess illegal pairs of states(Definition 10) whence the following improvement whereΣout and Σin are as in Definition 11 and may and mustrefer to the quotient C1C2
Definition 12 Let Cprime be the interface defined on the samestate structure as C1C2 with however the following modali-ties
may prime(q1 q2) = may(q1 q2) cap(may2(q2) cup Σin
)must prime(q1 q2) = must(q1 q2) cup (Σout
1 cap Σout2 capmay2(q2))
define the compatible quotient written C1C2 to be thereduction of Cprime C1C2 = [Cprime]
This construction is justified by the following result
Lemma 10 The compatible quotient C1C2 solves thefollowing problem
max
C∣∣∣∣∣∣C has no inconsistent stateC otimes C2 has no illegal pair of statesC otimes C2 C1
Proof Denote C = C1C2 the compatible quotient definedabove The proof is threefold (i) C is proved to be a solutionof the inequality CotimesC2 C1 (ii) C is proved to be compatiblewith C2 and (iii) every Cprime satisfying the two conditions aboveis proved to be a refinement of C
Remark that reachable states in (C1C2)otimesC2 are of the form(q1 q2 q2) and that for every reachable state pair (q1 q2) inC1C2 state (q1 q2 q2) is reachable in (C1C2)otimes C2
(i) Remark that may prime sube may and must prime supe must HenceC1C2 C1C2 Since the parallel composition is monotonic(C1C2)otimes C2 (C1C2)otimes C2 C1
(ii) For every state (q1 q2 q2) reachable in (C1C2)otimes C2one among the following three cases occurs
bull Assume e isin Σin1 meaning that e is an input for both C2
and C1C2 Hence state (q1 q2 q2) is not illegal becauseof e
bull Assume e isin Σout1 cap Σout
2 Therefore e is an input of thecompatible quotient Remark must prime(q1 q2) sube may2(q2)Hence state (q1 q2 q2) is not illegal because of e
bull Assume e isin Σout1 capΣin
2 meaning that e is an output of thecompatible quotient Remark may prime(q1 q2) sube must2(q2)Therefore state (q1 q2 q2) is not illegal because of e
(iii) Let Cprimeprime be a modal interface such that C1C2 Cprimeprime C1C2 We shall prove that either Cprimeprime C1C2 or that Cprimeprime is notcompatible with C2 Remark that every reachable state (q1 q2)of C1C2 is related to exactly one state qprimeprime of Cprimeprime by the twomodal refinement relations Assume that Cprimeprime is not a refinementof C1C2 meaning that there exists related states (q1 q2)and qprimeprime such that may prime(q1 q2) sube may primeprime(qprimeprime) sube may(q1 q2)and must prime(q1 q2) supe must primeprime(qprimeprime) supe must(q1 q2) and eithermay prime(q1 q2) ( may primeprime(qprimeprime) or must prime(q1 q2) ) must primeprime(qprimeprime)Remark e isin Σin
1 implies that e isin may prime(q1 q2) iff e isinmay(q1 q2) and that e isin must prime(q1 q2) iff e isin must(q1 q2)Therefore the case e isin Σin
1 does not have to be considered
1) Assume there exists e such that e isin may primeprime(qprimeprime) may prime(q1 q2) Remark this implies e isin Σout
1 cap Σin2
meaning that e is an output of the compatible quo-tient Remark also that e 6isin must2(q2) Therefore state(qprimeprime q2) is illegal in Cprimeprime otimes C2
2) Assume there exists e such that e isin must prime(q1 q2) must primeprime(qprimeprime) Remark this implies e isin Σout
1 cap Σout2
meaning that e is an input of the compatible quotientRemark also that e isin may2(q2) Therefore state (qprimeprime q2)is illegal in Cprimeprime otimes C2
2
D Modal Interfaces with variable alphabet
As a general principle every relation or operator introducedin Section VIII-C (for Modal Interfaces with a fixed alphabetΣ) is extended to the case of variable alphabets by 1) extendingand equalizing alphabets and then 2) applying the relations oroperators of Section VIII-C to the resulting Modal InterfacesFor all frameworks we studied so far alphabet extension wasperformed using inverse projections see Section VII-C Forinstance this is the procedure used in defining the compositionof io-automata extending alphabets in io-automata is byadding at each state and for each added action a self-loop labeled with this action The very reason for using thismechanism is that it is neutral for the composition in thefollowing sense it leaves the companion io-automaton freeto perform any wanted local action
So for Modal Interfaces what would be a neutral procedurefor extending alphabets Indeed considering (26) or (28)
RR ndeg 8147
Contracts for System Design 38
yields two different answers namely
for (26)
α isin may1(q1) and α isin whatever2(q2)dArr
α isin whatever(q1 q2)
for (28)
α isin must1(q1) and α isin whatever2(q2)dArr
α isin whatever(q1 q2)
where ldquowhateverrdquo denotes either may or must Consequentlyneutral alphabet extension is by adding
bull may self-loops for the conjunction andbull must self-loops for the composition
The bottom line is that we need different extension proceduresThese observations explain why alphabet extension is properlyhandled neither by Interface Automata (see the last paragraphof Section VIII-B) nor by AG-contracts (see the end ofSection VII-C) These theories do not offer enough flexibilityfor ensuring neutral extension for all relations or operators
We now list how alphabet extension must be performed foreach relation or operator for two Modal Interfaces C1 and C2(the reader is referred to [166] for justifications) Alphabetsare extended as follows where Σprime supe Σ Define the strongextension of C to Σprime written CuarrΣprime
as follows
CuarrΣprime
(Σin)uarrΣprime
= Σin cup (Σprime Σ)
(Σout)uarrΣprime
= Σout
QuarrΣprime
= Q
quarrΣprime
0 = q0
mayuarrΣprime
= may cup (Σprime Σ)
mustuarrΣprime
= must cup (Σprime Σ)
(31)
In (31) the added may and must transitions are all self-loopsThe weak extension of C written CuArrΣprime
is defined using thesame formulas with the only following modification
CuArrΣprime
=
mustuArrΣprime= must
(32)
Observe that the strong extension uses the classical inverseprojection everywhere The weak extension however proceedsdifferently with the must transitions in that it forbids the legalenvironments to submit additional actions as its outputs
Using weak and strong alphabet equalization the relationsand operations introduced in Section VIII-C extend to variablealphabets as indicated now In the following formulas (ΣΣprime)is a pair such that Σ sube Σprime and (Σ1Σ2Σ) denotes a triplesuch that Σ = Σ1 cup Σ2 and satisfying the typing constraints
Σini = Σin cap Σi and Σout
i = Σout cap Σi for i = 1 2
It is understood that contract C has alphabet Σ and so on
Theorem 1 The following relations and operators
M prime |=M C = M prime |=M CuArrΣprime
Eprime |=E C = Eprime |=E CuarrΣprime
C1 C2 = C1 CuArrΣ2
C1 and C2 = CuArrΣ1 and CuArrΣ
2
C1 otimes C2 = CuarrΣ1 otimes CuarrΣ2
C1C2 = CuArrΣ1 CuarrΣ2
(33)
instantiate the meta-theory
Proof The first two formulas just provide definitions so noproof is needed for them Their purpose is to characterizethe weakly and strongly extended Modal Interfaces in termsof their sets of environments and implementations For bothextensions allowed output actions of the implementations areaugmented whereas mandatory actions are not For the weakextension legal environments are not modified in that noadditional output action is allowed for them In contrast for thestrong extension legal environments are allowed to submit anyadditional output action These observations justify the otherformulas 2
E Projecting and Restricting
A difficult step in the management of contracts was illus-trated in Figure 4 of Section IV-D It consists in decomposinga contract C into a composition of sub-contractsotimes
iisinI Ci C (34)
where sub-contract Ci has alphabet Σi = Σini ] Σout
i As aprerequisite to (34) the designer has to guess some topologicalarchitecture by decomposing the alphabet of actions of C as
Σ =⋃iisinI Σi Σi = Σin
i ] Σouti (35)
such that composability conditions regarding inputs and out-puts hold Guessing architectural decomposition (35) relies onthe designerrsquos understanding of the system and how it shouldnaturally decomposemdashthis typically is the world of SysMLFinding decomposition (34) is however technically difficultin that it involves behaviors It is particularly difficult if Cis itself a conjunction of viewpoints or requirements whichtypically occurs in requirements engineering see Section XI
C =andkisinK Ck (36)
The algorithmic means we develop in the remaining part ofthis section will be instrumental in solving (34) They will beused in the Parking Garage example of Section XI
Projecting over a subalphabet Projecting a contract overa sub-alphabet is the first natural tool for consideration Itis the dual operation with respect to alphabet extension thatwas developed in Section VIII-D Two projections can bedefined which can be seen as under- and over-approximationsrespectively by referring to the refinement order
RR ndeg 8147
Contracts for System Design 39
Let C be a Modal Interface with alphabet Σ = Σin cup Σout
and let Σprime sub Σ be a sub-alphabet Define respectively theabstracted projection and refined projection
CdarrΣprime= min Cprime | ΣCprime = Σprime and Cprime C
CdArrΣprime= max Cprime | ΣCprime = Σprime and Cprime C
(37)
where ldquominrdquo and ldquomaxrdquo refer to refinement order for ModalInterfaces with different alphabets see (33) The projectionCdArrΣprime
(respectively CdarrΣprime) is computed via the following on-
the-fly algorithm 1) Perform ε-closure on the set of states byconsidering unobservable the actions not belonging to Σprime andthen 2) Perform determinization by giving priority to mustover may (respectively to may over must) see Table VI fordetails Step 2) of the procedure for computing CdArrΣprime
is apossible source of inconsistencies
The abstracted projection CdarrΣprimeprovides a projected view
of a system-level contract over a small subset of actionsThe abstracted projection is thus a useful tool for contractexploration and debug It is not a synthesis tool however
This is in contrast to the refined projection CdArrΣprime which
satisfies the following result For any finite set Ci | i isin Iof Modal Interfaces with respective alphabets Σi we haveassuming that the left and right hand sides are properlydefinedmdasha typing property on input and output alphabetsotimes
iisinI
[Ci and
(andkisinK C
dArrΣi
k
)]
andkisinK Ck (38)
To show this by symmetry it is enough to show (38) withthe conjunction on the right hand side replaced by any singleCk for k selected from finite set K For any i isin I we haveCdArrΣi
k Ck and thus
Cprimei =def
[Ci and
(andkisinK C
dArrΣi
k
)] Ck (39)
holds for every i from which (38) follows Unfortunately therefined projection quite often gives raise to inconsistenciesIn addition the contract composition arising in left hand sideof (38) is subject to incompatibilities Informally said thistechnique works if the sub-systems are only ldquoloosely coupledrdquoso that neither inconsistencies nor incompatibilities occur Tomitigate this problem we propose an alternative technique forturning a conjunction into a composition
Restricting to a sub-alphabet Let C be a Modal Interfacewith alphabet Σ = Σin cup Σout and let (ΣprimeinΣprimeout) be twoinput and output sub-alphabets such that Σprimeout sube Σout SetΣprime = Σprimein]Σprimeout and define the restriction of C to Σprime denotedby CdarrΣprime via the procedure shown in see Table VII comparewith Table VI Observe that the states of the restriction cor-respond to sets of states of the original Modal Interface Therestriction aims at avoiding incompatibilities when consideringthe composition as the following lemma shows
Lemma 11 If C and CdarrΣprime are both consistent then so istheir compatible quotient CCdarrΣprime see Definition 12Proof Consider two alphabets Σ supe Σprime and a consistent C onalphabet Σ such that CdarrΣprime is also consistent The only casewhere quotient produces inconsistent states is whenever there
input CΣΣprime output Cprime
let proj(OpX) =if X has not been visitedthen
1 mark X visited2 for every α isin Σprime do
21 let Y = ε-closure(Σminus Σprime next(αX))22 let m = OpmC(q α) | q isin X23 add to Cprime a transition (Xα Y ) with modality m24 proj(Op Y )
done
let project(Op C) =1 let X0 = ε-closure(Σminus Σprime q0)2 set initial state of Cprime to X0
3 proj(OpX0)4 reduce Cprime5 return Cprime
let order (cannot maymustle) =
must le may
cannot le may
in CdarrΣprime= project(or C)
CdArrΣprime= project(and C)
Table VIALGORITHM FOR COMPUTING THE PROJECTIONS (37)
input CΣinΣoutΣprimeinΣprimeout output Cprime
let order(cannot maymustlein) = cannot lein may lein must
order(cannot maymustleout) =
must le may
cannot le mayin let rest(X) =
if X has not been visitedthen
1 mark X visited2 for every α isin Σprime do
21 let Y = ε-closure(Σminus Σprime next(αX))22 let m = OpmC(q α) | q isin X
where Op = if α isin Σprimein then orin else andout
23 add to Cprime a transition (Xα Y ) with modality m24 rest(Op Y )
done
let restrict(C) =1 let X0 = ε-closure(Σminus Σprime q0)2 set initial state of Cprime to X0
3 rest(OpX0)4 reduce Cprime5 return Cprime
Table VIIALGORITHM FOR COMPUTING THE RESTRICTION CdarrΣprime
exists an action e and a state pair (qR) in CCdarrΣprime such thate has modality must in q and does not have modality mustin R We prove by contradiction that no such reachable statepair (qR) and action e exist Remark that by definition of therestriction q isin R The restriction is assumed to be in reducedform meaning that it does not contain inconsistent states Twocases have to be considered
1) Action e has modality cannot in R Several sub-caseshave to be considered depending on the IO status ofe and on the fact that the reduction of the restrictionhas turned a may modality for e into a cannot In allcases action e has modality cannot or may in q which
RR ndeg 8147
Contracts for System Design 40
contradicts the assumption2) Action e has modality may in R This implies that e also
has modality may in q which contradicts the assumptionThis finishes the proof of the lemma 2
The following holds by Lemma 10
CdarrΣprime otimes (CCdarrΣprime ) CCCdarrΣprime has no inconsistent state
(CdarrΣprime CCdarrΣprime ) has no incompatible pair of states(40)
By Lemma 11 the only property for checking is the consis-tency of CdarrΣprime This is a significant improvement comparedto the issues raised by the refined projection as explained inthe paragraph following (39) Decomposition (40) can be usedwhile sub-contracting through the following algorithm
Algorithm 1 We are given some system-level contract CThe top-level designer guesses some topological architectureaccording to (35) Then she recursively decomposes
C = C0 C0darrΣ1otimes C1
C0darrΣ1otimes C1darrΣ2
otimes C2 C0darrΣ1
otimes otimes Cnminus1darrΣn
=def C(Σ1) otimes otimes C(Σn)
(41)
which ultimately yields a refinement of C by a compatiblecomposition of local sub-contracts 2
Discussion The operations of projection and restrictionthat we introduced here can probably be made be genericat the level of the meta-theory Observe however that suchoperations explicitly refer to the notion of sub-alphabet whichdoes not exist at the level of the meta-theory In additionModal Interfaces are the only concrete theory in which variablealphabets are properly supported For these two reasons wepreferred to develop these operations for Modal Interfacesonly
F Observers
Here we develop observers for a Modal InterfaceC = (ΣinΣout Q q0rarr 99K) having no inconsistent statemeaning that rarrsube99K With this consistency assumption inforce observers are then obtained as follows with referenceto Definition 2bull Condition 2 of Definition 7 boils down to requiring thatE times Cmust simulates E Simulation testing can thus beused to check this call bE
C(E) the corresponding verdictbull To test for implementations we first construct the max-
imal environment EC and apply testing to check sim-ulation of EC times M by Cmay call bM
C1 the corre-sponding verdict Performing this requires maintainingpairs of states ((qE qM ) (qE q)) in simulation relation(qE qM )le(qE q) For any such pair of states let bM
C2 de-note the verdict answering whether (qE qM )
αminusrarrECtimesMholds each time q αminusrarr holds for any α isin Σout Theoverall verdict for implementation testing is then
bMC1(EC timesM) and bM
C2(EC timesM)
Lemma 3 for generic observers specializes to the followingeffective semi-decision procedure
Lemma 121) If bE
C outputs F then C is incompatible2) If bM
C1 and bMC2 outputs F then C is inconsistent
G Bibliographical note
As explained in [72] [56] [127] [83] [165] [166] Inter-face Theories make no explicit distinction between assump-tions and guarantees
Interface Automata variants and extensions InterfaceAutomata were proposed by de Alfaro and Henzinger [72][70] [5] [54] as a candidate theory of interfaces In thesereferences Interface Automata focused primarily on parallelcomposition and compatibility Quoting [72]
ldquoTwo interfaces can be composed and are compatibleif there is at least one environment where they canwork togetherrdquo
The idea is that the resulting composition exposes as aninterface the needed information to ensure that incompatiblepairs of states cannot be reached This can be achieved byusing the possibility for a component to refuse selectedinputs from the environment at a given state [72] [56] Incontrast to our development in Section VIII-B no sets ofenvironments and implementations are formally associated toan Interface Automaton in the original developments of theconcept A refinement relation for Interface Automata wasdefined in [72]mdashwith the same definition as oursmdashit couldnot however be expressed in terms of sets of implementationsProperties of interfaces are described in game-based logicseg ATL [9] with a theoretical high-cost complexity Theoriginal semantics of an Interface Automaton was given by atwo-player game between an input player that represents theenvironment (the moves are the input actions) and an outputplayer that represents the component itself (the moves are theoutput actions) Despite the availability of partial results [83]the framework of Interface Automata lacks support for theconjunction of interfaces in a general setting and does notoffer the flexibility of modalities Sociable Interfaces [71]combine the approach presented in the previous paragraphwith interface automata [72] [73] by enabling communicationvia shared variables and actions45 First the same actioncan appear as a label of both input and output transitionsSecondly global variables do not belong to any specificinterface and can thus be updated by multiple interfaces Con-sequently communication and synchronization can be one-to-one one-to-many many-to-one and many-to-many Symbolicalgorithms for checking the compatibility and refinement ofsociable interfaces have been implemented in TICC [3]Software Interfaces were proposed in [55] as a pushdownextension of interface automata (which are finite state) Push-down interfaces are needed to model call-return stacks ofpossibly recursive software components This paper contains
45This formalism is thus not purely synchronous and is mentioned in thissection with a slight abuse
RR ndeg 8147
Contracts for System Design 41
also a comprehensive interface description of Tiny OS46 anoperating system for sensor networks Moore machines andrelated reactive synchronous formalisms are very well suitedto embedded systems modeling Extending interface theoriesto a reactive synchronous semantics is therefore meaningfulSeveral contributions have been made in this direction startingwith Moore and Bidirectional Interfaces [56] In Moore Inter-faces each variable is either an input or an output and thisstatus does not change in time Bidirectional Interfaces offeradded flexibility by allowing variables to change IO statusdepending on the local state of the interface Communicationby shared variable is thus supported and for instance allowsdistributed protocols or shared buses to be modeled In bothformalisms two interfaces are deemed compatible wheneverno variable is an output of both interfaces at the same timeand every legal valuation of the output variables of oneinterface satisfies the input predicate of the other The mainresult of the paper is that parallel composition of compatibleinterfaces is monotonic with respect to refinement Note thatMoore and Bidirectional Interfaces force a delay of at leastone transition between causally dependent input and outputvariables exactly like Moore machines In [83] the frame-work of Synchronous Interfaces is enriched with a notion ofconjunction (called shared refinement) This development wasfurther elaborated in [78] In Moore interfaces legal values ofthe input variables and consequent legal values of the outputvariables are not causally related Synchronous Relational In-terfaces [177] [178] have been proposed to capture functionalrelations between the inputs and the outputs associated toa component More precisely inputoutput relations betweenvariables are expressed as first-order logic formulas over theinput and output variables Two types of composition are thenconsidered connection and feedback Given two relationalinterfaces C1 and C2 the first one consists in connecting someof the output variables of C1 to some of the input variablesof C2 whereas feedback composition allows one to connectan output variable of an interface to one of its own inputsThe developed theory supports refinement compatibility andalso conjunction The recent work [112] studies conditions thatneed to be imposed on interface models in order to enforceindependent implementability with respect to conjunctionFinally [53] develops the concept of simulation distancesfor interfaces thereby taking robustness issues into accountby tolerating errors Finally Web services Interfaces wereproposed in [38]
The discussion of variants and extensions related to timeresources and probability is deferred to corresponding sec-tions
Modal Interfaces variants and extensions Propertiesexpressed as sets of traces can only specify what is forbiddenUnless time is explicitly invoked in such properties it isnot possible to express mandatory behaviors for designsModalities were proposed by Kim Larsen [130] [11] [46] asa simple and elegant framework to express both allowed and
46httpwwwtinyosnet
mandatory properties Modal Specifications basically consist inassigning a modality may or must to each possible transition ofa system They have been first studied in a process-algebraiccontext [130] [125] in order to allow for loose specificationsof systems Since then they have been considered for automata[128] and formal languages [163] [164] and applied to a widerange of application domains (see [11] for a complete survey)Informally a must transition is available in every componentthat realizes the modal specification while a may transitionneeds not be A modal specification thus represents a set ofmodelsmdashunfortunately models of modal transition systems areoften call ldquoimplementationsrdquo in the literature which is unfor-tunate in our context We prefer keeping the term ldquomodelrdquoand reserve the term ldquoimplementationrdquo for the entities intro-duced in Sections VIII-B and VIII-C Modal Specificationsoffer built-in conjunction of specifications [129] [167] Theexpressiveness of Modal Specifications has been characterizedas a strict fragment of the Hennessy-Milner logic in [46]and also as a strict fragment of the mu-calculus in [89] Theformalism is rich enough to specify safety properties as well asrestricted forms of liveness properties Modal Interfaces withthe right notion of compatibility were introduced in [165][166] and the problem of alphabet equalization with weakand strong alphabet extensions was first correctly addressed inthe same references In [23] compatibility notions for ModalInterfaces with the passing of internal actions are definedContrary to the approach reviewed before a pessimistic viewof compatibility is followed in [23] ie two Modal Interfacesare only compatible if incompatibility between two interfacescan occur in any environment A verification tool called MIOWorkbench is available The quotient of Modal Specificationswas studied in [124] [164] Determinism plays a role in themodal theory Non-deterministic Modal Interfaces have pos-sibly non-deterministic io-automata as class of componentsThey are much more difficult to study than deterministic onesand corresponding computational procedures are of highercomplexity A Modal Interface is said to be deterministic if itsmay-transition relation is deterministic For nondeterministicModal Interfaces modal refinement is incomplete [128] thereare nondeterministic Modal Interfaces C1 and C2 for whichthe set of implementations of C1 is included in that of C2without C1 being a modal refinement of C2 Hence refinementaccording to the meta-theory is not exactly instantiated butonly approximated in a sound way A decision procedure forimplementation inclusion of nondeterministic Modal Interfacesdoes exist but turns out to be EXPTIME-complete [12] [25]whereas the problem is PTIME-complete if determinism isassumed [167] [26] The benefits of the determinism assump-tion in terms of complexity for various decision problemson modal specifications is underlined in [26] The ldquomergerdquoof non-deterministic Modal Specifications regarded as partialmodels has been considered in [179] This operation consistsin looking for common refinements of initial specifications andis thus similar to the conjunction operation presented hereIn [179] [90] algorithms to compute the maximal commonrefinements (which are not unique when non-determinism is
RR ndeg 8147
Contracts for System Design 42
allowed) are proposed They are implemented in the toolMTSA [82] Assumeguarantee contracts viewed as pairs ofModal Specifications were proposed in [96] It thus com-bines the flexibility offered by the clean separation betweenassumptions and guarantees and the benefits of a modalframework Several operations are then studied refinementparallel composition conjunction and priority of aspects Thislast operation composes aspects in a hierarchical order suchthat in case of inconsistency an aspects of higher priorityoverrides a lower-priority contract The synthesis of ModalInterfaces from higher-level specifications has been studiedfor the case of scenarios In [173] Existential Live SequenceCharts are translated into Modal Specifications hence provid-ing a mean to specify modal contracts Regarding extensionsAcceptance Interfaces were proposed by J-B Raclet [163][164] Informally an Acceptance Interface consists of a set ofstates with for each state a set of ready sets where a readyset is a set of possible outgoing transitions from that stateIn intuitive terms an Acceptance Interface explicitly specifiesits set of possible models Acceptance Interfaces are moreexpressive than Modal Interfaces but at the price of a pro-hibitive complexity for the various relations and operators ofthe theory Modal Interfaces have been enhanced with markedstates by Caillaud and Raclet [27] Having marked statessignificantly improves expressiveness It is possible to specifythat some state must be reachable in any implementation whileleaving the particular path for reaching it unspecified As anexample of use Modal Interfaces with marked states have beenapplied in [4] to the separate compilation of multiple clockedsynchronous programs
The discussion of variants and extensions related to timeresources and probability is deferred to corresponding sec-tions
Features of our presentation The presentation of in-terface theories in this paper is new in many aspects Forthe first time all interface theories are clearly cast in theabstract framework of contracts following our meta-theory Inparticular the association to an interface C of the two sets ECandMC is new It clarifies a number of concepts In particularthe interface theories inherit from the properties of the meta-theory without the need for specific proofs The projectionand restriction operators for Modal Interfaces are new Castinginterface theories into the meta-theory was developed for thebasic interface theories only It would be useful to extend thisto the different variants and see what the benefit would beBenoicirct Caillaud has developed the MICA tool [49] whichimplements Modal Interfaces with all the operations andservices discussed in this section
IX PANORAMA TIMED INTERFACE THEORIES
In this section we develop an instance of an interface theoryfor timed systems This section is meant to be illustrative ofour approach to concrete instances of contract theories It doesnot claim to expose the good instance Our presentation buildson top of [35] To simplify the exposure we restrict ourselves
to the case of a fixed alphabet Σ As usual now we begin withthe component model
A Components as Event-Clock Automata
Timed Automata [6] constitute the basic model for systemsdealing with time and built on top of automata In wordstimed automata are automata enhanced with clocks Predicateson clocks guard both the states (also called ldquolocationsrdquo) andthe transitions Actions are attached to transitions that resultin the resetting of some of the clocks
Event-Clock Automata [7] [8] [35] form a subclass oftimed automata where clock resets are not arbitrary eachaction α comes with a clock hα which is reset exactlywhen action α occurs The interest of this subclass is thatevent-clock automata are determinizable which facilitates thedevelopment of a (modal) theory of contracts The definitionof event-clock automata requires some prerequisites
We are given an underlying finite set H of clocks A clockvaluation is a map ν H 7rarr R+ where R+ denotes the set ofnonnegative reals The set of all clock valuations is denotedby V We denote by 0 the clock valuation assigning 0 to allclocks and by ν + t the clock obtained by augmenting ν withthe constant t For ν a valuation the valuation ν[0hα] assigns0 to hα and keeps the valuation of other clocks unchanged
Clocks can be used to define guards The class of guardsconsidered by [35] consists of finite conjunctions of expres-sions of the form h sim n where h is a clock n is an integerand sim is one of the following relations ltle=ge gt Forg a guard write ν |= g to mean that valuation ν satisfiesguard g For N an integer G(H N) denotes the set of allguards over H involving only integers n lt N + 1 and wewrite G(H) = G(Hinfin)
Definition 13 An event-clock automaton over alphabet Σis a tuple M = (ΣinΣout Q q0 Nrarr) wherebull ΣinΣout Q q0 are as for io-automata elements of Q
are called locationsbull HΣ = hα | α isin Σ is the set of clocksbull N is a finite integer and rarrsube Q times G(HΣ N) times Σ times Q
is the transition relation write qgαminusrarr qprime to mean that
(q g α qprime) isinrarr
The semantics of M is a timed transition system with infinitestate space QtimesV defined as follows transition q
gαminusrarr qprime canfire from state (q ν) isin Q times V iff ν |= g as a result of thisfiring the clock hα is reset to zero thus resulting in the newstate (qprime ν[0hα]) isin Q times V In our Timed Interface theorycomponents are event-clock automata that are
1) deterministic in the following sense
forall(q α ν) isin Qtimes Σtimes V there is at mostone transition q
gαminusrarr qprime such that ν |= g(42)
2) receptive meaning that
forallq isin Qforallα isin Σin qTαminusrarr
holds where T denotes the trivial guard ldquotruerdquo
RR ndeg 8147
Contracts for System Design 43
Instead of further developing our theory we will show how totake advantage of previously developed theories by showingthat event-clock automata are finitely encoded by means of re-gion automata that we introduce next Fix bound N A regionis an equivalence class ϑ of clock valuations ν satisfying thesame set of guards from G(H N) Denote by Θ the set of allsuch regions (bound N is understood) For ϑ isin Θ consider
τ(ϑ) = ϑprimeprime | existνprimeprime isin ϑprimeprimeexistν isin ϑexistt ge 0 st νprimeprime = ν + t
which is the set of all regions that can be obtained from ϑ byletting time elapse Finally for ϑ a region and α an actionϑdarrα is the region obtained from ϑ by resetting clock hα Usingthese notations we associate to each event-clock automatonM = (ΣinΣout Q q0 Nrarr) a Region Automaton which isthe following finite state automaton
R [M ] =(Σin timesΘΣout timesΘ QtimesΘ (q00)rArr
)(43)
where the transition relation rArr is given by
(q ϑ)ϑrdquoα
===rArr (qprime ϑprime) iff
q gαrarr qprime withϑrdquo sube τ(ϑ) cap g andϑprime = ϑrdquodarrα
(44)
Vice-versa any Region Automaton R defines a uniqueevent-clock automaton M [R] by deducing from (44) theminimal guards associated to its transitions Starting from anevent-clock automaton M M [R [M ]] is related to M by astrengthening of its guards However it holds that47
R [M [R [M ]]] = R [M ] (45)
Under the above correspondence components in theevent-clock automaton domain are mapped to components inthe io-automaton domain
B Modal Event-Clock Specifications
In this section we develop the framework of con-tracts on top of our component model of deterministicevent-clock automata To simplify we only develop the caseof a fixed alphabet Σ
Definition 14 A Modal Event-Clock Specification (MECS)is a tuple C = (ΣinΣout Q q0rarr 99K) where ΣinΣoutQ q0 are as in Interface Automata and
rarr sube 99K sube Qtimes G(HΣ)times ΣtimesQ
Using the same construction as above MECS C induces aRegion Modal Event-Clock Specification (RMECS) denoted byR [C] which is a Modal Interface according to Definition 7Accordingly R [C] defines a pair (ER[C]
MR[C]) of sets of
io-automata and we finally define
(EC MC ) =def
(M[ER[C]
]M[MR[C]
])The map C 7rarr R [C] satisfies48
R [M [R [C]]] = R [C] (46)
47It is shown in [35] that M 7rarr R [M ] forms a Galois connection48Again it is a Galois connection [35]
This allows us to lift the contract theory of RMECS (whichare Modal Interfaces) to a contract theory of MECS Whilethis is conceptually elegant it is not efficient since movingfrom MECS to RMECS (from timed models to region models)is ExpTime which is costly To cope with this difficulty theauthors of [35] have provided direct cheap formulas expressedin the MECS domain These formulas provide a partial answerto the issue of complexity In particular the following lemmaholds that was stated and proved in [35]
Lemma 13 For C1 and C2 two MECS having identical inputand output alphabets define C1andC2 symbolically with rules ofthe following form
Glbmay q1
g1α99K qprime1 and q2
g2α99K qprime2
(q1 q2)g1andg2α99K (qprime1 q
prime2)
Glbmustleft q1
g1αrarr qprime1 and q2g2α qprime2
(q1 q2)g1andg2αrarr (qprime1 q
prime2)
where denotes ad libitumrarr or 99K and with Glbmustright
defined symmetrically (see [35] for the complete set of rules)Then we have
R [C1andC2] = R [C1]andR [C2] (47)
Inconsistent states for both sides of (47) correspond A similarlemma holds for contract quotient C1C2 Unfortunately thepruning of inconsistent states cannot be performed directlyin the MECS domain and mapping to regions is mandatoryNevertheless dedicated rules to handle directly inconsistentstates exist in the symbolic versions of the different relationsand operations on MECS As a result the computation ofthe regions is only mandatory when the designer aims atcleaning its contract by pruning the inconsistencies A similarlemma holds for contract composition C1otimesC2 Again pruningincompatible pairs of states cannot be performed directly inthe MECS domain and mapping to regions is mandatory49
C Bibliographical note
This note focuses on interface types of framework Thereader is referrect to the bibliographical note of Section VII-Gfor extensions of AG-contracts addressing time
A first interface theory able to capture the timing aspectsof components is Timed Interfaces [74] Timed Interfacesallows specifying both the timing of the inputs a componentexpects from its environment and the timing of the outputsit can produce Compatibility of two timed interfaces is thendefined and refers to the existence of an environment such thattiming expectations can be met The Timed Interface theoryproposed in [68] fills a gap in the work introduced in [74]by defining a refinement operation In particular it is shownthat compatibility is preserved by refinement This theoryalso proposes a conjunction and a quotient operation and is
49Authors of [35] do not mention this fact for the following reason Theydo not consider the issue of receptiveness for components and therefore theissue of compatibility does not arise
RR ndeg 8147
Contracts for System Design 44
implemented in the tool ECDAR [69] Timed SpecificationTheories are revisited from a linear-time perspective in [60]
The first timed extension of modal transition systems waspublished in [52] It is essentially a timed (and modal) versionof the Calculus of Communicating Systems (by Milner) Basedon regions tool support for refinement checking were imple-mented and made available in the tool EPSILON [95] Anothertimed extension of Modal Specifications was proposed in [36]In this formalism transitions are equipped with a modality anda guard on the component clocks very much like in timedautomata For the subclass of modal event-clock automataan entire algebra with refinement conjunction product andquotient has been developed in [33] [34]
Resources other than time were also consideredmdashwithenergy as the main target Resource Interfaces [57] can beused to enrich a variety of interface formalisms (InterfaceAutomata [72] AssumeGuarantee Interfaces [73] etc) witha resource consumption aspect Based on a two player game-theoretic presentation of interfaces Resource Interfaces allowfor the quantitative specification of resource consumptionWith this formalism it is possible to decide whether compo-sitions of interfaces exceed a given resource usage thresholdwhile providing a service expressed either with Buumlchi condi-tions or thanks to quantitative rewards Because resource usageand rewards are explicit rather then being defined implicitlyas solutions of numerical constraints this formalism doesnot allow one to reason about the variability of resourceconsumption across a set of logically correct models
X PANORAMA PROBABILISTIC INTERFACE THEORIES
Probabilistic systems are non-deterministic systems inwhich choice is controlled by random trial Such systems areuseful for many purposes ranging from physical or biologicalsystems to security protocols intrusion detection and up tosafety and reliability analyses in system design In this sectionas another illustration of our meta-theory we develop a simpleinstance of a probabilistic interface theory Again to simplifythe exposure we restrict ourselves to the case of a fixedalphabet Σ
A Components as Probabilistic Automata
We first introduce Probabilistic Automata with inputs andoutputs also called InputOutput Markov Decision Processesand then we motivate their use in safety analysis
Definition 15 A Probabilistic Automaton with inputs andoutputs (io-PA) is a tuple M = (ΣinΣout Q q0Πrarr)wherebull Σin and Σout are disjoint finite input and output alpha-
bets such that Σin cup Σout = Σbull Q is a finite set of states and q0isinQ is the initial state
we denote by Π(Q) the finite set of all probabilities overQ also called the probabilistic states
bull rarr sube Qtimes ΣtimesΠ(Q) is the transition relation we writeq
αminusrarr π to mean (q α π) isinrarr and q αminusrarr if q αminusrarr πholds for some π
bull In addition we require M to be deterministic in thefollowing sense for any pair (q α) isin Q times Σ q αminusrarr πand q αminusrarr πprime implies π = πprime
A run σ of M starts from initial state q0 and then progressesby a sequence of steps of the form q
αminusrarr π 7rarr qprime wheresupplementary transitions π 7rarr qprime are drawn at random byselecting a successor state qprime isin Q according to probabilityπ A strategy consists in fixing a function ϕ Q rarr Σand using it to select the next action Once a strategy hasbeen fixed jumping from a probabilistic state to the next onegives raise to a time-invariant Markov Chain whose invariantprobability can be computed or statistically estimated Whenall probabilistic states are Dirac measures δqprime selecting qprime asa next state with probability one io-PA M boils down to anio-automaton Thus io-PA subsume io-automata
Two io-PA M1 and M2 are composable if Σout1 capΣout
2 = emptyTwo composable io-PA M1 and M2 compose into M = M1timesM2 as follows
(q1 q2)αminusrarrM π1 otimes π2 iff
q1
αminusrarrM1π1 and
q2αminusrarrM2
π2(48)
where otimes denotes the product of two probabilities thus makingthe two components independent Parallel composition definedin this way has all the desired properties
Similarly the concept of simulation relation is easily de-rived from that of io-automata by preserving probabilitiesfor Mi i = 1 2 two io-PA and two states qi isin Qi say that q1
simulates q2 written q2le q1 if there exists a surjective mapf Q1 7rarr Q2 such that
forallα st q2αminusrarr2 π2 existπ1 isin Π(Q1)
dArr (49) q1αminusrarr1 π1
π2(qprime2) =sumf(qprime1)=qprime2
π1(qprime1)
π1(qprime1) gt 0rArr f(qprime1) le qprime1
Observe that since we consider only deterministic io-PAthere exists at most one π2 such that q2
αminusrarr2 π2 hence thereis no need to quantify over π2 in the precondition of (49) Inprobability theory relation π2(qprime2) =
sumf(qprime1)=qprime2
π1(qprime1) writesπ2 = f(π1) Say that M1 simulates M2 written M2leM1 ifq20leq10 Simulation relation is preserved by composition IfM2leM1 then every strategy ϕ2 Q2 7rarr Σ2 defined over M2
has its counterpart into a matching strategy ϕ1 Q1 7rarr Σ1
over M1 by setting ϕ1(q1) = ϕ2(f(q1)) For i = 1 2 letΩi = QN
i be the set of all sequences of states of Qi and let(ΩiPi) i = 1 2 be the two resulting probability spaces whenmatching strategies are used for M1 and M2 Then the mapf induces a measurable map ψ = (f f ) Ω1 7rarr Ω2 suchthat
intZ(ω2)dP2(ω2) =
intZ(ψ(ω1))dP1(ω1) In particular
the probability distributions with respect to P1 and P2 of anymeasurable function depending only on the successive actionsperformed are identical
The natural use of io-PAs for safetyreliability analysis isto capture faulty situations through states Component states
RR ndeg 8147
Contracts for System Design 45
are partitioned into safe states and faulty states that can beequipped with different fault labels (names of states can dothis no semantic adaptation is needed) The probabilistic partof io-PAs naturally captures the spontaneous occurrence offaults When in a faulty state a component outputs actionsthat can either be used to model fault propagation or maybe alarms for use in system supervision Input actions in afaulty state can be used to either model denial of servicefrom other components (thus resulting in a risk of movingto a faulty state) or may be reconfiguration actions Thusspontaneous occurrence of failures with fault propagation iscaptured by this framework To summarize io-PAs offer anatural framework in which to combine functional and safetyviewpoints
B Simple Modal Probabilistic Interfaces
By following the same steps as for Modal Interfacessee Definition 7 we can define Simple Modal ProbabilisticInterfaces as pairs C = (Cmay Cmust) of io-PAs There is nonew difficulty in doing this Expressiveness of this frameworkhowever is modest whence the attribute ldquosimplerdquo When usedin the context of safetyreliability analysis Simple ModalProbabilistic Interfaces support the specification of fault ac-commodation in systems For example one can specify abouta componentbull that it does not accommodate denial of service inputs
representing fault propagation are disallowed (ldquomust notoccurrdquo)
bull that it must be prepared to possible denial of serviceinputs representing fault propagation are allowed (ldquomustbe acceptedrdquo)
bull that it never generates spontaneous failures actions lead-ing to a probabilistic state from which a faulty state can beimmediately reached are disallowed (ldquomust not occurrdquo)
bull that spontaneous failures are unavoidable actions leadingto a probabilistic state from which a faulty state can beimmediately reached are allowed (ldquomust be acceptedrdquo)
One could argue that io-PA by themselves offer a similarexpressiveness by playing with probabilities Simple ModalProbabilistic Interfaces however offer the full algebra ofcontracts which io-PA donrsquot
C Bibliographical note
This note focuses on interface types of framework Thereader is referred to the bibliographical note of Section VII-Gfor extensions of AG-contracts addressing probability
Exactly like the Interval Markov Chain (IMC) for-malism [116] they generalize Constraint Markov Chains(CMC) [50] are abstractions of a (possibly infinite) sets ofDiscrete Time Markov Chains Instead of assigning a fixedprobability to each transition transition probabilities are keptsymbolic and defined as solutions of a set of first orderformulas Variability across implementations is made possiblenot only with symbolic transition probabilities but also thanksto the labelling of each state by a set of valuations or setsof atomic propositions This allows CMCs to be composed
thanks to a conjunction and a product operators While theexistence of a residuation operator remains an open problemCMCs form an interface theory in which satisfaction andrefinement are decidable and compositions can be computedusing quantifier elimination algorithms In particular CMCswith polynomial constraints form the least class of CMCsclosed under all composition operators Abstract ProbabilisticAutomata (APA) [79] is another specification algebra withsatisfaction and refinement relations product and conjunctioncomposition operators Despite the fact that APAs generalizeCMCs by introducing a labeled modal transition relationdeterministic APAs and CMCs coincide under the mild as-sumption that states are labeled by a single valuation Forboth formalisms parallel composition is restricted to non-interacting components since alphabets of actions must bedisjoint
Our formalism of Simple Modal Probabilistic Interfaces ex-hibits the whole contract algebra Regarding limitations unlikeIMC CMC and APA this model does not allow for specifyingfamilies of transition probabilities and hence it cannot helpfor quantitative reasoning about reliability analysis
XI THE PARKING GARAGE AN EXAMPLE INREQUIREMENTS ENGINEERING
In this section we develop the parking garage exampleintroduced in Section IV-C Some of the material is repeatedfor better readability Despite being simple and small this ex-ample quickly becomes complex for reasons that are intrinsicto the formal management of requirements The MICA tooldeveloped by Benoicirct Caillaud was used to develop it [49]
Requirements are written in constrained English languageand then translated into Modal Interfacesmdashwhile the pre-sented translation is manual automatic translation can beenvisioned50 Once this is completed contracts are formallydefined and the apparatus of contracts can be used In par-ticular important properties regarding certification can beformally defined and checked eg consistency compatibilitycorrectness and completeness In addition support is providedfor turning top-level requirements into an architecture of sub-systems each one equipped with its own requirements Thelatter can then be submitted to independent suppliers forfurther development
A The contract framework
We shall use Modal Interfaces (with variable alphabet) asdeveloped in Sections VIII-C and subsequent ones There arethree main reasons for this choice
1) By offering the may and must modalities Modal Inter-faces are well suited to express mandatory and optionalbehaviors in the specification which we consider impor-tant for requirements engineering
50In fact the contract specification languages proposed in the projectsSPEEDS [29] and CESAR (httpwwwcesarprojecteu) are examples oftranslations from a constrained English language to a formal models ofcontracts similar to Modal Interfaces
RR ndeg 8147
Contracts for System Design 46
2) Being large sets of requirements structured into chaptersrequirements documents are a very fragmented style ofspecification Only Modal Interfaces offer the neededsupport for an accurate translation of concepts such asldquoset of requirementsrdquo ldquoset of chaptersrdquo together with aqualification of who is responsible for each requirement(the considered component or sub-system versus itsenvironment)
3) As we shall see at the top-level conjunction prevailsHowever as soon as the designer refines the top-levelrequirements into an architecture of sub-systems com-position enters the game Turning a conjunction of top-level requirements into a composition of sub-systemsspecifications thus becomes a central task Only ModalInterfaces provide significant assistance for this
Overall the problem considered in claim 3) can be stated asfollows The designer begins with some system-level contractC which is typically specified as a conjunction of viewpointsandor requirements The designer guesses some topologicalarchitecture by decomposing the alphabet of actions of C as
Σ =⋃iisinI Σi Σi = Σin
i ] Σouti (50)
such that composability conditions regarding inputs and out-puts hold Once this is done we expect our contract frameworkto provide help in generating a decomposition of C asotimes
iisinI Ci C (51)
where sub-contract Ci has alphabet Σi = Σini ] Σout
i Guess-ing architectural decomposition (50) relies on the designerrsquosunderstanding of the system and how it should naturallydecomposemdashthis typically is the world of SysML Findingdecomposition (51) is however technically difficult in that itinvolves behaviors The algorithmic means that were presentedin Section VIII-E provide the due answer In this ParkingGarage example we will use both the abstracted projectionand the restriction that were developed in that section
B Top level requirements
In this section we begin with the top-level requirementsThe system under specification is a parking garage subjectto payment by the user At its most abstract level the re-quirements document comprises the different chapters gatepayment and supervisor see Table VIII The gate chapterwill collect the generic requirements regarding entry and exitgates These generic requirements will then be specialized forentry and exit gates respectively
0
gate_close
1gate_opengate_close
vehicle_passgate_open
Figure 7 Requirement Rg1 specified as an io-automaton Prefix ldquordquoindicates an input and prefix ldquordquo indicates an output
gateRg1ldquovehicles shall not pass when gate is closedrdquo see Fig 7Rg2 after vehicle_pass vehicle_pass is forbiddenRg3 after gate_open gate_open is forbidden and
after gate_close gate_close is forbiddenpaymentsupervisor
Table VIIITHE TOP-LEVEL SPECIFICATION WITH CHAPTER gate EXPANDED
REQUIREMENTS WRITTEN IN italics ARE ASSUMPTIONS UNDER WHICHgate SHOULD OPERATE
Focus on the ldquogaterdquo chapter It consists of the three re-quirements shown on Table VIII Requirement Rg1 is bestdescribed by means of an io-automaton shown in Figure 7mdashwe provide an informal textual explanation for it betweenquotes51 The other two requirements are written using con-strained natural language which can be seen as a boilerplatestyle of specification Prefix ldquordquo indicates an input and prefixldquordquo indicates an output
The first two requirements are not under the responsibilityof the system since they rather concern the car driver Thus itdoes not make sense to include them as part of the guaranteesoffered by the system Should we remove them This wouldbe problematic If drivers behave the wrong way unexpectedthings can occur for sure The conclusion is that 1) we shouldkeep requirements Rg1 and Rg2 and 2) we should handlethem differently than Rg3 which is a guarantee offered by thesystem Indeed Rg1 and Rg2 are assumptions under whichthe gate operates as guaranteed In the sequel assumptions arewritten in italics
So far we have specified gate as a list of requirementsRequirement Rg1 specified as an io-automaton can be con-sidered formal Requirements Rg2 and Rg3 are formulatedin constrained natural language and are ready for subsequentformalization eg as io-automata Are we done Not yetWe need to give a formal meaning to what it means to havea collection of requirements and what it means to distinguishassumptions from guarantees The contract framework wedevelop next will provide support for this
C Formalizing requirements as contracts
We shall use Modal Interfaces (with variable alphabet) asdeveloped in Sections VIII-C and subsequent ones Thuswe first need to explain how the specification of ldquogaterdquo inTable VIII translates into Modal Interfaces
We first observe that each requirement Rgj of Table VIIIis a sentence that can be formalized as an io-automaton see
51 We take the convention that the variables of the resulting io-automatonare those mentioned in the text of the requirement Some adjustment is neededto this convention however as exemplified by Figure 7 Suppose that somerequirement says ldquogate_open never occursrdquo This is translated by havingno mention of gate_open in the corresponding io-automaton To expressthis ldquonegativerdquo fact we must keep track of the fact that gate_open belongsto the alphabet of actions of the io-automaton Thus when performing thetranslation the explicit list of inputs and outputs should be explicitly givenTo avoid such additional notational burden we have cheated by omitting thisunless necessary
RR ndeg 8147
Contracts for System Design 47
Figure 7 for such a formalization of requirement Rg1 Ac-cordingly each chapter D = gatepaymentsupervisorof Table VIII is structured as a pair
D = ((A1 Am) (G1 Gn)) (52)
where the Ais (the assumptions) and the Gjs (the guarantees)are io-automata in which all involved actions possess thesame status (input or output) throughout all Ais and Gjs Thetranslation of a specification of the form (52) into a ModalInterface is performed by applying the following two series ofrules
Rules 1 We adopt the following rules for the translation ofguarantees (in the form of io-automata) into Modal InterfacesRG
1 Unless otherwise explicitly stated transitions labeledby an output action of the considered system are givena may modality the rationale for doing this is that thedefault semantics for guarantees is ldquobest effortrdquo A mustmodality is assigned if the requirement specifies itmdashegby having a ldquomustrdquo in the sentence
RG2 Transitions labeled by an input action of the considered
system are given a must modality the rationale for doingthis is that as part of its guarantees the component mustnot refuse an input that is ldquolegallyrdquo submitted by theenvironment
RG3 Guarantees in a same requirements chapter D combine
by conjunctionApplying Rules 1 to the set of guarantees of D yields thecontract encoding these guarantees denoted by GD 2
Performing this for the single guarantee Rg3 of gate yieldsthe Modal Interface shown in Figure 8
0 1gate_opengate_close
0 1gate_opengate_close
Figure 8 Translating the guarantee Rg3 of gate as an io-automaton (top)and then as a Modal Interface Ggate (bottom) using Rules 1
Rules 2 We adopt the following rules for the translationof assumptions (in the form of io-automata) into ModalInterfacesRA
1 We exchange the status inputoutput in every assump-tion thus taking the point of view of the environment
RA2 Having done this we apply Rules 1 to the assumptions
So far this yields a draft Modal Interface A that must besatisfied by every environment
RA3 This is not enough however as we really want envi-
ronments that submit all legal stimuli To ensure this wesimply turn in A all may transitions to must transitionswhich yields A
Applying Rules 2 to the set of assumptions of D yields theModal Interface AD encoding these assumptions 2
Performing this for the assumptions Rg1 and Rg2 of gateyields the Modal Interface shown in Figure 9
1 0
gate_close
1gate_opengate_close
gate_openvehicle_pass
2 0
gate_open
1vehicle_passgate_open
3 (11)
gate_close
(10)
gate_opengate_closevehicle_pass
gate_open
4 0
gate_close
1gate_openvehicle_passgate_close
gate_open
Figure 9 Translating the assumptions of gate as a Modal Interface Agate
using Rules 2 1 translation of Rg1 2 translation of Rg2 3 the resultingconjunction 4 the final result after applying rule RA
3 and renaming the states
So far we have represented any chapter D of the require-ments document as a pair of Modal Interfaces (AD GD) withmirroring inputoutput statuses for their actionsmdashevery inputof AD is an output of GD and vice-versa It is the merit ofModal Interfaces to allow for a direct representation of thispair of assumption and guarantee in the form of a single ModalInterface by using the following formula for A and G twoModal Interfaces with mirroring inputoutput statuses for theiractions
(AG) is represented by the quotient (AotimesG)A (53)
which is the contract characterizing the components thatimplement G in the context of A see Section V-E Performingthis for the whole chapter gate yields the Modal Interfaceshown in Figure 10 Some comments are in order regardingthis Modal Interfacebull Regarding the guarantees offered by the component
Allowed outputs possess a may modality which reflectsthat Guarantees specify what the component may deliverOther actions are forbidden
bull Regarding the context of operation Legal inputs to thegate (eg vehicle_through when exiting state ldquo1rdquo) havea must modality This complies with the intuition that
RR ndeg 8147
Contracts for System Design 48
gate(x) where x isinentry exitRg1(x) ldquovehicles shall not pass when x_gate is closedrdquo see Fig 7Rg2(x) after vehicle_pass vehicle_pass is forbiddenRg3 after x_gate_open x_gate_open is forbidden and after x_gate_close x_gate_close is forbidden
paymentRp1 ldquouser inserts a coin every time a ticket is inserted and only thenrdquo Fig omittedRp2 ldquouser may insert a ticket only initially or after an exit ticket has been issuedrdquo Fig omittedRp3 ldquoexit ticket is issued after ticket is inserted and payment is made and only thenrdquo Fig omitted
supervisorRg1(entry)Rg1(exit)Rg2(entry)Rg2(exit)Rs1 initially and after entry_gate close entry_gate open is forbiddenRs2 after ticket_issued entry_gate open must be enabledRs3 ldquoat most one ticket is issued per vehicle entering the parking and tickets can be issued only if requested
and ticket is issued only if the parking is not fullrdquo see Fig 12Rs4 ldquowhen the entry gate is closed the entry gate may not open unless a ticket has been issuedrdquo Fig omittedRs5 ldquothe entry gate must open when a ticket is issuedrdquo Fig omittedRs6 ldquoexit gate must open after an exit ticket is inserted and only thenrdquo Fig omittedRs7 ldquoexit gate closes only after vehicle has exited parkingrdquo Fig omitted
Table IXREQUIREMENTS FOR THE TOP-LEVEL
0
1vehicle_pass
2gate_open
vehicle_passgate_closegate_open
gate_close3vehicle_pass
gate_close
vehicle_pass
Figure 10 Chapter gate of the top-level requirements document translatedinto a Modal Interface Cgate
the component should not refuse legal stimuli from itsenvironment Violation of the contract by its environmentoccurs when an illegal input is submitted by the environ-ment (vehicle_through when exiting state 0 or state 3) Asa consequence the whole contract gets relaxed which isreflected by the move to the special state ldquo2rdquo from whichany action is allowedmdashsuch a state is often called a ldquotoprdquostate Note that this top state resulted from computing thequotient
The same procedure applies to all chapters gate paymentand supervisor of the top-level textual specification shownin Table IX (it is an expansion of Table VIII) In particu-lar the Modal Interfaces encoding chapters payment andsupervisor of the top-level are displayed in Figures 11 to 13Figure 13 showing the contract associated to the supervisor isunreadable and the reader may wonder why we decided to putit here We indeed wanted to show that when contract designis performed formally and carefully top-level contracts rapidlybecome complex even for modest sets of requirements So theformal management of requirements and their translation intoformal contracts must be tool-assisted
Finally the whole top-level contract C is the conjunctionof the contracts representing chapters gate payment and
supervisor of the top-level requirements document
C = Cgate and Cpayment and Csupervisor (54)
Owing to the complexity of Csupervisor shown in Figure 13we do not show the Modal Interface C formalizing the fulldocument Nevertheless the latter was generated and can thenbe exploited as we develop next The above specificationonly covers the functional viewpoint of the system Otherviewpoints might be of interest as well eg regarding timingbehavior and energy consumption They would be developedwith the same method and combined to the above contract Cusing conjunction
D Sub-contracting to suppliers
In this section we apply the technique developed in Sec-tion VIII-E for generating an architecture of sub-systems withtheir associated sets of requirements Each sub-system canthen be submitted for independent development to a differentsupplier
The duty of the designer is to specify an architecture ldquoagravela SysMLrdquo as shown on Figure 14 Some comments arein order regarding this architecture The considered instanceof a parking garage consists of one entry gate one exitgate and one payment machine Compare with the top-levelspecification of Table IX The latter comprises a generic gatea payment machine and a supervisor each one with its setof requirements In contrast the architecture of Figure 14involves no supervisor The supervisor is meant to be dis-tributed among the two gates The architecture of Figure 14seems to be very loosely coupled First the PaymentMachineseems to be totally independent In fact the ticket that isinserted in the exit gate must coincide with the one issued bythe PaymentMachine It turns out that this reflects a missingassumption regarding the environment of the system (namelythe user of the parking) Then the two gates seem to have the
RR ndeg 8147
Contracts for System Design 49
0 1ticket_insert_payment 2
coin_insert_paymentticket_insert_payment
3
coin_insert_payment
ticket_insert_paymentcoin_insert_paymentexit_ticket_issue
exit_ticket_issueticket_insert_paymentcoin_insert_payment
Figure 11 Chapter payment of the top-level requirements documenttranslated into a Modal Interface Cpayment
(a0)
vehicle_exit (b0)request_enter
(a1)vehicle_enter
request_entervehicle_exit
ticket_issue
vehicle_enter
vehicle_exit(b1)
request_enter
(a2)
vehicle_enter
vehicle_exitticket_issuerequest_enter
vehicle_enter
vehicle_exit
vehicle_enter
(b2)request_enter
vehicle_exit
vehicle_enter
request_enter
Figure 12 Modal Interface for Rs3
0
entry_gate_close
1
exit_ticket_insert
7
vehicle_entervehicle_exit
44
request_enter
entry_gate_closeexit_ticket_insert
2
exit_gate_open
vehicle_entervehicle_exit
43
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
3
request_enter
vehicle_enter
75
vehicle_exit
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
4
ticket_issue
vehicle_enter
72
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
vehicle_enter
5
vehicle_exit
11
entry_gate_open
exit_gate_openexit_ticket_insertexit_gate_closeentry_gate_closevehicle_enterentry_gate_openvehicle_exitrequest_enter
ticket_issue
vehicle_entervehicle_exit
exit_ticket_insertrequest_enter
6
exit_gate_open
8
exit_gate_close
59
entry_gate_open
vehicle_enter
vehicle_exit exit_ticket_insertrequest_enter
exit_gate_open
exit_gate_close
58
entry_gate_open
vehicle_entervehicle_exit
request_enter
9
exit_ticket_insert
45
entry_gate_open
exit_gate_open
vehicle_entervehicle_exitexit_ticket_insert
request_enter
10
entry_gate_open
vehicle_exit
entry_gate_openexit_ticket_insertrequest_enter
exit_gate_open
entry_gate_close
47
ticket_issue
68
vehicle_enter
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insertrequest_enter
12
ticket_issue
69
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
49
vehicle_enter
13
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
19
request_enter
77
entry_gate_open
50
vehicle_exit
vehicle_enter
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
20
entry_gate_open
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
21
ticket_issue
34
vehicle_enter
71
entry_gate_close
vehicle_exit
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
22
vehicle_enter
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
23request_enter
84
entry_gate_open
127
vehicle_exit
vehicle_enter
exit_ticket_insertrequest_enter
exit_gate_open
24
vehicle_exit
33
entry_gate_open
vehicle_entervehicle_exit
exit_ticket_insertrequest_enter
16
exit_gate_open
17
exit_gate_close
25
entry_gate_open
vehicle_enter
vehicle_exit
exit_gate_openexit_ticket_insertrequest_enter
exit_gate_close
26
entry_gate_open
vehicle_entervehicle_exit
request_enter
18
exit_ticket_insert
114
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
80
entry_gate_open
vehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
81ticket_issue
79
entry_gate_close
99
vehicle_enter
vehicle_exit
exit_gate_open
entry_gate_open
exit_ticket_insertrequest_enter
82vehicle_enter
vehicle_entervehicle_exitexit_gate_open
exit_ticket_insert
31
request_enter
83
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
32
entry_gate_open
vehicle_exitexit_ticket_insertrequest_enter
entry_gate_open
exit_gate_open
vehicle_enter
91
entry_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
vehicle_enter
92
entry_gate_close
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
35
request_enter
101
entry_gate_close
entry_gate_open
60
vehicle_exit
vehicle_enter
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
36
vehicle_exit
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
37
exit_gate_open
125
exit_gate_close
93
entry_gate_close
entry_gate_open
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
exit_gate_open
38
vehicle_exit
exit_gate_close
94
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
39
exit_gate_open
40
exit_gate_close
entry_gate_close
entry_gate_open
vehicle_enter
ticket_issue
vehicle_exitexit_ticket_insertrequest_enter
exit_gate_open
exit_gate_close
entry_gate_open
73entry_gate_close
vehicle_entervehicle_exit
ticket_issue
request_enter
41
exit_ticket_insert
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
ticket_issue
entry_gate_open
exit_ticket_insertrequest_enter
42
exit_gate_open
entry_gate_close
entry_gate_close
ticket_issue
vehicle_enter
entry_gate_open
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
exit_gate_open vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
exit_ticket_insert
entry_gate_close
request_enterentry_gate_open
46
ticket_issue
124
vehicle_enter
vehicle_exit
entry_gate_open
request_enter
exit_ticket_insert
126
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
48
vehicle_enter
vehicle_entervehicle_exit
exit_gate_open
request_enterexit_ticket_insert
113
entry_gate_open
vehicle_exit
request_enter
exit_ticket_insertentry_gate_open
exit_gate_open
105
entry_gate_close
vehicle_enter
request_enter
vehicle_enter
exit_ticket_insert
entry_gate_openexit_gate_open
56
vehicle_exit
74entry_gate_close
vehicle_exit
exit_ticket_insertentry_gate_open
57
exit_gate_open
entry_gate_close
123
exit_gate_close
vehicle_enter
request_enter
vehicle_exit
exit_ticket_insert
entry_gate_openexit_gate_open
request_enter
76
entry_gate_close
exit_gate_close
61
vehicle_enter
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
14
ticket_issue
entry_gate_close
vehicle_enter
vehicle_exit
exit_gate_closeentry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
15
vehicle_enter
vehicle_exit
vehicle_enter
request_enter
exit_gate_openexit_ticket_insert
vehicle_exit
86
entry_gate_open
exit_gate_close
vehicle_entervehicle_exit
request_enter
entry_gate_openexit_ticket_insert
51
exit_gate_open
52
exit_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit
exit_ticket_insertexit_gate_open exit_gate_close
vehicle_entervehicle_exit
request_enter
53
exit_ticket_insert
entry_gate_open
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
54
exit_gate_open
67entry_gate_open
request_enter
vehicle_enter
vehicle_exit
exit_ticket_insertexit_gate_open
55
entry_gate_open
entry_gate_close
request_enter
vehicle_exit
exit_ticket_insert
entry_gate_openexit_gate_open
vehicle_enter
vehicle_enter
entry_gate_open
exit_ticket_insertexit_gate_open
70
request_enter
62
vehicle_exit
entry_gate_close
vehicle_enter
ticket_issue
entry_gate_open
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
entry_gate_close
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_exit
vehicle_entervehicle_exit
ticket_issue
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_close
exit_gate_open
vehicle_enter
ticket_issue
exit_gate_close
vehicle_exit exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
entry_gate_open
exit_ticket_insert
63
exit_gate_open
64exit_gate_close
entry_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit exit_ticket_insertexit_gate_open
exit_gate_close
entry_gate_close
entry_gate_close
vehicle_entervehicle_exit
request_enter
65
exit_ticket_insert
entry_gate_open
entry_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
66exit_gate_open
entry_gate_open
entry_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit
exit_ticket_insertexit_gate_open
entry_gate_close
vehicle_exit
request_enter
exit_gate_open
exit_ticket_insertentry_gate_open
vehicle_enter
vehicle_entervehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insert
78
request_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
vehicle_enter
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
vehicle_exit
exit_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
exit_gate_close
vehicle_enter
request_enter
vehicle_exit
entry_gate_closeexit_gate_openexit_ticket_insert
entry_gate_close
vehicle_exit
request_enter
exit_ticket_insert
entry_gate_open
vehicle_enter
vehicle_entervehicle_exit
exit_ticket_insert
request_enter
104entry_gate_close
112entry_gate_open
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enter
95entry_gate_close
entry_gate_openvehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
exit_ticket_insert
entry_gate_close
request_enterentry_gate_open
115
ticket_issue
98
vehicle_enter
vehicle_exit
exit_ticket_insert
entry_gate_open
request_enter
116
vehicle_enter
vehicle_entervehicle_exit
exit_ticket_insert
30
request_enter
107
entry_gate_open
vehicle_entervehicle_exit
exit_ticket_insert
request_enter97
entry_gate_open
vehicle_exit
exit_ticket_insert
request_enterentry_gate_open
vehicle_enter
96entry_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
89
request_enter
106
entry_gate_closeentry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insert
90
request_enter
100
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
entry_gate_closeexit_ticket_insertrequest_enter
exit_gate_open
vehicle_enter
entry_gate_closeexit_gate_openexit_ticket_insertrequest_enter
vehicle_exit
vehicle_entervehicle_exit
ticket_issue
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_close
exit_gate_open
vehicle_enter
ticket_issue
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
vehicle_enter
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
102
vehicle_exit
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
103
exit_gate_open
exit_gate_close
vehicle_enter
vehicle_exit
request_enterexit_ticket_insert
entry_gate_closeexit_gate_open
exit_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
request_entervehicle_enter
entry_gate_closeexit_ticket_insertentry_gate_open
exit_gate_open
request_enter
vehicle_enter
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insert
85
vehicle_exit
vehicle_exit
entry_gate_close
entry_gate_openexit_ticket_insert
exit_gate_open
request_enter
117
vehicle_enter
exit_gate_close
vehicle_exit
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insert
request_enter
87
vehicle_enter
exit_gate_close
exit_gate_close
entry_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
27
ticket_issue
vehicle_enter
vehicle_exit
exit_gate_close
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
28
vehicle_enter
vehicle_exit
vehicle_enter
exit_gate_close
exit_ticket_insertexit_gate_open
29request_enter
111
entry_gate_open
vehicle_exit
vehicle_enter
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
exit_gate_open
109
entry_gate_open
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
vehicle_enter
108
entry_gate_close
vehicle_exit
vehicle_enter
exit_gate_close
exit_gate_openexit_ticket_insert
88
request_enter
vehicle_exit
110
entry_gate_close
entry_gate_open
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
exit_gate_close
entry_gate_close
vehicle_entervehicle_exit
entry_gate_open
exit_ticket_insert
request_enter
entry_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enterentry_gate_close
vehicle_enter
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
exit_gate_close
entry_gate_close
entry_gate_open
exit_ticket_insert
exit_gate_open
vehicle_enter
request_enter
vehicle_exit
exit_gate_close
entry_gate_close
entry_gate_open
exit_ticket_insertexit_gate_open
vehicle_enter
vehicle_exit
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
exit_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enter
entry_gate_close
vehicle_exit
request_enter
vehicle_enterentry_gate_close
exit_ticket_insert
entry_gate_openexit_gate_open
exit_gate_close
vehicle_exit
request_enter
vehicle_enter
exit_ticket_insert
entry_gate_close
entry_gate_open
vehicle_exit
exit_gate_close
entry_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
128ticket_issue
vehicle_enter
vehicle_exit
exit_gate_close
exit_gate_open
entry_gate_open
exit_ticket_insertrequest_enter
129vehicle_enter
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insert
130
request_enter
122entry_gate_open
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
120
entry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
vehicle_enter
119entry_gate_close
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insert
118
request_enter
121
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_gate_close
entry_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
exit_gate_closeexit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
exit_gate_open
exit_gate_close
request_enter
exit_ticket_insertentry_gate_close
vehicle_exit
exit_gate_open
exit_gate_close
request_enter
vehicle_enter
entry_gate_close
exit_ticket_insertentry_gate_open
vehicle_entervehicle_exit
request_enter
exit_gate_open
entry_gate_open
exit_ticket_insert
exit_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
entry_gate_open
vehicle_exit
exit_ticket_insert
request_enter
vehicle_enter
entry_gate_closeentry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
vehicle_enter
exit_ticket_insertrequest_enter
entry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
entry_gate_close
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_open
Figure 13 Chapter supervisor of the top-level requirements documenttranslated into a Modal Interface Csupervisor for a capacity of two for theparking garage
shared input ldquovehicle exitrdquo as their only interaction But thisshared input is involved in requirement Rs3 which forbidsthe entry if the parking is full
In Figure 15 we show the result of applying to the ar-chitecture of Figure 14 the Algorithm 1 developed in Sec-tion VIII-E which yields by construction a refinement of thetop-level contract C by a decomposition into local contracts
C C(ΣEntryGate)otimes C(ΣExitGate)otimes C(ΣPaymentMachine)
(55)
Local contract C(ΣEntryGate) is the more complex one becauseit involves countingmdashwe have assumed a capacity of two tokeep it simple Remarkably enough the decomposition (55)involves small sub-systems compared to Csupervisor (Fig 13)and the global contract C the restriction operation is to beacknowledged for this strong reduction in size
E The four ldquoCrdquo
Requirements capture and management are important mat-ters for discussion with certification bodies These bodieswould typically assess a number of quality criteria from egthe following list elaborated by INCOSE [114] AccuracyAffordability Boundedness Class Complexity Completeness
request enter
ticket issue
entry gate open
entry gate closeEntryGate
vehicle enter
vehicle exit
exit ticket insert ExitGateexit gate open
exit gate close
ticket insert payment
coin insert paymentPaymentMachine exit ticket issue
Figure 14 System architecture as specified by the designer
0
vehicle_exit
1
request_enter
3
vehicle_enter
request_entervehicle_exit
2ticket_issue
vehicle_enter
request_entervehicle_exit
vehicle_enter
4
entry_gate_open
entry_gate_closeentry_gate_open
ticket_issuevehicle_enterrequest_entervehicle_exit
entry_gate_close
request_entervehicle_exit
5vehicle_enter
vehicle_enter
6
request_enter
15
entry_gate_close
16
vehicle_exit vehicle_enter
request_enter
7
vehicle_exit
8
entry_gate_close
entry_gate_closevehicle_enter
request_entervehicle_exit
vehicle_exit
vehicle_enter
request_enter
9ticket_issue
vehicle_exit
vehicle_enter
request_enter
10
entry_gate_open
vehicle_exit
entry_gate_closerequest_enter
11
vehicle_enter
vehicle_enter
vehicle_exit12
request_enter
14entry_gate_close
vehicle_enter
vehicle_exit
request_enter
13entry_gate_close
vehicle_enter
vehicle_exit request_enter
vehicle_enter
request_enter
vehicle_exit
vehicle_exit
vehicle_enter
request_enter
entry_gate_close
vehicle_enter
request_entervehicle_exit
0 1exit_ticket_insert
4
vehicle_exit
exit_ticket_insert
2
exit_gate_open
vehicle_exit
exit_ticket_insert
3vehicle_exitexit_gate_close
exit_ticket_insertvehicle_exit
exit_ticket_insertexit_gate_close
vehicle_exitexit_gate_open
0 1ticket_insert_payment 2
coin_insert_paymentticket_insert_payment
3
coin_insert_payment
ticket_insert_paymentcoin_insert_paymentexit_ticket_issue
exit_ticket_issueticket_insert_paymentcoin_insert_payment
Figure 15 The three restrictions of the global contract C for the three sub-systems EntryGate (top) ExitGate (mid) and PaymentMachine (bottom)
Conciseness Conformance Consistency Correctness Criti-cality Level Orthogonality Priority Risk Unambiguousnessand Verifiability In this section we focus on four quality crite-ria that are considered central by certification authorities andare relevant to contracts namely Completeness CorrectnessConsistency and Compatibility
1) Consistency amp Compatibility Consistency and compat-ibility have been formally defined in the meta-theory seeSection V and Table IV therein In particular those formaldefinitions can be formally checked Thus the question ariseswhether these formal definitions suitably reflect the commonsense meaning of these terms
According to the common meaning a set of requirementsis consistent if it is not self-contradicting The intent is thatthere is no point in trying to implement an inconsistent set ofrequirements as no such implementation is going to exist
RR ndeg 8147
Contracts for System Design 50
It turns out that the existence of implementations is theformal definition of consistency according to the meta-theoryClearly the formal definition of consistency meets its commonsense interpretation We illustrate consistency on the top-levelspecification of Table IX Referring to this table we havestrengthened Rs6 and Rs7 in some way Lack of consistencyis revealed by checking the mutual consistency of these tworequirements with the requirement Rg3 applied to the exitgate After the following scenario
exit_ticket_insertexit_gate_openexit_ticket_insert
event exit_gate_open has modality must in left-hand interfaceand modality cannot in right-hand interface
According to the common meaning an architecture of sub-systems as characterized by their respective specifications iscompatible if these sub-systems ldquomatch togetherrdquo in that theycan be composed and the resulting system can interact withthe environment as expectedmdashuse cases can be operated aswished As explained in Table IV of Section V this is theformal definition of compatibility in the meta-theory Againthe formal definition of compatibility meets its common senseinterpretation
2) Correctness Correctness can only be defined withreference to another specification We propose to translateldquocorrectnessrdquo by one of the following properties dependingon the case (see Table IV for the notations)bull ldquois a correct implementation ofrdquo written |=Mbull ldquois a correct environment ofrdquo written |=Ebull ldquorefinesrdquo written
3) Completeness Completeness raises a difficulty Al-though the term ldquocompletenessrdquo speaks for itself it cannotbe formally defined what it means to be complete for a top-level specification in the form of a set of requirements Thereason is that we lack a reference against which completenesscould be checked Hence the only way to inspect a top-level specification for completeness is to explore it manuallyThe best help for doing this is to execute the specificationThus specifications must be executable Fortunately ModalInterfaces are executable and this way undesirable behaviorscan be revealed We illustrate this on the top-level specificationof Table IX where Rs6 is changed into ldquoexit gate must openafter an exit ticket is insertedrdquo (by omitting ldquoand only thenrdquo)Lack of completeness is revealed by simulation The followingscenario can occur
exit_ticket_insertexit_gate_openvehicle_exitexit_gate_closeexit_gate_open
which allows vehicles to exit without having inserted an exitticket an unwanted behavior This reveals that the specificationwas not tight enough ie incomplete So far for completenessof the top-level specification
In contrast completeness can be formally defined whena reference C is available We propose to say that Cprime isincomplete with reference to C if
1) Cprime does not refine C but2) there exists Cprimeprime Cprime such that Cprimeprime is consistent and
compatible and refines CThe rationale for this definition is that Cprime is not precise enoughbut can be made so by adding some more requirementsNote that Cprime is incomplete with reference to C if and onlyif Cprime and C is consistent and compatible This criterion is ofparticular relevance when Cprime =
otimesiisinI Ci is an architecture of
sub-contracts where Ci is to be submitted to supplier i forindependent development
F Discussion
Requirements engineering is considered very difficult Re-quirements are typically numerous and very difficult to struc-ture Requirements concern all aspects of the system func-tion performance energy reliabilitysafety Hence systemsengineers generally use several frameworks when expressingrequirements The framework of contracts expressed as ModalInterfaces that we have proposed here improves the situationin a number of aspectsbull It encompasses a large part of the requirements52
bull It can accommodate different concrete formalisms Inour example we have blend textual requirements withrequirements specified as state machines Richer for-malisms such as Stateflow diagrams can be accom-modated in combination with abstract interpretationtechniquesmdashthis is not developed here
bull We have shown how to offer formal support to importantproperties such as the four Crsquos during the process ofcertification
bull We have proposed a correct-by-construction approach tothe difficult step of moving from the top-level specifi-cation in the form of a requirements document to anarchitecture of sub-contracts for the suppliers53
XII CONTRACTS IN THE CONTEXT OF AUTOSAR
In this section we use AUTOSAR as an industrial exampleof how to leverage contracts within an existing standard toextend it
A The AUTOSAR context
AUTOSAR54 is a world-wide development partnership in-cluding almost all players in the automotive domain electronics
52 According to figures that were given to us by industrials 70-80 of therequirements can be expressed using the style we have developed here Otherrequirements typically involve physical characteristics of the system or definethe range for some parameters
53 The framework of AssumeGuarantee contracts that is used in Section XIIdoes not offer this for two reasons First it lacks the quotient and secondlocal alphabets are not properly handled In contrast AssumeGuarantee con-tracts are very permissive in how they can be expressed In particular dataflowdiagrams (Simulink) can be used to express assumptions and guarantees
54httpwwwautosarorg
RR ndeg 8147
Contracts for System Design 51
supply chain It has been created with the purpose of de-veloping an open industry standard for automotive softwarearchitectures To achieve the technical goals of modularityscalability transferability and reusability of functions AU-TOSAR provides a common software infrastructure based onstandardized interfaces for the different layers The AUTOSARproject has focused on the objectives of location indepen-dence standardization of interfaces and portability of codeWhile these goals are undoubtedly of paramount importancetheir achievement may not be sufficient for improving thequality of software systems As for most other embeddedsystem car electronics is characterized by functional as well asnon functional properties assumptions and constraints [111]Therefore an AUTOSAR based development process benefitsfrom adding contracts as the this section will demonstrate
B The contract framework
Extensive use of SimulinkStateflow modeling is performedfor system design in the automobile sector It is thus naturalto try reusing this modeling style for defining contractsSince AG contracts of Section VII simply rely on specify-ing assertions regardless of how they are actually describedwe use AG contracts for this AUTOSAR case study SinceSimulinkStateflow diagrams are very flexible contracts canbe expressed for all viewpoints (function timing safety) Inturn reasoning on such contracts is beyond the capability ofautomatic tools Consequently checking for implementationand refinement relations will be performed manually on smallmodels In contrast the powerful contract algebra developedin the meta-theory is fully generic and does not depend onthe nature and complexity of the considered models Themodularity it offers will thus be the main help offered bycontract based design in this case study As another featureof this this study the distinction between ldquohorizontalrdquo andldquoverticalrdquo contracts is used see Section IV-D4 Finally thefollowing variation of AG contracts is used
Assertions consist of a timed extension of the weaklysynchronous model (18) namely
P sube ((Σ 7rarr D) cup R+)lowast cup ((Σ 7rarr D) cup R+)
ω (56)
meaning that the assertion proceeds by a succession of stepsconsisting of either assignment of values to variables (includ-ing the special status absent for multiple-clocked assertions)or time progress Composition is by intersection P1timesP2 =def
P1 and P2 with alphabet equalization by inverse projection asin see Section VII-C Following Section VII-B componentsare tuples M = (ΣinΣout P ) where Σ = Σin cup Σout is thedecomposition of alphabet Σ into its inputs and outputs andP is an assertion following (56) Components must be free ofexception in the sense of Definition 4
A contract is a tuple C = (ΣinΣoutAs AwG) whereΣ = Σin cup Σout is the decomposition of alphabet Σ intoits inputs and outputs As and Aw the strong and weakassumptions and G the guarantees are assertions over ΣThe set EC of the legal environments for C collects all com-ponents E such that E sube A The set MC of all components
implementing C is defined by (As andAw)timesM sube G meaningthat implementations guarantee G under the condition that theenvironment satisfies the stronger condition AsandAw In otherwords in this framework legal environments are constrainedby strong assumptions only whereas the conjunction of strongand weak assumptions is required to guarantee G Weakassumptions are useful for design iterations in case strictobligations for the context of use may not be realizable
To conclude on this framework its difference is onlymethodological since any contract with strong and weakassumptions C = (ΣinΣoutAs AwG) is equivalent to anordinary AG contract (ΣinΣoutAsG or notAw) Thus thereader is referred to Section VII Adding time to the paradigmdoes not change anything to the relations or operators definedin that section
However adding time results in decidability and complexityissues The latter problem can be fixed in part by usingobservers see Sections V-G and VII Other proofs can be car-ried on manuallymdashthis is feasible for undecidable propertieswhen the needed reasoning only involves a small part of theanalyzed system involving few locally interacting componentsThe added value of our contract framework is to supportthe combination of proofs into a validation for the overallsystem taking into account detailed design decisions capturedin system and ECU configurations
C Exterior Light Management System
To illustrate the benefits of contract-based systems engineer-ing in AUTOSAR we consider as an example an excerpt of anExterior Light Management for an automobile55 We focus onthe parts responsible for sensing driver inputs and actuatingthe rear direction indicator lights and brake lights With thisexample we show how requirements can be refined to contractsand discuss the added value of contracts for negotiationsbetween OEM and suppliers We will also illustrate the useof vertical contracts eg to specify the expected latency ofthe communication solution and computations from the timingviewpoint and a failure hypothesis in terms of reliability
1) Function and timing We begin our study by showinghow AUTOSAR models can be enhanced with contracts
System
ext_pedal
ext_lamp
ext_tssext_wls
ext_rlaext_rra
Figure 16 Virtual Functional Bus model
The Virtual Functional Bus model Figure 16 shows the Vir-tual Functional Bus (VFB) model encompassing the exteriorlights management This software composition specifies the
55A case-study from the German SPES2020 project
RR ndeg 8147
Contracts for System Design 52
interfaces exposed by the component to the sensors deliveringdriver inputs (brake pedal warn light button turn signallever) and to the actuators controlling the lights Ports witharrowheads denote an asynchronous data flow interface whichis a SenderReceiverInterface Here it is a special kind calledServiceInterface which means the data is provided by somelocal service located in the BasicSoftware stack of an ECU(Electronic Computing Unit) The requirements document ofthe system contains one timing-related requirementbull R1 If the driver presses the brake pedal the brake lights
must light not later than 25msWe formalize in Table X this requirement as a contract by
using a pattern-based contract specification language (terms inbold-face are keywords)
CR1
As whenever ext_pedal occursext_pedal does not occur during[ext_pedalext_lamp]ext_pedal occurs sporadicwith minperiod 25ms
Aw trueG delay between ext_pedal and
ext_lamp within [0ms25ms]
Table XHORIZONTAL CONTRACT OF VFB MODEL
Indicator
BrakePedalSensor PedalToLamp
TurnSwitchSensor
WarnLightsSensor
SwitchLightActuator
RearLeftActuator
RearRightActuator
BrakeLampActuator
ext_pedal
pos_pedal_out lamp_intensity ext_lamp
ext_tss
ext_wls
tss
wls
ext_rla
ext_rra
rla_signalrra_signal
emcyBrake
pos_pedal_in
Figure 17 Decomposed Virtual Functional Bus model
Decomposed VFB Software composition Figure 17 showsthe decomposed VFB model AssemblySwConnectors link theports of parts of the composition and are subject to commu-nication refinement The components used in the compositionand their functions are as followsbull BrakePedalSensor receives the position of the brake pedal
(ext_pedal) and distributes it to other components
bull PedalToLamp reads the brake pedal position (pos_pedal)and calculates requested brightness of the brake indicatorlights (lamp_intensity)
bull BrakeLampActuator reads the requested brightness of thebrake indicator lights (lamp_intensity) and actuates thebrake lamps accordingly (ext_lamp)
bull TurnSwitchSensor reads the position of the lever and for-wards it (tss)
bull WarnLightsSensor reads status of the warn blink button andforwards it (wls)
bull Indicator reads the status of the warn blink button the leverposition and cyclically toggles the left and right signals(rla_signal rra_signal)
bull Rear(Left|Right)Actuator reads its input signal ((rla|rra)_signal)and actuates the bulb (ext_(rla|rra))
bull SwitchLightActuator reads left and right signals((rla|rra)_signal) and provides feedback on the dashboard
Horizontal (functional) contracts associated to the VFBmodel For the decomposed VFB model we derive horizontalcontracts specifying the desired IO behavior of the parts Asan example for the component BrakePedalSensor we state thecontracts shown in Table XI Contract CfIOBPS
specifies that
CfIOBPS
Afs whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Afw true
Gf whenever ext_pedal occurspos_pedal_out occurs
CfSIGNALBPS
Afs whenever pos_pedal_out occurs
pos_pedal_out does not occur during[pos_pedal_outpos_pedal_in]
Afw true
Gf whenever pos_pedal_out occurspos_pedal_in occurs
Table XIA SAMPLE OF THE HORIZONTAL CONTRACTS OF THE DECOMPOSED VFB
MODEL SUPERSCRIPT f REFERS TO ldquoFUNCTIONrdquo
provided that the pedal is not ldquomultiply pressedrdquo then thepos_pedal message traverses the BrakePedalSensor and then thewire following it with some unspecified delay In particular nomessage is lost due to a miss by this block Similar contractsare stated for all blocks of the VFB model thus resultingin a set Cf
IO of contracts For all AssemblySwConnectors ofthe composition horizontal contracts are specified that aresimilar to that of CfSIGNALBPS
resulting in a set CfSIGNAL
of contracts This contract scheme guarantees a reliable datatransport by each wire of the VFB model no matter how thecommunication is refined
So far we have stated contracts for each block and eachwire of the VFB model Compose the above contracts usingcontract composition (14) ie compute
CfVFB =otimes(otimes
C | C isin CfIO)
otimes(otimesC | C isin Cf
SIGNAL) (57)
RR ndeg 8147
Contracts for System Design 53
The guarantee offered by overall contract CfVFB is the con-junction of the guarantees of the constitutive contracts Hencecontract CfVFB guarantees that messages reliably traverse theVFB model with however an unspecified delay On the otherhand contract composition (14) assumes the conjunction ofall assumptions stated for each blockmdashthe guarantee offeredby CfVFB and the strong assumption of CR1
discharge all ofthese assumptions
At this point we observe that contract CfVFB involves notiming characteristics and thus functional contract CfVFB doesnot refine the initial contract CR1 To overcome this timingcontracts are added in the next step that will complement thisfunctional contract with timing viewpoint based on expectedperformance characteristics of the computing platform
Budgeting time using contracts We now state additionalcontracts such as the ones shown in Table XII Observethat for those contracts weak assumptions are used see Sec-tion XII-B regarding the motivations for doing this Observealso that we repeated the functional strong assumption56
Again stating similar contracts for each block and wire of the
CtIOBPS
Ats whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Atw ext_pedal occurs sporadic
with minperiod 15msGt delay between ext_pedal and
pos_pedal_out within [0ms15ms]
CtSIGNALBPS
Ats whenever pos_pedal_out occurs
pos_pedal_out does not occur during[pos_pedal_outpos_pedal_in]
Atw pos_pedal_out occurs sporadic
with minperiod 2msGt delay between pos_pedal_out and
pos_pedal_in within [0ms2ms]
Table XIITIMING CONTRACT OF DECOMPOSED VFB MODEL SUPERSCRIPT t
INDICATES THAT THESE CONTRACTS DEAL WITH TIMING
VFB model yields two sets CtIO and Ct
SIGNAL of contractsand we consider
CtVFB =otimes
(otimesC | C isin Ct
IO)otimes(otimesC | C isin Ct
SIGNAL)(58)
The next step is to combine for each component (blockor wire) of the VFB model the two functional and timingviewpoints using conjunction ie to compute
CVFB =otimes(otimes[
Cf and Ct]| (Cf Ct) isin CIO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin CSIGNAL
) (59)
where CIO collects for each block the pair of functional andtiming contracts associated with it and similarly for CSIGNAL
56 If we do not do this then when taking the conjunction of functionaland timing contracts the functional strong assumption gets absorbed by thestrong assumption of the timing contract since the latter is equal to T Seethe discussion regarding AssumeGuarantee contracts with variable alphabetsat the end of Section VII-C
At this point we observe that the architecture of the VFBmodel is a directed acyclic graph
Consider the conjunction C = Cf and Ct = (AG) for eachblock or wire As an example focus on block IOBPS whichis the first block of VFB seen as a directed acyclic graphRegarding the combination of strong and weak assumptionswe have A = Afs and Atw which is weaker than As theassumption of CR1
in Table X Regarding guarantees we haveG = Gf and Gt which ensures that messages traverse thecomponent without duplication or loss and with a delay lessthan the ldquominperiodrdquo of the input signal (15ms) Also guar-antee G offered by this block is strong enough to dischargethe assumption of the next wire when performing contractcomposition Reproducing the same reasoning inductivelyalong all blocks and wires of the VFB model seen as an acyclicgraph shows that
CVFB CR1(60)
Consequently submitting the pairs of contracts (Cf Ct) asso-ciated to each component for separate development possiblyby different suppliers will ensure correct integration (providedimplementations by the suppliers are correct with respect totheir contracts) In particular the component BrakePedalSensorbelongs to the chassis domain and is implemented by adifferent supplier than the other components
Discussion The above step of our contract based designmethodology leads to the following important notices
1) So far our proof steps were all manual Our contractbased reasoning however was instrumental in ensuring thatelementary proof steps were combined correctly Reasoningbased on intuition when component composition and view-point combination both occur is very likely to lead to wrongconclusions There is a strong added value in contract basedreasoning even if elementary proof steps are manual
2) Manual reasoning can be complemented by the use ofobservers Again it is important that the use of observerswhen component composition and viewpoint combination bothoccur is performed correctly Our development in Section V-Gprovides the formal support for this For the pattern basedlanguage used here a framework for checking refinement ofcontracts using an observer based strategy is described in [94]
3) The responsibility of establishing the sub-contracts sub-mitted to the different suppliers is assigned to the OEM inaccordance with his role as integrator Components belongingto different domains of a car (engine chassis etc) are likely tooriginate from different vendorssuppliers By using our abovereasoning the OEM can decompose its contract specificationspassing them to supplier(s) For example the componentBrakePedalSensor is the only one in the VFB model that belongsto the chassis domain and other components are developed byone or more different suppliers Thus in decomposition (59)the two sets of contracts CIO and CSIGNAL are partitioned
RR ndeg 8147
Contracts for System Design 54
eg for subcontracting to two different suppliers
Csupplier1VFB =
otimes(otimes[Cf and Ct
]| (Cf Ct) isin C1
IO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin C1
SIGNAL
)Csupplier2VFB =
otimes(otimes[Cf and Ct
]| (Cf Ct) isin C2
IO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin C2
SIGNAL
)Each supplier can then safely develop its own sub-systemindependently We develop this in the next sub-section
Implementation of software components and vertical as-sumptions Each of the software components being part ofthe software system composition (cf Figure 17) is a Compo-sitionSoftwareComponents as this allows the supplier to reusealready designed components We thus consider one suchcomponent with its contract C = Cf and Ct consisting of thefunctional contract Cf in conjunction with the timing contractCt The supplier can then follow two different approaches fordeveloping this component
In a first approach the supplier reuses a composition
C =otimes
iisinI Ci (61)
of off-the-shelf components available from a library Twosituations can then occurbull The easy case is when refinement holds C C This
means that for C = (As Aw G) guarantees are strongenough and assumptions are weak enough to implyrefinement with respect to the contract C specified bythe OEM
bull A more realistic (but also more delicate) case is when thefollowing weaker relations are satisfied
C Cf (62)G sube G (63)
As and Aw supe Afs andAfw (64)
but the conditions requested on timing assumptions forrefinement C C to hold are not satisfied
As and Aw 6supe Ats andAtw (65)
Under (65) composition from library C cannot be usedas such It can however still be used as a valid imple-mentation provided that some additional missing verticalassumption regarding timing is stated such that
As and Aw supe Ats andAtw and Atw︸ ︷︷ ︸for negotiation
(66)
(66) requires a negotiation in which additional verticalassumption Atw is returned back to the OEM as an ad-ditional performance requirement for the ECU platformIf this is accepted by the OEM then development by thesupplier using off-the-shelf components from the library(61) can proceed
The alternative approach is to implement the componentEventually this results in a composition of AtomicSoftwareCom-ponents This component type has an internal behavior specifi-cation comprising so called Runnables which are the smallest
executable entities known to AUTOSAR For each runnableactivation conditions are defined by means of RTEEvents con-trolled by the RuntimeEnvironment on the corresponding ECUand data accesses referring ports of the owning component AnRTEEvent can be configured to occur either cyclically (time-triggered) or by the data arrival on some input port of theowning component (event-triggered)
Figure 18 depicts the internal behavior of componentBrakePedalSensor This component consists of a single
BrakePedalSensor
BPSRunnable
pos_pedal_out
P=10ms
ext_pedal
Figure 18 Internal behavior of BrakePedalSensor-component
CfIBBPS
Afs whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Afw true
Gf whenever ext_pedal occurspos_pedal_out occurs
CtIBBPS
Ats whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Atw ext_pedal occurs sporadic
with minperiod 10msBPSRunnableact occurs each 10msdelay between BPSRunnableact andpos_pedal_out within [0ms10ms]
Gt delay between ext_pedal andpos_pedal_out within [0ms10ms + 10ms]
CprimetIBBPS
Aprimets whenever ext_pedal occursext_pedal does not occur during[ext_pedalpos_pedal_out]
Aprimetw ext_pedal occurs sporadicwith minperiod 10msBPSRunnableact occurs each 10msdelay between BPSRunnableact andpos_pedal_out within [0ms5ms]
Gprimet delay between ext_pedal andpos_pedal_out within [0ms10ms + 5ms]
Table XIIICONTRACTS FOR INTERNAL BEHAVIOR OF
BRAKEPEDALSENSOR-COMPONENT
runnable BPSRunnable which is activated cyclically with aperiod of 10ms Upon its activation it reads the sensorvalues from the ECU abstraction component and writes the
RR ndeg 8147
Contracts for System Design 55
position of the brake pedal on its provided SenderReceiverport The timing behavior of the component owning a time-triggered runnable can be characterized by the contract shownin Table XIII top
We now focus on the second situation in which the supplierwants to reuse components from a library to implementcontract C = CfIOBPS
and CtIOBPS We consider the case where
a component BrakePedalSensor has already been implementedand characterized by C = CfIBBPS
and CtIBBPSNow observe that
relation (62) holds However G 6sube G Taking a closer lookat Atw we see it assumes a worst case response time forBPSRunnable Thus the guarantee Gt can be strengthened ifweak assumption Atw is replaced by Aprimetw ensuring a shorterresponse time The supplier would then consider the con-tract Cprime = CfIBBPS
and CprimetIBBPS where the re-adjusted contract
CprimetIBBPScorresponds to assuming Aprimetw and guaranteeing Gprimet
For that modified contract relations (62ndash65) hold Howeverstrengthening an assumption is not a refinement Thereforeapplying this modification cannot be performed by the supplieron its own but rather requires negotiation with the OEM Ifthe OEM is willing to accept the stronger assumption Aprimetwthe component from the libary can be used and the modifiedcontract of the supplier is refined Cprime Cprimesupplier1
VFB The next process steps in the AUTOSAR methodology called
System configuration and ECU configuration define the targetarchitecture (ECUs and communication network) as well asthe deployment of the application software components onthat distributed architecture Thus satisfaction of the contractsspecified for the application needs to be verified for the givenarchitecture and deployment (cf IV-D4) We develop this inthe next two sub-sections
ECU configuration and vertical contracts During thefollowing discussion we assume that for each componentimplementation a contract similar to Cprime has been specifiedand possibly an associated Aprimetw has been negotiated Observethat Aprimetw may invalidate refinement of system requirements bythe VFB contract Consider the example above Aprimetw assumesan activation of BPSRunnable each 10ms and a worst caseresponse time less than 5ms This additional weak assumptionis now part of Cprimesupplier1
VFB However it is neither dischargedby any guarantee of CprimeVFB nor by the strong assumption ofCR1 Thus we need to verify that 1 all vertical assumptionscollected during previous steps are discharged during system-and ECU configuration and 2 all guarantees are met bysoftware components and connectors For both tasks state-of-the-art verification techniques can be used
As an example focus on the vertical assumption Aprimetw ofthe BrakePedalSensor-component and consider the ECU con-figuration depicted in Figure 19 The ECU hosts the twocomponents BrakePedalSensor and PedalToLamp of the VFBmodel57 These components are integrated with a layered basicsoftware stack on an ECU That stack consists of multipleBasicSoftwareModules (BSWM) Each of these modules has aset of standardized interfaces and is implemented by a set
57To simplify we omit port emcyBrake
RTE
BrakePedal
SensorPedalToLamp
BSW
COMOSt1 t2
Complex
Device
Driver
ext_pedal
pos_pedal_out
pos_pedal_in
lamp_intensity
isr
Figure 19 Extracting platform contracts from ECU configuration
of BswModuleEntities These are analogous to the Runnables ofapplication software components and are either executed by adedicated OS task or interrupt service routine Therefore weexpect BasicSoftwareModules to be characterized by contractsin a way similar to the internal behavior of applicationcomponents (cf contracts in Table XIII) In case a BSWM hasa BswModuleEntity that is not mapped to some task or interruptservice routine that entity is an ldquoordinaryrdquo function calledwithin the context of another BswModuleEntity or Runnable Inthe example ECU configuration two BSWMs are shown
bull A ComplexDeviceDriver which has direct access to thesensor of the ECU that detects position of the brake pedal
bull An AUTOSAR COM module and a CAN interface (notshown here)
The components and BSWMs own a single runnable eachbsw entity respectively The ECU configuration maps BP-SRunnable to task t1 of the operating system (OS) and PTL-Runnable to task t2 The BswModuleEntity of the ComplexDe-viceDriver is mapped to an interrupt service routine while theentity of the COM module is simply a function for sendinga signal That function is used by the AUTOSAR runtimeenvironment (RTE) to realize the communication specified onVFB-level by means of the connectors For each task of theOS the ECU configuration specifies at least its priority andwether it is preemptable The activation of a task is specifiedby linking an alarm of the OS to that task Those alarmscan also be configured to occur cyclically For each cyclicalarm we generate a contract PALARMi
with trivial strongand weak assumptions and as guarantee the cycle time ofthe alarm The example ECU configuration contains a singlealarm whose contract is listed in Table XIV top Furthermore
PALARM1
As trueAw trueG Alarmi occurs each 10ms
PBPSRunnable
As trueAw trueG delay between BPSRunnableact and
pos_pedal_out within [1ms4ms]
Table XIVPLATFORM CONTRACTS OBAINED BY ANALYSIS OF ECU CONFIGURATION
RR ndeg 8147
Contracts for System Design 56
we can extract from the AUTOSAR model of the componentimplementation a set of execution time specifications for eachRunnable owned by the component Again the same appliesto BswModuleEntities With this information we can create atask network and obtain response times for each Runnableand BswModuleEntity (if executed by some task or interruptservice routine) using tools like SymTAS58 or chronVAL59Afterwards we generate for each Runnable and BswModuleEntity(if executed by task or ISR) a contract PRunnablei
with stongand weak assumption T and as guarantee the reponse timeinterval determined by analysis For the ECU configurationsketched in Figure 19 BPSRunnable has a response time thatlies in the interval [1ms 4ms] resulting in the contract shownin Table XIV bottom Similar contracts are stated for all tasksand alarms extracted from the ECU configurations We thencompose these contracts and the contracts of the BSWMswhich yields the contract P characterizing the executionplatform Following the approach outlined in Section IV-D4we compose the VFB contract with the platform contract andcheck for refinement ie
CprimeVFB otimes P CprimeVFB (67)
The vertical assumption Aprimetw is discharged in the compositionof the VFB and platform contracts and refinement holdsFurthermore with Aprimetw being discharged refinement of thesystem requirement holds again
CprimeVFB otimes P CR1(68)
The approach outlined here to analyze the mapping of applica-tion software components and their associated contracts on anECU network by creating contracts from ECU configurationsand results of response time analysis has been implemented ina framework That framework includes a meta-model support-ing contract-based design and enables to 1 specify contractsfor components in foreign models and 2 check for refinementbetween contracts belonging to different models [24]
Inter-ECU communication During system configurationthe leaves of the hierarchical software composition calledAtomicSoftwareComponents are mapped to ECUs of the targetarchitecture Thus we know for each connector of the VFBmodel whether it must be implemented by the communicationnetwork interconnecting the ECUs
For both intra- and inter-ECU communication the designmust be verified against the corresponding contracts of theVFB model ie the set of contracts[
Cf and Ct] ∣∣ (Cf Ct) isin CSIGNAL
(69)
Again available analysis techniques can be used Suppose asignal from the VFB model is mapped to a frame transmittedon a CAN bus The OEM can then for each such contractuse the combination of strong and weak assumptions A =Afs and Atw as specification of the minimal inter-arrival timesof subsequent occurrences of the signal Taking into account
58httpwwwsymtavisioncomsymtashtml59httpwwwinchroncomchronvalhtml
the priority of each CAN frame given by its identifier theresponse time of each signal can be computed and comparedagainst the guarantee G = Gf andGt
If the communication network whose configuration is partof the AUTOSAR system configuration is successfully verifiedagainst the contracts defined in (69) deployment of the VFBmodel on the target architecture is correct with regard tothe VFB contract and the design fulfills the initial systemrequirement CR1
Discussion The above development highlights themethodological value of contracts for system design in AU-TOSAR context at later design stages First both contractconjunction and composition are used Then modificationsthat are not refinements are pinpointed which forces thesupplier to engage on a negotiation with the OEM regardingsystem specifications Without the solid support of contractsand its rules such kind of reasoning would be error prone
2) Safety The virtual function bus (VFB) concept wasintended to enable a distributed development of software com-ponents independently from the underlying hardware architec-ture The specification of the interfaces in the 3x releases didnot support the kind of non functional property necessary todevelop safety aspects of critical systems This fact lead to thedevelopment of the previously mentioned Timing Extensionand Safety Extension to Methodology and Templates Thesafety extension directly addresses the use of contracts forthe specification of safety relevant properties driven by theneed for compliance to the upcoming ISO26262 standardThe ISO26262 not only requires comprehensive checking ofrequirements but also states explicitly the need for usingassumptions on the environment to develop a safety relevantelement on the supplier side (ldquosafety element out of contextrdquo)In particular the standard distinguishes betweenbull A functional safety concept comprising the functional
safety requirements their allocation to architectural el-ements and their interaction necessary to achieve thesafety goals This is used to demonstrate that the risksrelated to an item of a vehicle are addressed by anadequate functional architecture
bull A technical safety concept used to demonstrate that thefunctional safety concept is addressed by an adequatetechnical solution
As a simple example for this approach we take the functionalarchitecture of Figure 20 showing the decomposition of theSafeBrakeIndication function into the ldquonormalrdquo BrakeIndicationfunction and the SignalingFailureDetection safety function in casethe BrakeIndication fails The corresponding safety goal requiresthat a loss of the braking indication function shall be detectedThis is formalized as contract CS0 shown in Table XV Thiscontract states that under a given failure hypothesis (ldquonodouble failurerdquo) either the brake lamp is activated or the driveris warned by the SignalingFailureDetection function This contractis attached to the function SafeBrakeIndication
For the subfunction BrakeIndication we show in Table XVIa contract CS1 stating the correct behavior in the absence
RR ndeg 8147
Contracts for System Design 57
CS0
As trueAw Only one of Fail(BrakeIndication)
and Fail(SignalFailureDetection) occursG Whenever BreakRequest occurs then
BreakIndication or SignalFailureDetection is performed
Table XVHORIZONTAL CONTRACT REPRESENTING FUNCTIONAL SAFETY
REQUIREMENT
ltltFunctiongtgt SafeBrakeIndication
ltltFunctiongtgt BrakeIndication
ltltSafetyFunctiongtgt SignalingFailureDetection
ltltFunctionalExchangegtgt BrakeRequest
ltltFunctionalExchangegtgt Detect(BrakeIndicationFail)
Figure 20 Functional architecture including safety function
of a failure of this function For the SignalingFailureDetection
CS1
As trueAw Absence of Fail(BrakeIndication)G Whenever BrakeRequest occurs then
BrakeIndication is performed
Table XVIHORIZONTAL CONTRACT FOR FUNCTION OF BRAKING LAMP
the associated contract states that a detected failure of thesub-function BrakeIndication is correctly indicated under theassumption that the provided function itself is not impacted bya failure see Table XVII An easy manual inspection shows
CS2
As trueAw Absence of fail(SignalingFailureDetection)G Whenever detect(fail(BrakeIndication))
SignalingFailureDetection is performed
Table XVIIHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
that the composition of CS1 otimes CS2 refines CS0 ie we haveformally validated the functional safety concept
The next step consists in allocating these functions tosoftware components on the VFB and developing a simpletechnical safety concept The corresponding technical architec-ture is shown in Figure 21 For the sake of simplicity we onlyconsider corrupted data while transmitting under failure modeThe affected communication links are marked in blue in Fig-ure 21 Thus fail(BrakeIndication) is mapped to fail(pos_pedal) andfail(lamp_intensity) In the same way fail(SignalingFailureDetection)is mapped to fail(mal_indication) This mapping is not furtherelaborated in this paper
For defining the technical safety concept so-called prop-agation contracts are used Propagation contracts expresshow failures (from the environment of the component) are
BrakePedal Sensor
PedalTo Lamp
BrakeLamp Actuator
MalfunctionIndication
lamp_intensity pos_pedal
ext_pedal mal_indication
ext_lamp
ext_indication
Figure 21 Extract of Indicator System
processed by the component According to the ISO 26262 (seeFigure 22) Faults Errors and Failures are distinguished by thepatterns used for the contracts
Figure 22 The role of Faults Errors and failures
For instance the contract CS4 of Table XVIII states that theerror state of the PedalToLamp component is caused by a failurein the communication
CS4
As trueAw trueG Mode PedalToLampError is caused by
fail(pos_pedal)
Table XVIIIHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
The nominal behavior is again given by the contract with anassumption about the absence of the communication failuresee Table XIX
Similarly the error state of the BreakLampActuator iscaused by a failure on the second communication link(fail(lamp_intensity)) or by a failure propagated from the PedalTo-Lamp component see Table XX The nominal behavior of the
RR ndeg 8147
Contracts for System Design 58
CS5
As trueAw Absence of fail(pos_pedal)G Whenever pos_pedal occurs then
lamp_intensity occurs
Table XIXEXEMPLARY CONTRACT FOR NOMINAL BEHAVIOR SPECIFICATION
BrakePedalSensor and the MalfunctionIndicator is formed similarlyto CS5
CS6
As trueAw trueG Mode BreakLampActuatorError is caused by
fail(lamp_intensity) or mode PedalToLampError
Table XXHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
The composition of contracts CS4 CS7
together with thenot stated simple nominal contracts entails the contract CS8
shown on Table XXI stating the functional safety requirement
CS8
As trueAw only one of faila failb failcG Whenever ext_pedal occurs then
ext_lamp or ext_indication occurs
Table XXICONTRACT STATING THE TECHNICAL SAFETY REQUIREMENT
Contract CS8is directly related to the functional safety goal
and includes the allocation to a technical safety concept Thisway a consistency between the functional and the technicalsafety concept has been established Furthermore thanks tothe formal pattern-based specification language the refinementrelations ensure that the concepts themselves are correct
To conclude let us mention other safety related use-caseswhich benefit from contract based specification such as theautomatic generation of fault-trees or FMEA tables as well asthe safe-state management
D Integrating Contracts in AUTOSAR
An important challenge is to smoothly integrate the use ofcontracts as part of AUTOSAR methodology We advocate amigration in two steps
TodaymdashOffering a Smooth Integration of Contract-BasedSystem Engineering with AUTOSAR The metamodel under-lying the CESAR reference technology platform has beencarefully designed to support a seamless design flow fromthe derivation of high-level requirements of new automotivefunctions to the level of detailed application design defined asthe entry point in the AUTOSAR design methodology The keyfor this smooth integration has been laid by AUTOSAR itselfby enforcing a clean separation between application develop-ment on the one side and deployment to distributed target
architectures on the other side Regarding layered design thejoint scope of CESAR and AUTOSAR ranges from systems-of-systems levels for Car2X applications to the introductionof new automotive functions and down to the detailed designlevel As illustrated in the previous section such phases wouldbuild on established design processes and currently used de-sign tools where contracts and viewpoints are conservativelyadded as additional flavor to existing design methodologiesFull hand-over to AUTOSAR takes place at the detailed designstage where component contracts get implemented using theAUTOSAR component model thus providing the entry pointfor the AUTOSAR design methodology
Following the AUTOSAR flow system configurations andECU configurations describe the detailed target hardware Wecan then automatically extract from system and ECU con-figurations all information for performing real-time analysisVertical assumptions on the component level can be derivedby back-annotation from the underlying target hardware Alter-natively vertical assumptions can be seen as constraining thetarget architecture (regarding its timing characteristics) and canthus be used to constrain the design space for possible targetarchitectures Finally when deploying components to ECUscommunications of the virtual functional bus are mapped to theinter-component communications on the physical architecture
The FuturemdashIntegrating Contracts in AUTOSAR The cur-rent AUTOSAR release is expressive enough to represent real-time contracts Using the concept of timing chains both end-to-end deadlines as well as assumed response times for compo-nent execution and communication can be expressed Howeverthe current release was not designed for extensibility thereis no established notion of viewpoints and hence no anchorto easily migrate from the current setting to one supportingmultiple viewpoints As pointed out before the decision asto which viewpoints should or should not be anchored is abusiness decision However given that ISO 26262 has becomebinding we see the need for a systematic integration of thesafety viewpoint
In fact a safety extension has already been proposed forinclusion in AUTOSAR It allows to use contracts for theencapsulation of Basic SoftWare (BSW) modules applicationsoftware components entities of the hardware architecture(like ECUs and buses) and the characterization of commu-nication services Such encapsulation would for instancedistinguish between BSW modules that (1) contribute to safety(safety mechanisms) and (2) those that could potentiallyimpact systemrsquos safety (by providing their failure propagationbehavior) A typical example for (1) would be the func-tion inhibition manager that maintains function inhibitionswhenever for instance implausible outputs are generated Atypical example for (2) would be an error that occurs inthe communication services or an error that is generated incommunication HW that impacts communication services
The objective of the extension is to provide an ISO 26262compliant traceability This allows for instance to deal withcompliance between functional safety (where functions haz-ards and safety functions are collected in the functional
RR ndeg 8147
Contracts for System Design 59
model) and technical safety of the AUTOSAR architectureinstance (guaranteeing that the AUTOSAR implementationmdashusing given safety functions of the AUTOSAR architecturemdashindeed implements the identified functional safety concept)
Since timing and safety viewpoints will be supported inAUTOSAR it is at least worthwhile to consider introducingthe concepts of viewpoints systematically Doing so will easetheir activation at times when other market factors such aspower-management mandate their introduction
E Summary and discussion
We have proposed a smooth path for integrating contractsin the context of AUTOSAR at the level of detailed designWe believe that the main aspects for consideration whileintroducing contracts are the handling of time budgets andthe specification of failure modes and failure propagation incombination with the functional aspect itself Vertical contractswere instrumental in handling time budgets Such contractsrelate two different layers of the AUTOSAR framework
XIII CONCLUSION
This paper presented past and recent results as well asnovel advances in the area of contracts and their theory Byencompassing (functional and non-functional) behaviors thenotion of contract we considered here represents a significantstep beyond the one originally developed in the softwareengineering community
A What contracts can do for the designer
This paper demonstrates that contracts offer a number ofadvantages
Contracts offer a technical support to legal customer-supplier documents Concurrent developmentmdashboth withinand across companiesmdashcalls for smooth coordination andintegration of the different design activities Properly definingand specifying the different concurrent design tasks is andremains a central difficulty Obligations must therefore beagreed upon together with suspensive conditions seen aslegal documents By clearly establishing responsibilities ourformalization of contracts constitutes the technical counterpartof such legal documents Contracts are an enabling technologyfor concurrent development
Contracts offer support to certification By providing for-mal arguments that can assess and guarantee the qualityof a design throughout all design phases (including earlyrequirements capture) contracts offer support for certificationBy providing sophisticated tools in support of modularityreuse in certification is made easier
Contracts comply with formal and semi-formal approachesThe need for being ldquocompletely formalrdquo has hampered for along time formal verification in many industrial sectors inwhich flexibility and intuitive expression in documentationsimulation and testing were and remain preferred As theAUTOSAR use case of Section XII demonstrated using con-tracts makes semi-formal design safer Small analysis stepsare within the reach of human reasoning A valid system
wide analysis for both component-based and refinement-baseddesigns is typically beyond the reach of human reasoningContract based design enables it
Contracts improve requirement engineering As illustratedin the Parking Garage example of Section XI contracts areinstrumental in decoupling top-level system architecture fromthe architecture used for sub-contracting to suppliers Formalsupport is critical in choosing alternative solutions and migrat-ing between different architectures with relatively small effortOf course contracts are not the only important technologyfor requirements engineeringmdashtraceability is essential anddeveloping domain specific ontologies is also important
Contracts can be used in any design process Contractsoffer a orthogonal support for all methodologies and can beused in any flow as a supporting technology in composing andrefining designs
B Status of research
The area of contracts benefits from many advances inresearch that were not targeted to it Interface theories weredeveloped by the community of game theorymdashcomponent andenvironment are seen as two players in a game Modalitiesaimed to offer more expressive logics were born at theboundary between logics and formal verification Contractsas a philosophy originated both from software engineeringand formal verification communities with the paradigms ofPre-conditionPost-condition or AssumeGuarantee It is notuntil the 2000rsquos that the concept of contracts presented hereas a tool to support system design emerged In this evolutionvarious formalisms and theories were borrowed to developa rigorous framework This paper was intended to show thepower of a unified theoretical background for contracts the useof contracts in present methodologies and the challenges for itseffective applications in future applications The mathematicalelegance of the concepts underpinning this area providesconfidence in a sustained continuation of the research effort
C Status of practice
The use of contract-based techniques in system design isin its infancy in industry Further maturation is needed forits paradigm and concepts to become on one side clearand simple to be widely accepted by engineers in their day-to-day work and on the other side developed enough toallow for the development of tools for automatic verificationand synthesis While powerful contract-based proof-of-concepttools are being experimentedmdashsome of them were presentedin this papermdashthe robustness of the tools and the underlyingtechniques is still weak and contract-based design flows andmethodologies are not yet fully developed nor mature
D The way forward
The ability of contracts to accommodate semi-formal andformal methodologies should enable a smooth and rapid mi-gration from theory and proof-of-concepts to robust flows andmethodologies The need for jointly developing new systemswhile considering issues of intellectual property will make
RR ndeg 8147
Contracts for System Design 60
it attractive to rely on contracts in supplier chains In ouropinion contracts are primarily helpful for early stages ofsystem design and particularly requirement engineering whereformal methods are desperately needed to support distributedand concurrent development by independent actors
We have illustrated in this paper how suppliers can be givensub-contracts that are correct by construction and can be auto-matically generated from top-level specification We believehowever that the semi-assistedsemi-manual use of contractssuch as exemplified by our AUTOSAR case study is alreadya significant help useful for requirements engineering tooAltogether a contract engine (such as the MICA tool presentedin Section XI) can be used in combination with both manualreasoning and dedicated formal verification engines (eg fortargeting the timing viewpoint or the safety viewpoint) as thebasis for future development that will make contracts mainstream
REFERENCES
[1] Martiacuten Abadi and Leslie Lamport Conjoining specifications ACMTrans Program Lang Syst 17(3)507ndash534 1995
[2] Yael Abarbanel Ilan Beer Leonid Gluhovsky Sharon Keidar andYaron Wolfsthal FoCs - Automatic Generation of Simulation Checkersfrom Formal Specifications In E Emerson and A Sistla editors Com-puter Aided Verification volume 1855 of Lecture Notes in ComputerScience pages 538ndash542 Springer Berlin Heidelberg 2000
[3] B Thomas Adler Luca de Alfaro Leandro Dias da Silva MarcoFaella Axel Legay Vishwanath Raman and Pritam Roy Ticc A Toolfor Interface Compatibility and Composition In Proc of the 18thInternational Conference on Computer Aided Verification (CAVrsquo06)volume 4144 of Lecture Notes in Computer Science pages 59ndash62Springer 2006
[4] Albert Benveniste and Benoicirct Caillaud and Jean-Baptiste RacletApplication of Interface Theories to the Separate Compilation ofSynchronous Programs In IEEE Conf on Decision and Control dec2012
[5] Luca De Alfaro and Thomas A Henzinger Interface-based design InIn Engineering Theories of Software Intensive Systems proceedings ofthe Marktoberdorf Summer School Kluwer 2004
[6] Rajeev Alur and David L Dill A theory of timed automata TheoreticalComputer Science 126(2)183ndash235 1994
[7] Rajeev Alur Limor Fix and Thomas A Henzinger A determinizableclass of timed automata In David L Dill editor CAV volume 818 ofLecture Notes in Computer Science pages 1ndash13 Springer 1994
[8] Rajeev Alur Limor Fix and Thomas A Henzinger Event-clockautomata A determinizable class of timed automata Theor ComputSci 211(1-2)253ndash273 1999
[9] Rajeev Alur Thomas A Henzinger and Orna Kupferman Alternating-time temporal logic J ACM 49(5)672ndash713 2002
[10] Rajeev Alur Thomas A Henzinger Orna Kupferman and Moshe YVardi Alternating refinement relations In Proc of the 9th InternationalConference on Concurrency Theory (CONCURrsquo98) volume 1466 ofLecture Notes in Computer Science pages 163ndash178 Springer 1998
[11] Adam Antonik Michael Huth Kim G Larsen Ulrik Nyman andAndrzej Wasowski 20 Years of Modal and Mixed SpecificationsBulletin of European Association of Theoretical Computer Science1(94) 2008
[12] Adam Antonik Michael Huth Kim Guldstrand Larsen Ulrik Nymanand Andrzej Wasowski Complexity of Decision Problems for Mixedand Modal Specifications In FoSSaCS pages 112ndash126 2008
[13] Road vehicles ndash functional safety Standard ISO 26262[14] Christel Baier and Joost-Pieter Katoen Principles of Model Checking
MIT Press Cambridge 2008[15] Felice Balarin Jerry R Burch Luciano Lavagno Yosinori Watanabe
Roberto Passerone and Alberto L Sangiovanni-Vincentelli Con-straints specification at higher levels of abstraction In Proceedingsof the Sixth IEEE International High-Level Design Validation and Test
Workshop (HLDVT01) pages 129ndash133 Monterey CA November 7ndash92001 IEEE Computer Society Los Alamitos CA USA
[16] Felice Balarin Abhijit Davare Massimiliano DrsquoAngelo Douglas Dens-more Trevor Meyerowitz Roberto Passerone Alessandro Pinto Al-berto Sangiovanni-Vincentelli Alena Simalatsar Yoshinori WatanabeGuang Yang and Qi Zhu Platform-based design and frameworksMETROPOLIS and METRO II In Gabriela Nicolescu and Pieter JMosterman editors Model-Based Design for Embedded Systems chap-ter 10 page 259 CRC Press Taylor and Francis Group Boca RatonLondon New York November 2009
[17] Felice Balarin and Roberto Passerone Functional verification method-ology based on formal interface specification and transactor generationIn Proceedings of the Conference on Design Automation and Test inEurope (DATE06) pages 1013ndash1018 Munich Germany March 6ndash102006 European Design and Automation Association 3001 LeuvenBelgium
[18] Felice Balarin and Roberto Passerone Specification synthesis andsimulation of transactor processes IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 26(10)1749ndash1762October 2007
[19] Felice Balarin Roberto Passerone Alessandro Pinto and Alberto LSangiovanni-Vincentelli A formal approach to system level designMetamodels and unified design environments In Proceedings of theThird ACM and IEEE International Conference on Formal Methodsand Models for Co-Design (MEMOCODE05) pages 155ndash163 VeronaItaly July 11ndash14 2005 IEEE Computer Society Los Alamitos CAUSA
[20] Felice Balarin Yosinori Watanabe Harry Hsieh Luciano LavagnoClaudio Passerone and Alberto L Sangiovanni-Vincentelli Metropo-lis An Integrated Electronic System Design Environment IEEEComputer 36(4)45ndash52 2003
[21] Krishnakumar Balasubramanian Aniruddha Gokhale Gabor KarsaiJanos Sztipanovits and Sandeep Neema Developing applicationsusing model-driven design environments IEEE Computer 39(2)33ndash40 2006
[22] Sebastian S Bauer Alexandre David Rolf Hennicker Kim GuldstrandLarsen Axel Legay Ulrik Nyman and Andrzej Wasowski Movingfrom specifications to contracts in component-based design In Juande Lara and Andrea Zisman editors FASE volume 7212 of LectureNotes in Computer Science pages 43ndash58 Springer 2012
[23] Sebastian S Bauer Philip Mayer Andreas Schroeder and Rolf Hen-nicker On Weak Modal Compatibility Refinement and the MIOWorkbench In Proc of 16th International Conference on Tools andAlgorithms for the Construction and Analysis of Systems (TACASrsquo10)volume 6015 of Lecture Notes in Computer Science pages 175ndash189Springer 2010
[24] Andreas Baumgart Eckard Boumlde Matthias Buumlker Werner Damm Guumln-ter Ehmen Tayfun Gezgin Stefan Henkler Hardi Hungar BernhardJosko Markus Oertel Thomas Peikenkamp Philipp Reinkemeier IngoStierand and Raphael Weber Architecture Modeling Technical reportOFFIS March 2011
[25] Nikola Benes Jan Kretiacutenskyacute Kim Guldstrand Larsen and Jiriacute SrbaChecking Thorough Refinement on Modal Transition Systems IsEXPTIME-Complete In Martin Leucker and Carroll Morgan editorsICTAC volume 5684 of Lecture Notes in Computer Science pages112ndash126 Springer 2009
[26] Nikola Benes Jan Kretiacutenskyacute Kim Guldstrand Larsen and Jiriacute SrbaOn determinism in modal transition systems Theoretical ComputerScience 410(41)4026ndash4043 2009
[27] Benoicirct Caillaud and Jean-Baptiste Raclet Ensuring Reachability byDesign In Int Colloquium on Theoretical Aspects of Computing sept2012
[28] Albert Benveniste and Geacuterard Berry The synchronous approach toreactive and real-time systems Proceedings of the IEEE 79(9)1270ndash1282 1991
[29] Albert Benveniste Benoicirct Caillaud Alberto Ferrari LeonardoMangeruca Roberto Passerone and Christos Sofronis Multiple view-point contract-based specification and design In Proceedings of theSoftware Technology Concertation on Formal Methods for Componentsand Objects FMCOrsquo07 volume 5382 of Lecture Notes in ComputerScience pages 200ndash225 Springer October 2008
[30] Albert Benveniste Paul Caspi Stephen A Edwards Nicolas Halb-wachs Paul Le Guernic and Robert de Simone The SynchronousLanguages 12 years later Proceedings of the IEEE 91(1)64ndash83 2003
RR ndeg 8147
Contracts for System Design 61
[31] Luca Benvenuti Alberto Ferrari Leonardo Mangeruca EmanueleMazzi Roberto Passerone and Christos Sofronis A contract-basedformalism for the specification of heterogeneous systems In Proceed-ings of the Forum on Specification Verification and Design Languages(FDL08) pages 142ndash147 Stuttgart Germany September 23ndash25 2008
[32] Gerard Berry The effectiveness of synchronous languages for thedevelopment of safety-critical systems White paper Esterel Technolo-gies 2003
[33] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet A compositional approach on modal specifications for timedsystems In Proc of the 11th International Conference on FormalEngineering Methods (ICFEMrsquo09) volume 5885 of Lecture Notes inComputer Science pages 679ndash697 Springer 2009
[34] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet Modal event-clock specifications for timed component-baseddesign Science of Computer Programming 2011 To appear
[35] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet Modal event-clock specifications for timed component-baseddesign Science of Computer Programming 2012 to appear
[36] Nathalie Bertrand Sophie Pinchinat and Jean-Baptiste Raclet Refine-ment and consistency of timed modal specifications In Proc of the3rd International Conference on Language and Automata Theory andApplications (LATArsquo09) volume 5457 of Lecture Notes in ComputerScience pages 152ndash163 Springer 2009
[37] Antoine Beugnard Jean-Marc Jeacutezeacutequel and Noeumll Plouzeau Makingcomponents contract aware IEEE Computer 32(7)38ndash45 1999
[38] Dirk Beyer Arindam Chakrabarti and Thomas A Henzinger Webservice interfaces In Allan Ellis and Tatsuya Hagino editors WWWpages 148ndash159 ACM 2005
[39] Purandar Bhaduri and S Ramesh Interface synthesis and protocolconversion Formal Aspects of Computing 20(2)205ndash224 2008
[40] Purandar Bhaduri and Ingo Stierand A proposal for real-time interfacesin speeds In Design Automation and Test in Europe (DATErsquo10) pages441ndash446 IEEE 2010
[41] Simon Bliudze and Joseph Sifakis The Algebra of Connectors -Structuring Interaction in BIP IEEE Trans Computers 57(10)1315ndash1330 2008
[42] R Bloem and B Jobstmann Manual for property-based synthesis toolTechnical Report Prosyd D223 2006
[43] Roderick Bloem Alessandro Cimatti Karin Greimel Georg HofferekRobert Koumlnighofer Marco Roveri Viktor Schuppan and RichardSeeber RATSY - A New Requirements Analysis Tool with SynthesisIn Tayssir Touili Byron Cook and Paul Jackson editors CAV volume6174 of Lecture Notes in Computer Science pages 425ndash429 Springer2010
[44] Grady Booch James Rumbaugh and Ivar Jacobson Unified ModelingLanguage User Guide The (2nd Edition) (Addison-Wesley ObjectTechnology Series) Addison-Wesley Professional 2005
[45] Amar Bouali XEVE an Esterel Verification Environment In Alan JHu and Moshe Y Vardi editors CAV volume 1427 of Lecture Notesin Computer Science pages 500ndash504 Springer 1998
[46] Geacuterard Boudol and Kim Guldstrand Larsen Graphical versus logicalspecifications Theor Comput Sci 106(1)3ndash20 1992
[47] Jerry R Burch Trace Algebra for Automatic Verification of Real-Time Concurrent Systems PhD thesis School of Computer ScienceCarnegie Mellon University August 1992
[48] Jerry R Burch Roberto Passerone and Alberto L Sangiovanni-Vincentelli Overcoming heterophobia Modeling concurrency in het-erogeneous systems In Proceedings of the 2nd International Confer-ence on Application of Concurrency to System Design (ACSD01) pages13ndash32 Newcastle upon Tyne UK June 25ndash29 2001 IEEE ComputerSociety Los Alamitos CA USA
[49] Benoicirct Caillaud Mica A Modal Interface Compositional AnalysisLibrary October 2011 httpwwwirisafrs4toolsmica
[50] Benoicirct Caillaud Benoicirct Delahaye Kim G Larsen Axel LegayMikkel Larsen Pedersen and Andrzej Wasowski Compositional designmethodology with constraint Markov chains In Proceedings of the7th International Conference on Quantitative Evaluation of SysTems(QEST) 2010 IEEE Computer Society 2010
[51] Daniela Cancila Roberto Passerone Tullio Vardanega and MarcoPanunzio Toward correctness in the specification and handling ofnon-functional attributes of high-integrity real-time embedded systemsIEEE Transactions on Industrial Informatics 6(2)181ndash194 May 2010
[52] Karlis Cerans Jens Chr Godskesen and Kim Guldstrand LarsenTimed Modal Specification - Theory and Tools In Costas Courcou-betis editor CAV volume 697 of Lecture Notes in Computer Sciencepages 253ndash267 Springer 1993
[53] Pavol Cernyacute Martin Chmelik Thomas A Henzinger and ArjunRadhakrishna Interface simulation distances In Marco Faella andAniello Murano editors GandALF volume 96 of EPTCS pages 29ndash42 2012
[54] Arindam Chakrabarti A Framework for Compositional Design andAnalysis of Systems PhD thesis EECS Department University ofCalifornia Berkeley Dec 2007
[55] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger MarcinJurdzinski and Freddy Y C Mang Interface compatibility checkingfor software modules In Ed Brinksma and Kim Guldstrand Larseneditors CAV volume 2404 of Lecture Notes in Computer Sciencepages 428ndash441 Springer 2002
[56] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger andFreddy Y C Mang Synchronous and Bidirectional Component Inter-faces In Proc of the 14th International Conference on Computer AidedVerification (CAVrsquo02) volume 2404 of Lecture Notes in ComputerScience pages 414ndash427 Springer 2002
[57] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger andMarieumllle Stoelinga Resource Interfaces In Rajeev Alur and InsupLee editors EMSOFT volume 2855 of Lecture Notes in ComputerScience pages 117ndash133 Springer 2003
[58] Edward Y Chang Zohar Manna and Amir Pnueli Characterizationof temporal property classes In Werner Kuich editor ICALP volume623 of Lecture Notes in Computer Science pages 474ndash486 Springer1992
[59] Taolue Chen Chris Chilton Bengt Jonsson and Marta ZKwiatkowska A compositional specification theory for componentbehaviours In Helmut Seidl editor ESOP volume 7211 of LectureNotes in Computer Science pages 148ndash168 Springer 2012
[60] Chris Chilton Marta Z Kwiatkowska and Xu Wang Revisiting timedspecification theories A linear-time perspective In Marcin Jurdzinskiand Dejan Nickovic editors FORMATS volume 7595 of Lecture Notesin Computer Science pages 75ndash90 Springer 2012
[61] E Clarke O Grumberg and D Peled Model Checking MIT Press1999
[62] Edmund M Clarke David E Long and Kenneth L McMillanCompositional model checking In LICS pages 353ndash362 1989
[63] W Damm E Thaden I Stierand T Peikenkamp and H HungarUsing Contract-Based Component Specifications for Virtual Integra-tion and Architecture Design In Proceedings of the 2011 DesignAutomation and Test in Europe (DATErsquo11) March 2011 To appear
[64] Werner Damm and David Harel LSCs Breathing life into messagesequence charts Formal Methods in System Design 19(1)45ndash80 2001
[65] Werner Damm Angelika Votintseva Alexander Metzner BernhardJosko Thomas Peikenkamp and Eckard Boumlde Boosting reuse ofembedded automotive applications through rich components In Pro-ceedings of FIT 2005 - Foundations of Interface Technologies 2005
[66] Werner Damm and Bernd Westphal Live and let die LSC basedverification of UML models Sci Comput Program 55(1-3)117ndash1592005
[67] Abhijit Davare Douglas Densmore Trevor Meyerowitz AlessandroPinto Alberto Sangiovanni-Vincentelli Guang Yang and Qi Zhu Anext-generation design framework for platform-based design In DesignVerification Conference (DVCon) San Josersquo California 2007
[68] Alexandre David Kim G Larsen Axel Legay Ulrik Nyman andAndrzej Wasowski Timed IO automata A complete specificationtheory for real-time systems In Proc of the 13th ACM InternationalConference on Hybrid Systems Computation and Control (HSCCrsquo10)pages 91ndash100 ACM 2010
[69] Alexandre David Kim Guldstrand Larsen Axel Legay Ulrik Nymanand Andrzej Wasowski ECDAR An Environment for CompositionalDesign and Analysis of Real Time Systems In Proc of the 8thInternational Symposium on Automated Technology for Verificationand Analysis (ATVArsquo10) volume 6252 of Lecture Notes in ComputerScience pages 365ndash370 2010
[70] Luca de Alfaro Game Models for Open Systems In VerificationTheory and Practice volume 2772 of Lecture Notes in ComputerScience pages 269ndash289 Springer 2003
[71] Luca de Alfaro Leandro Dias da Silva Marco Faella Axel LegayPritam Roy and Maria Sorea Sociable Interfaces In Proc of
RR ndeg 8147
Contracts for System Design 62
the 5th International Workshop on Frontiers of Combining Systems(FroCosrsquo05) volume 3717 of Lecture Notes in Computer Sciencepages 81ndash105 Springer 2005
[72] Luca de Alfaro and Thomas A Henzinger Interface automata In Procof the 9th ACM SIGSOFT International Symposium on Foundations ofSoftware Engineering (FSErsquo01) pages 109ndash120 ACM Press 2001
[73] Luca de Alfaro and Thomas A Henzinger Interface theories forcomponent-based design In Thomas A Henzinger and Christoph MKirsch editors EMSOFT volume 2211 of Lecture Notes in ComputerScience pages 148ndash165 Springer 2001
[74] Luca de Alfaro Thomas A Henzinger and Marieumllle Stoelinga TimedInterfaces In Proc of the 2nd International Workshop on EmbeddedSoftware (EMSOFTrsquo02) volume 2491 of Lecture Notes in ComputerScience pages 108ndash122 Springer 2002
[75] Benoicirct Delahaye Modular Specification and Compositional Analysisof Stochastic Systems PhD thesis Universiteacute de Rennes 1 2010
[76] Benoicirct Delahaye Benoicirct Caillaud and Axel Legay ProbabilisticContracts A Compositional Reasoning Methodology for the Designof Stochastic Systems In Proc 10th International Conference onApplication of Concurrency to System Design (ACSD) Braga PortugalIEEE 2010
[77] Benoicirct Delahaye Benoicirct Caillaud and Axel Legay Probabilisticcontracts A compositional reasoning methodology for the designof systems with stochastic andor non-deterministic aspects FormalMethods in System Design 2011 To appear
[78] Benoicirct Delahaye Uli Fahrenberg Thomas A Henzinger Axel Legayand Dejan Nickovic Synchronous interface theories and time trig-gered scheduling In Holger Giese and Grigore Rosu editorsFMOODSFORTE volume 7273 of Lecture Notes in Computer Sci-ence pages 203ndash218 Springer 2012
[79] Benoicirct Delahaye Joost-Pieter Katoen Kim G Larsen Axel LegayMikkel L Pedersen Falak Sher and Andrzej Wasowski AbstractProbabilistic Automata In Ranjit Jhala and David A Schmidt editorsVMCAI volume 6538 of Lecture Notes in Computer Science pages324ndash339 Springer 2011
[80] Douglas Densmore Sanjay Rekhi and Alberto L Sangiovanni-Vincentelli Microarchitecture Development via Metropolis SuccessivePlatform Refinement In DATE pages 346ndash351 IEEE ComputerSociety 2004
[81] David L Dill Trace Theory for Automatic Hierarchical Verificationof Speed-Independent Circuits ACM Distinguished Dissertations MITPress 1989
[82] Nicolaacutes DrsquoIppolito Dario Fischbein Marsha Chechik and SebastiaacutenUchitel MTSA The Modal Transition System Analyser In Proc ofthe 23rd IEEEACM International Conference on Automated SoftwareEngineering (ASErsquo08) pages 475ndash476 IEEE 2008
[83] Laurent Doyen Thomas A Henzinger Barbara Jobstmann and TatjanaPetrov Interface theories with component reuse In Proceedings of the8th ACM amp IEEE International conference on Embedded softwareEMSOFTrsquo08 pages 79ndash88 2008
[84] Dumitru Potop-Butucaru and Stephen Edwards and Geacuterard BerryCompiling Esterel Springer V 2007 ISBN 0387706267
[85] Cindy Eisner PSL for Runtime Verification Theory and Practice InOleg Sokolsky and Serdar Tasiran editors RV volume 4839 of LectureNotes in Computer Science pages 1ndash8 Springer 2007
[86] Cindy Eisner Dana Fisman John Havlicek Michael JC GordonAnthony McIsaac and David Van Campenhout Formal Syntax andSemantics of PSL - Appendix B of Accellera LRM January 2003Technical report IBM 2003
[87] Cindy Eisner Dana Fisman John Havlicek Yoad Lustig AnthonyMcIsaac and David Van Campenhout Reasoning with temporal logicon truncated paths In Warren A Hunt Jr and Fabio Somenzi editorsCAV volume 2725 of Lecture Notes in Computer Science pages 27ndash39Springer 2003
[88] Johan Eker Joumlrn W Janneck Edward A Lee Jie Liu Xiaojun LiuJ Ludvig Stephen Neuendorffer S Sachs and Yuhong Xiong Tamingheterogeneity - the ptolemy approach Proc of the IEEE 91(1)127ndash144 2003
[89] G Feuillade Modal specifications are a syntactic fragment of the Mu-calculus Research Report RR-5612 INRIA June 2005
[90] Dario Fischbein and Sebastiaacuten Uchitel On correct and completestrong merging of partial behaviour models In Proc of the 16thACM SIGSOFT International Symposium on Foundations of SoftwareEngineering (SIGSOFT FSErsquo08) pages 297ndash307 ACM 2008
[91] F Fleurey P A Muller and J M Jzquel Weaving executabilityinto object-oriented meta-languages In Proceedgins of the 8th In-ternational Conference on Model Driven Engineering Languages andSystems (MODELS05) October 2005
[92] Freacutedeacuteric Boussinot and Robert de Simone The Esterel languageProceedings of the IEEE 79(9)1293ndash1304 1991
[93] Peter Fritzson Principles of Object-Oriented Modeling and Simulationwith Modelica 21 Wiley 2003
[94] Tayfun Gezgin Raphael Weber and Maurice Girod A RefinementChecking Technique for Contract-Based Architecture Designs InFourth International Workshop on Model Based Architecting andConstruction of Embedded Systems ACES-MBrsquo11 volume 7167 ofLecture Notes in Computer Science Springer October 2011
[95] Jens Chr Godskesen Kim Guldstrand Larsen and Arne Skou Auto-matic verification of real-time systems using Epsilon In Son T Vuongand Samuel T Chanson editors PSTV volume 1 of IFIP ConferenceProceedings pages 323ndash330 Chapman amp Hall 1994
[96] G Goumlssler and J-B Raclet Modal Contracts for Component-basedDesign In Proc of the 7th IEEE International Conference on SoftwareEngineering and Formal Methods (SEFMrsquo09) IEEE Computer SocietyPress November 2009
[97] Susanne Graf and Sophie Quinton Contracts for BIP HierarchicalInteraction Models for Compositional Verification In John Derrick andJuumlri Vain editors FORTE volume 4574 of Lecture Notes in ComputerScience pages 1ndash18 Springer 2007
[98] Orna Grumberg and David E Long Model checking and modularverification ACM Trans Program Lang Syst 16(3)843ndash871 1994
[99] Imene Ben Hafaiedh Susanne Graf and Sophie Quinton Reasoningabout Safety and Progress Using Contracts In Proc of ICFEMrsquo10volume 6447 of LNCS pages 436ndash451 Springer 2010
[100] Nicolas Halbwachs Synchronous programming of reactive systemsKluwer Academic Pub 1993
[101] Nicolas Halbwachs Fabienne Lagnier and Christophe Ratel Program-ming and Verifying Real-Time Systems by Means of the SynchronousData-Flow Language Lustre IEEE Trans Software Eng 18(9)785ndash793 1992
[102] Nicolas Halbwachs Fabienne Lagnier and Pascal Raymond Syn-chronous observers and the verification of reactive systems In MauriceNivat Charles Rattray Teodor Rus and Giuseppe Scollo editorsAMAST Workshops in Computing pages 83ndash96 Springer 1993
[103] Nicolas Halbwachs and Pascal Raymond Validation of synchronousreactive systems From formal verification to automatic testing In P SThiagarajan and Roland H C Yap editors ASIAN volume 1742 ofLecture Notes in Computer Science pages 1ndash12 Springer 1999
[104] David Harel Statecharts A visual formalism for complex systemsSci Comput Program 8(3)231ndash274 1987
[105] David Harel Hillel Kugler Shahar Maoz and Itai Segall Acceleratingsmart play-out In Jan van Leeuwen Anca Muscholl David PelegJaroslav Pokornyacute and Bernhard Rumpe editors SOFSEM volume5901 of Lecture Notes in Computer Science pages 477ndash488 Springer2010
[106] David Harel Robby Lampert Assaf Marron and Gera Weiss Model-checking behavioral programs In Samarjit Chakraborty Ahmed Jer-raya Sanjoy K Baruah and Sebastian Fischmeister editors EMSOFTpages 279ndash288 ACM 2011
[107] David Harel and Rami Marelly Come Letrsquos Play Scenario-BasedProgramming Using LSCs and the Play-Engine Springer-Verlag 2003httpwwwwisdomweizmannacil~harelComeLetsPlaypdf
[108] David Harel Assaf Marron and Gera Weiss Behavioral programmingCommun ACM 55(7)90ndash100 2012
[109] David Harel Assaf Marron Guy Wiener and Gera Weiss Behavioralprogramming decentralized control and multiple time scales InCristina Videira Lopes editor SPLASH Workshops pages 171ndash182ACM 2011
[110] David Harel and Amir Pnueli On the development of reactive systemsIn K R Apt editor Logic and Models for Verification and Specificationof Concurrent Systems volume F13 of NATO ASI Series pages 477ndash498 Springer-Verlag 1985
[111] H Heinecke W Damm B Josko A Metzner H KopetzA Sangiovanni-Vincentelli and M Di Natale Software Componentsfor Reliable Automotive Systems In Design Automation and Test inEurope 2008 DATE rsquo08 pages 549ndash554 march 2008
[112] Thomas A Henzinger and Dejan Nickovic Independent imple-mentability of viewpoints In Radu Calinescu and David Garlan edi-
RR ndeg 8147
Contracts for System Design 63
tors Monterey Workshop volume 7539 of Lecture Notes in ComputerScience pages 380ndash395 Springer 2012
[113] C A R Hoare An axiomatic basis for computer programmingCommun ACM 12(10)576ndash580 1969
[114] INCOSE Incose systems engineering handbook 2010 httpwwwincoseorgProductsPubsproductssehandbookaspx
[115] Cliff B Jones Specification and design of (parallel) programs In IFIPCongress pages 321ndash332 1983
[116] B Jonsson and K G Larsen Specification and refinement ofprobabilistic processes In Logic in Computer Science (LICS) pages266ndash277 IEEE Computer 1991
[117] Gilles Kahn The Semantics of Simple Language for Parallel Program-ming In IFIP Congress pages 471ndash475 1974
[118] S Karris Introduction to Simulink with Engineering ApplicationsOrchard Publications 2006
[119] G Karsai J Sztipanovits A Ledeczi and T Bapty Model-integrated development of embedded software Proceedings of theIEEE 91(1)145ndash164 January 2003
[120] Gabor Karsai Janos Sztipanovitz Akos Ledczi and Ted Bapty Model-integrated development of embedded software Proceedings of theIEEE 91(1) January 2003
[121] Orna Kupferman and Moshe Y Vardi Modular model checking InWillem P de Roever Hans Langmaack and Amir Pnueli editorsCOMPOS volume 1536 of Lecture Notes in Computer Science pages381ndash401 Springer 1997
[122] Leslie Lamport Proving the correctness of multiprocess programsIEEE Trans Software Eng 3(2)125ndash143 1977
[123] C Larman and VR Basili Iterative and incremental developments abrief history Computer 36(6)47ndash56 June 2003
[124] Kim G Larsen and L Xinxin Equation solving using modal transitionsystems In Proceedings of the 5th Annual IEEE Symp on Logic inComputer Science LICSrsquo90 pages 108ndash117 IEEE Computer SocietyPress 1990
[125] Kim Guldstrand Larsen Modal specifications In Automatic Verifica-tion Methods for Finite State Systems volume 407 of Lecture Notes inComputer Science pages 232ndash246 Springer 1989
[126] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski In-terface InputOutput Automata In Jayadev Misra Tobias Nipkowand Emil Sekerinski editors FM volume 4085 of Lecture Notes inComputer Science pages 82ndash97 Springer 2006
[127] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski ModalIO Automata for Interface and Product Line Theories In ProgrammingLanguages and Systems 16th European Symposium on ProgrammingESOPrsquo07 volume 4421 of Lecture Notes in Computer Science pages64ndash79 Springer 2007
[128] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski OnModal Refinement and Consistency In Proc of the 18th InternationalConference on Concurrency Theory (CONCURrsquo07) pages 105ndash119Springer 2007
[129] Kim Guldstrand Larsen Bernhard Steffen and Carsten Weise A con-straint oriented proof methodology based on modal transition systemsIn Proc of the 1st International Workshop on Tools and Algorithmsfor Construction and Analysis of Systems (TACASrsquo95) volume 1019of Lecture Notes in Computer Science pages 17ndash40 Springer 1995
[130] Kim Guldstrand Larsen and Bent Thomsen A Modal Process LogicIn Proceedings of the Third Annual Symposium on Logic in ComputerScience (LICSrsquo88) pages 203ndash210 IEEE 1988
[131] A Ledeczi A Bakay M Maroti P Volgyesi G Nordstrom J Sprin-kle and G Karsai Composing domain-specific design environmentsIEEE Computer 34(11)44 ndash51 November 2001
[132] Akos Ledeczi Miklos Maroti Arpad Bakay Gabor Karsai JasonGarrett Charles Thomason Greg Nordstrom Jonathan Sprinkle andPeter Volgyesi The generic modeling environment In Proceedingsof the IEEE International Workshop on Intelligent Signal Processing(WISP2001) Budapest Hungary May 24ndash25 2001
[133] Edward A Lee Cyber physical systems Design challenges TechnicalReport UCBEECS-2008-8 EECS Department University of Califor-nia Berkeley Jan 2008
[134] Nancy A Lynch Inputoutput automata Basic timed hybrid proba-bilistic dynamic In Roberto M Amadio and Denis Lugiez editorsCONCUR volume 2761 of Lecture Notes in Computer Science pages187ndash188 Springer 2003
[135] Nancy A Lynch and Eugene W Stark A proof of the kahn principlefor inputoutput automata Inf Comput 82(1)81ndash92 1989
[136] Zohar Manna and Amir Pnueli Temporal verification of reactivesystems Safety Springer 1995
[137] Herveacute Marchand Patricia Bournai Michel Le Borgne and Paul LeGuernic Synthesis of Discrete-Event Controllers Based on the SignalEnvironment Discrete Event Dynamic Systems 10(4)325ndash346 2000
[138] Herveacute Marchand and Mazen Samaan Incremental Design of aPower Transformer Station Controller Using a Controller SynthesisMethodology IEEE Trans Software Eng 26(8)729ndash741 2000
[139] B Meyer Applying ldquodesign by contractrdquo IEEE Computer 25(10)40ndash51 October 1992
[140] Bertrand Meyer Touch of Class Learning to Program Well UsingObject Technology and Design by Contract Springer SoftwareEngineering 2009
[141] MW Maier Architecting Principles for Systems of Systems SystemsEngineering 1(4)267ndash284 1998
[142] Walid A Najjar Edward A Lee and Guang R Gao Advances in thedataflow computational model Parallel Computing 25(13-14)1907ndash1929 1999
[143] Radu Negulescu Process Spaces and the Formal Verification ofAsynchronous Circuits PhD thesis University of Waterloo Canada1998
[144] Nicolas Halbwachs and Paul Caspi and Pascal Raymond and DanielPilaud The synchronous data flow programming language LustreProceedings of the IEEE 79(9)1305ndash1320 1991
[145] P Nuzzo A Sangiovanni-Vincentelli X Sun and A PuggelliMethodology for the design of analog integrated interfaces usingcontracts IEEE Sensors Journal 12(12)3329ndash3345 Dec 2012
[146] Object Management Group (OMG) Model driven architecture (MDA)FAQ [online] httpwwwomgorgmda
[147] Object Management Group (OMG) Unified Modeling Language(UML) specification [online] httpwwwomgorgspecUML
[148] Object Management Group (OMG) A UML profile for MARTE beta1 OMG Adopted Specification ptc07-08-04 OMG August 2007
[149] Object Management Group (OMG) System modeling languagespecification v11 Technical report OMG 2008
[150] Object constraint language version 20 OMG Available Specificationformal06-05-01 Object Management Group May 2006
[151] The Design Automation Standards Committee of the IEEE Com-puter Society editor 1850-2010 - IEEE Standard for PropertySpecification Language (PSL) IEEE Computer Society 2010
[152] J Hudak P Feiler D Gluch The Architecture Analysis and DesignLanguage (AADL) An Introduction Software Engineering Institute(SEI) Technical Note CMUSEI-2006-TN-011 February 2006
[153] Roberto Passerone Semantic Foundations for Heterogeneous SystemsPhD thesis Department of Electrical Engineering and Computer Sci-ences University of California Berkeley Berkeley CA 94720 May2004
[154] Roberto Passerone Jerry R Burch and Alberto L Sangiovanni-Vincentelli Refinement preserving approximations for the design andverification of heterogeneous systems Formal Methods in SystemDesign 31(1)1ndash33 August 2007
[155] Roberto Passerone Luca de Alfaro Thomas A Henzinger and AlbertoSangiovanni-Vincentelli Convertibility verification and converter syn-thesis Two faces of the same coin In Proceedings of InternationalConference on Computer Aided Design San Jose CA 2002
[156] Roberto Passerone Imene Ben Hafaiedh Susanne Graf Albert Ben-veniste Daniela Cancila Arnaud Cuccuru Seacutebastien Geacuterard FrancoisTerrier Werner Damm Alberto Ferrari Leonardo Mangeruca Bern-hard Josko Thomas Peikenkamp and Alberto Sangiovanni-VincentelliMetamodels in Europe Languages tools and applications IEEEDesign and Test of Computers 26(3)38ndash53 MayJune 2009
[157] Paul Le Guernic and Thiserry Gautier and Michel Le Borgne andClaude Le Maire Programming real-time applications with SignalProceedings of the IEEE 79(9)1321ndash1336 1991
[158] I Pill B Jobstmann R Bloem R Frank M Moulin B SterinM Roveri and S Semprini Property simulation Technical ReportProsyd D121 2005
[159] Dumitru Potop-Butucaru Benoicirct Caillaud and Albert BenvenisteConcurrency in synchronous systems Formal Methods in SystemDesign 28(2)111ndash130 2006
[160] Dumitru Potop-Butucaru Robert de Simone and Yves Sorel Neces-sary and sufficient conditions for deterministic desynchronization InChristoph M Kirsch and Reinhard Wilhelm editors EMSOFT pages124ndash133 ACM 2007
RR ndeg 8147
Contracts for System Design 64
[161] Terry Quatrani Visual modeling with Rational Rose 2000 and UML(2nd ed) Addison-Wesley Longman Ltd Essex UK UK 2000
[162] R Sudarsan and SJ Fenves and RD Sriram and F Wang A productinformation modeling framework for product lifecycle managementComputer-Aided Design 371399ndash1411 2005
[163] Jean-Baptiste Raclet Quotient de speacutecifications pour la reacuteutilisationde composants PhD thesis Ecole doctorale Matisse universiteacute deRennes 1 November 2007
[164] Jean-Baptiste Raclet Residual for Component Specifications In Procof the 4th International Workshop on Formal Aspects of ComponentSoftware (FACSrsquo07) 2007
[165] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct CaillaudAxel Legay and Roberto Passerone Modal interfaces Unifyinginterface automata and modal specifications In Proceedings of theNinth International Conference on Embedded Software (EMSOFT09)pages 87ndash96 Grenoble France October 12ndash16 2009
[166] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct CaillaudAxel Legay and Roberto Passerone A modal interface theory forcomponent-based design Fundamenta Informaticae 108(1-2)119ndash149 2011
[167] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct Caillaudand Roberto Passerone Why are modalities good for interfacetheories In Proc of the 9th International Conference on Applicationof Concurrency to System Design (ACSDrsquo09) IEEE Computer SocietyPress 2009
[168] Richard Payne and John Fitzgerald Evaluation of ArchitecturalFrameworks Supporting Contract-Based Specification Technical Re-port CS-TR-1233 Computing Science Newcastle University UK Dec2010 available from httpwwwcsnclacukpublicationstrspapers1233pdf
[169] Robert W Floyd Assigning meaning to programs In JT Schwartzeditor Proceedings of Symposium on Applied Mathematics volume 19pages 19ndash32 1967
[170] A Sangiovanni-Vincentelli S Shukla J Sztipanovits G Yang andD Mathaikutty Metamodeling An emerging representation paradigmfor system-level design Special Section on Meta-Modeling IEEEDesign and Test 26(3)54ndash69 2009
[171] Alberto Sangiovanni-Vincentelli Quo vadis sld Reasoning aboutthe trends and challenges of system level design Proc of the IEEE95(3)467ndash506 2007
[172] D Schmidt Model-driven engineering IEEE Computer pages 25ndash31February 2006
[173] German Sibay Sebastian Uchitel and Viacutector Braberman ExistentialLive Sequence Charts Revisited In ICSE 2008 30th InternationalConference on Software Engineering ACM May 2008
[174] Joseph Sifakis Component-Based Construction of HeterogeneousReal-Time Systems in Bip In Giuliana Franceschinis and KarstenWolf editors Petri Nets volume 5606 of Lecture Notes in ComputerScience page 1 Springer 2009
[175] Functional safety of electricalelectronicprogrammable electronicsafety-related systems Standard IEC 61508
[176] Eugene W Stark A proof technique for relyguarantee properties InS N Maheshwari editor FSTTCS volume 206 of Lecture Notes inComputer Science pages 369ndash391 Springer 1985
[177] Stavros Tripakis Ben Lickly Thomas A Henzinger and Edward ALee On relational interfaces In Proc of the 9th ACM amp IEEEInternational conference on Embedded software (EMSOFTrsquo09) pages67ndash76 ACM 2009
[178] Stavros Tripakis Ben Lickly Thomas A Henzinger and Edward ALee A theory of synchronous relational interfaces ACM TransProgram Lang Syst 33(4)14 2011
[179] Sebastiaacuten Uchitel and Marsha Chechik Merging partial behaviouralmodels In Proc of the 12th ACM SIGSOFT International Symposiumon Foundations of Software Engineering (SIGSOFT FSErsquo10) pages43ndash52 ACM 2004
[180] Jos Warmer and Anneke Kleppe The Object Constraint LanguageGetting Your Models Ready for MDA Addison-Wesley LongmanPublishing Co Inc Boston MA USA 2nd edition 2003
RR ndeg 8147
RESEARCH CENTRERENNES ndash BRETAGNE ATLANTIQUE
Campus universitaire de Beaulieu35042 Rennes Cedex
PublisherInriaDomaine de Voluceau - RocquencourtBP 105 - 78153 Le Chesnay Cedexinriafr
ISSN 0249-6399
- Introduction
-
- The Present System Design
- The Future CPS and SoS
- The Need for a Methodological Effort
- Contract based design
- Readers guide
-
- System Design Challenges
-
- Complexity of Systems
- Complexity of OEM-Supplier Chains
- Managing Requirements
- Managing Risks
- System-wide Optimization
-
- How Challenges have been addressed so far
-
- Complexity of Systems and System-wide Optimization
-
- Layered design
- Component-based design
- The V-model process
- Model-Based Design
- Virtual Integration
- Platform Based Design
-
- Complexity of OEM-Supplier Chains Standardization and Harmonization
-
- Standardization of design entities
- Harmonization of processes and certification
-
- Managing Requirements Traceability and Multiple Viewpoints
- Cross-company Shared Risk Management
- The Need for Contracts
-
- Contracts what why where and how
-
- Contracts
-
- Components and their Environment Contracts
-
- Contract Operators
-
- Contract Composition and System Integration
- Contract Refinement and Independent Development
- Contract Conjunction and Viewpoint Fusion
-
- Contracts in requirement engineering
- Contract Support for Design Methodologies
-
- Supporting open systems
- Managing Requirements and Fusing Viewpoints
- Design Chain Management Re-using and Independent Development
- Deployment and Mapping
-
- Bibliographical note
-
- A Mathematical Meta-theory of Contracts
-
- Components and their composition
- Contracts
- Refinement and conjunction
- Contract composition
- Quotient
- Discussion
- Observers
- Bibliographical note
-
- Panorama of concrete theories
- Panorama AssumeGuarantee contracts
-
- Dataflow AG contracts
- Capturing exceptions
- Dealing with variable alphabets
- Synchronous AG contracts
- Observers
- Discussion
- Bibliographical note
-
- Panorama Interface theories
-
- Components as io-automata
- Interface Automata with fixed alphabet
- Modal Interfaces with fixed alphabet
- Modal Interfaces with variable alphabet
- Projecting and Restricting
- Observers
- Bibliographical note
-
- Panorama Timed Interface Theories
-
- Components as Event-Clock Automata
- Modal Event-Clock Specifications
- Bibliographical note
-
- Panorama Probabilistic Interface Theories
-
- Components as Probabilistic Automata
- Simple Modal Probabilistic Interfaces
- Bibliographical note
-
- The Parking Garage an example in Requirements Engineering
-
- The contract framework
- Top level requirements
- Formalizing requirements as contracts
- Sub-contracting to suppliers
- The four ``C
-
- Consistency amp Compatibility
- Correctness
- Completeness
-
- Discussion
-
- Contracts in the context of Autosar
-
- The Autosar context
- The contract framework
- Exterior Light Management System
-
- Function and timing
- Safety
-
- Integrating Contracts in Autosar
- Summary and discussion
-
- Conclusion
-
- What contracts can do for the designer
- Status of research
- Status of practice
- The way forward
-
- References
-
Contracts for System Design 4
CONTENTS
I Introduction 6I-A The Present System Design 6I-B The Future CPS and SoS 6I-C The Need for a Methodological Effort 6I-D Contract based design 7I-E Readerrsquos guide 7
II System Design Challenges 8II-A Complexity of Systems 8II-B Complexity of OEM-Supplier Chains 9II-C Managing Requirements 9II-D Managing Risks 10II-E System-wide Optimization 10
III How Challenges have been addressed so far 10III-A Complexity of Systems and System-
wide Optimization 10III-A1 Layered design 11III-A2 Component-based design 11III-A3 The V-model process 11III-A4 Model-Based Design 12III-A5 Virtual Integration 12III-A6 Platform Based Design 13
III-B Complexity of OEM-Supplier ChainsStandardization and Harmonization 13III-B1 Standardization of design
entities 13III-B2 Harmonization of processes
and certification 14III-C Managing Requirements Traceability
and Multiple Viewpoints 14III-D Cross-company Shared Risk Management 14III-E The Need for Contracts 15
IV Contracts what why where and how 16IV-A Contracts 16
IV-A1 Components and their Envi-ronment Contracts 16
IV-B Contract Operators 17IV-B1 Contract Composition and
System Integration 17IV-B2 Contract Refinement and In-
dependent Development 18IV-B3 Contract Conjunction and
Viewpoint Fusion 18IV-C Contracts in requirement engineering 19IV-D Contract Support for Design Method-
ologies 20IV-D1 Supporting open systems 20IV-D2 Managing Requirements and
Fusing Viewpoints 20IV-D3 Design Chain Management
Re-using and IndependentDevelopment 21
IV-D4 Deployment and Mapping 21IV-E Bibliographical note 23
V A Mathematical Meta-theory of Contracts 24V-A Components and their composition 24V-B Contracts 25V-C Refinement and conjunction 25V-D Contract composition 26V-E Quotient 27V-F Discussion 27V-G Observers 27V-H Bibliographical note 28
VI Panorama of concrete theories 29
VII Panorama AssumeGuarantee contracts 29VII-A Dataflow AG contracts 30VII-B Capturing exceptions 30VII-C Dealing with variable alphabets 31VII-D Synchronous AG contracts 32VII-E Observers 32VII-F Discussion 32VII-G Bibliographical note 32
VIII Panorama Interface theories 33VIII-A Components as io-automata 33VIII-B Interface Automata with fixed alphabet 34VIII-C Modal Interfaces with fixed alphabet 35VIII-D Modal Interfaces with variable alphabet 37VIII-E Projecting and Restricting 38VIII-F Observers 40VIII-G Bibliographical note 40
IX Panorama Timed Interface Theories 42IX-A Components as Event-Clock Automata 42IX-B Modal Event-Clock Specifications 43IX-C Bibliographical note 43
X Panorama Probabilistic Interface Theories 44X-A Components as Probabilistic Automata 44X-B Simple Modal Probabilistic Interfaces 45X-C Bibliographical note 45
XI The Parking Garage an example in Require-ments Engineering 45
XI-A The contract framework 45XI-B Top level requirements 46XI-C Formalizing requirements as contracts 46XI-D Sub-contracting to suppliers 48XI-E The four ldquoCrdquo 49
XI-E1 Consistency amp Compatibility 49XI-E2 Correctness 50XI-E3 Completeness 50
XI-F Discussion 50
RR ndeg 8147
Contracts for System Design 5
XII Contracts in the context of AUTOSAR 50XII-A The AUTOSAR context 50XII-B The contract framework 51XII-C Exterior Light Management System 51
XII-C1 Function and timing 51XII-C2 Safety 56
XII-D Integrating Contracts in AUTOSAR 58XII-E Summary and discussion 59
XIII Conclusion 59XIII-A What contracts can do for the designer 59XIII-B Status of research 59XIII-C Status of practice 59XIII-D The way forward 59
References 60
RR ndeg 8147
Contracts for System Design 6
I INTRODUCTION
A The Present System Design
System companies such as automotive avionics and con-sumer electronics companies are facing significant difficultiesdue to the exponentially raising complexity of their productscoupled with increasingly tight demands on functionalitycorrectness and time-to-market The cost of being late tomarket or of imperfections in the products is staggering aswitnessed by the recent recalls and delivery delays that systemindustries had to bear
In 2010 Toyota had to recall 10 Million cars worldwidefor reasons that ranged from the infamous sticky acceleratorpedals to steering and engine problems The last recall atthe end of August 2010 was for the engine control moduleToyota is not alone in this situation Most of the automotivemakers had one or more major recalls in the recent past(see eg httpwwwautorecallsus) involving electronics aswell as mechanical parts Boeing and Airbus Industries hadsignificant delays in the delivery of their latest planes (787and A380) For the A380 underlying causes were cited asissues in the cabling system configuration management anddesign process In particular the complexity of the cabinwiring (100000 wires and 40300 connectors) was considereda major issue (see httpenwikipediaorgwikiAirbus_A380)The delays caused the departure of both the EADS and AirbusCEOs and of the program manager for the A380 and caused anoverall earning shortfall of 48 Billion Euros Boeing originallyplanned the first flight of the 787 for August 2007 (seehttpenwikipediaorgwikiBoeing_787) but after a streamof delay announcements the actual first flight occurred onDecember 15 2009 The delays were caused by a number ofunfortunate events and design errors and caused at least a 23Billion USD write-off not counting the claim of Air India of1 Billion USD damages for delayed delivery and the revenueshortfalls
These are examples of the devastating effects that designproblems may cause The specific root causes of these prob-lems are complex and relate to a number of issues rangingfrom design processes and relationships with different depart-ments of the same company and with suppliers to incompleterequirement specification and testing
B The Future CPS and SoS
Many products and services require to take into considera-tion the interactions of computational and physical processesSystems where this interaction is tight and needs special careare called Cyber-Physical Systems (CPS) [133] The broadmajority of these new applications can be classified as ldquodis-tributed sense and control systemsrdquo that go substantially be-yond the ldquocomputerdquo or ldquocommunicaterdquo functions traditionallyassociated with information technology These applicationshave the potential to radically influence how we deal with abroad range of crucial problems facing our society today forexample national security and safety including surveillanceenergy management and distribution environment control
efficient and reliable transportation and mobility and effectiveand affordable health care A recurring property of theseapplications is that they engage all the platform componentssimultaneouslymdashfrom data and computing services on thecloud of large-scale servers data gathering from the sensoryswarm and data access on mobile devicesmdashwith significantheterogeneity These large scale systems composed of subsys-tems that are themselves systems are now called Systems ofSystems (SoS) and are heavily investigated
As the complexity of these systems increases our inabilityto rigorously model the interactions between the physical andthe cyber sides creates serious vulnerabilities Systems becomeunsafe with disastrous inexplicable failures that could not havebeen predicted The challenges in the realization and operationof these CPS and SoS are manifold and cover a broad range oflargely unsolved design and run-time problems These includemodeling and abstraction verification validation and testreliability and resiliency multi-scale technology integrationand mapping power and energy security diagnostics andrun-time management Failure to address these challengesin a cohesive and comprehensive way will most certainlydelay if not prohibit the widespread adoption of these newtechnologies
C The Need for a Methodological Effort
We believe the most promising means to address the chal-lenges in systems engineering is to employ structured andformal design methodologies that seamlessly and coherentlycombine the various dimensions of the design space (be itbehavior space or time) that provide the appropriate abstrac-tions to manage the inherent complexity and that can pro-vide correct-by-construction implementations The followingtechnology issues must be addressed when developing newapproaches to the design of complex systems CPS and SoSbull The overall design flows for heterogeneous systemsmdash
meant here both in a technical and also an organiza-tional sensemdashand the associated use of models acrosstraditional boundaries are not well developed and un-derstood Relationships between different teams inside asame company or between different stake-holders in thesupplier chain are not well supported by solid technicaldescriptions for the mutual obligations
bull System requirement capture and analysis is in largepart a heuristic process where the informal text andnatural language-based techniques in use today are facingsignificant challenges Formal requirement engineeringis in its infancy mathematical models formal analysistechniques and links to system implementation must bedeveloped
bull Dealing with variability uncertainty and life-cycle issuessuch as extensibility of a product family are not well-addressed using available systems engineering methodol-ogy and tools
bull Design-space exploration is rarely performed adequatelyyielding suboptimal designs where the architecture se-lection phase does not consider extensibility re-usability
RR ndeg 8147
Contracts for System Design 7
and fault tolerance to the extent that is needed to reducecost failure rates and time-to-market
bull The verification and validation of ldquocomplex systemsrdquoparticularly at the system integration phase where anyinteractions are complicated and extremely costly toaddress is a common need in defense automotive andother industries
The challenge is to address the entire process and not toconsider only point solutions of methodology tools andmodels that ease part of the design
D Contract based design
It is our goal to offer a new approach to the system designproblem that is rigorous and effective in dealing with theproblems and challenges described before and that at thesame time does not require a radical change in the wayindustrial designers carry out their task as it cuts across designflows of different type contract-based design
Contracts in the layman use of the term are establishedwhen an OEM must agree with its suppliers on the subsystemor component to be delivered Contracts involve a legal partbinding the different parties and a technical annex that servesas a reference regarding the entity to be delivered by thesuppliermdashin this work we focus on the technical facet ofcontracts Contracts can also be used through their technicalannex in concurrent engineering when different teams developdifferent subsystems or different aspects of a system within asame company
In this paper we argue that contracts can be actually usedalmost everywhere and at nearly all stages of system designfrom early requirements capture to embedded computinginfrastructure and detailed design involving circuits and otherhardware Contracts explicitly handle pairs of properties re-spectively representing the assumptions on the environmentand the guarantees of the system under these assumptionsIntuitively a contract is a pair
C = (AG) of Assumptions Guarantees
characterizing in a formal way 1) under which context thedesign is assumed to operate and 2) what its obligations areAssumeGuarantee reasoning has been known for quite sometime but it has been used mostly as verification mean for thedesign of software Our purpose is more ambitious contractbased design with explicit assumptions is a philosophy thatshould be followed all along the design with all kinds ofmodels whenever necessary Here the models we mean arerichmdashnot only profiles types or taxonomy of data but alsomodels describing the functions performances of variouskinds (time and energy) and safety The consideration of richcontracts as above in the industry is still in its infancy Tomake contract-based design a technique of choice for systemengineers we must developbull Mathematical foundations for contract representation and
requirement engineering that enable the design of frame-works and tools
bull A system engineering framework and associated method-ologies and tool sets that focus on system requirementmodeling contract specification and verification at mul-tiple abstraction layers The framework should addresscross-boundary and cross-organizational design activities
This paper intends to provide a unified treatment of contractswhere they are precisely defined and characterized so that theycan be used in design with no ambiguity In addition the paperprovides an important link between interfaces and contractsto show similarities and correspondences Examples of the useof contracts in design will be provided as well as in depthanalysis of existing literature
E Readerrsquos guide
The organization of the paper is explained in Table IIn Section II a review of the challenges that are faced by the
system industry is proposed followed in Section III by ananalysis of the design methodologies that have been deployedto cope with them
Section IV develops a primer on contracts by using a verysimple example requiring only elementary mathematical back-ground to be followed Its purpose is to smoothly introducethe different concepts and operations we need for a contractframeworkmdashthe restricted case considered is by no meansrepresentative of the kind of system we can address usingcontracts We then introduce a motivating example repre-sentative of requirement engineering In a third sub-sectionldquorequirementsrdquo on a theory of contracts are identified fromanalyzing what is expected from contract-based design andin particular the support for 1) the development of differentaspects or viewpoints of a system such as its function safetytiming and resource use by different teams and how to fusethese different aspects and 2) the possibility for differentsuppliers to develop independently the different subsystemssubcontracted to them This section concludes with the relatedbibliography
Section V is the cornerstone of this paper and it is a newvista on contracts The so-called ldquometa-theoryrdquo of contractsis introduced and developed in detail By meta-theory wemean the collection of concepts operations and propertiesthat any formal contract framework should offer Conceptsoperations and properties are thus stated in a fairly genericway Every concrete framework compliant with this meta-theory will inherit these generic properties The meta-theoryfocuses on assumptions and guarantees its formalizes howdifferent aspects or viewpoints of a specification can beintegrated and on which basis independent development bydifferent suppliers can be safely performed
So far the meta-theory is non effective in that it is notsaid how component and contracts are effectively representedand manipulated The subsequent series of sections propose apanorama of major concrete contract frameworks Section VIIdevelops the AssumeGuarantee contracts This framework isthe most straightforward instance of the meta-theory It dealswith pairs (AG) of assumptions and guarantees explicitlyA and G being both expressed as properties This framework
RR ndeg 8147
Contracts for System Design 8
Section methodological tutorial fundamental technical applicationSection IIchallengesSection IIIaddressing the challengesSection IVwhy contracts where and how
Section Vcontract meta-theory
Section VIIAssumeGuarantee contractsSection VIIIInterface theoriesSection IXtimedSection Xprobabilistic
Section XIrequirements engineeringSection XIIAUTOSAR
Section IIdarr
Section III Section IV
Section V Section VII mdash Section VIIIdarr darr
Section XII Section XI
Section IX mdash Section Xdarr darr
Section Section
Section IIdarr
Section III Section IV
Section V Section XI Section XII
Table IREADERrsquoS GUIDE CATEGORIZATION OF THE DIFFERENT SECTIONS (TOP) AND
DEPENDENCIES (BOTTOM LEFT IN-DEPTH READING BOTTOM-RIGHT QUICK READING)
is flexible in that it allows for different styles of descriptionof such propertiesmdashcomputational efficiency depends on thestyle adopted Section VIII develops the Interface theoriesin which assumptions and guarantees are specified by meansof a single object the interface Interface theories turn outto include the most effective frameworks They can easily beadapted to encompass timing (Section IX) and probabilistic(Section X) characteristics of systems
In Section XI a toy example in requirements engineeringis developed This example is simple but rich enough to illus-trate the very difficulties in formalizing requirements It alsoillustrates well the added value of contract based requirementsengineering First the different responsibilities (assumptionsversus obligation or guarantees) that requirement implicit referto are made explicit and captured in our contract frameworkSecond contracts offer a formal meaning for documents ofrequirements structured into chapters or viewpoints Contractsoffer formal support for checking important properties suchas consistency compatibility completeness and more Finallycontracts offer significant assistance in the process of deduc-ing from the top specification an architecture of specificationsfor the different sub-systems for independent developmentWhile our application example is a toy one is it neverthelesstoo complex for dealing with it by hand We handle it by usinga proof-of-concept tool for contract management
Finally Section XII develops a case study in the contextof AUTOSAR AUTOSAR is a recently established standardin the automobile sector This standard was developed withthe objective of allowing for better flexibility in componentreuse and OEMsupplier relations This section illustrates howcontracts can be used to break into simple pieces of reasoningthe difficult task of correct system integration
II SYSTEM DESIGN CHALLENGES
Many challenges face the system community to deliverproducts that are reliable and effective We summarize someof them below
A Complexity of Systems
The ever-expanding use of electronic embedded systems tocontrol increasingly many aspects of the real world and thetrend to interconnect more and more such systems (often fromdifferent manufacturers) into a global network are creating achallenging scenario for system designers In this scenario thethree challenges that are taking center stage are as follows
The Hardware Platform Complexity Most system com-panies rely on Components off-the-shelf (COTS) and pro-grammability to implement their applications For companieswho build ldquophysically largerdquo systems such as avionics and au-tomotive companies the complexity of the hardware platform
RR ndeg 8147
Contracts for System Design 9
Design task Tasks Tasks Tasks Tasks Tasks Tasksdelayed delayed delayed causing delay causing delay causing delayautomotive automation medical automotive automation medical
System integration 630 565 667 423 190 375test and verificationSystem architecture 296 261 333 385 429 313design and specificationSoftware application 444 304 750 269 310 250andor middlewaredevelopment and testProject management 370 283 167 538 381 375and planning
Table IIDIFFICULTIES RELATED TO SYSTEM INTEGRATION
is reflected in the number of Electronic Control Units and intheir interconnections For a top-of-the-line automobile thenumber of processors to manage and interconnect is above50 The layout of the cables that connect these processingelements with sensors and actuators is a serious concern Initialproduction of the Airbus A380 was troubled by delays in partattributed to the 530 km (330 mi) of wiring in each aircraft
The Embedded Software Complexity Given the cost andrisks associated to developing hardware solutions system com-panies are selecting hardware platforms that can be customizedby reconfiguration andor by software programmability Inparticular software is taking the lionrsquos share of the implemen-tation budgets and cost In cell phones more than 1 millionlines of code is standard today while in automobiles theestimated number of lines by 2010 is in the order of hundredsof millions and in the Boeing 787 is in the order of 20 millionlines However as this happens the complexity explosion ofthe software component causes serious concerns for the finalquality of the products and the productivity of the engineeringteams
The Integration Complexity A standard technique to dealwith complexity consists in decomposing top-down the systeminto subsystems This approach which has been customar-ily adopted by the semiconductor industry for years has alimitation as a designer or a group of designers has to fullycomprehend the entire system and to partition appropriately itsvarious parts a difficult task given the enormous complexityof todayrsquos systems
Hence the future is one of developing systems by compos-ing pieces that all or in part have already been predesignedor designed independently by other design groups or evencompanies This has been done routinely in vertical designchains for example in the avionics and automotive sectorsalbeit in a heuristic and ad hoc way The resulting lack of anoverall understanding of the interplay of the subsystems and ofthe difficulties encountered in integrating very complex partscause system integration to become a nightmare in the systemindustry as demonstrated by Table II1
In addition heterogeneity comes into play Integration of
1VDC research Track 3 Embedded Systems Market Statistics Exhibit II-13from volumes on automotiveindustrial automationmedical 2008
electronic and mechanical design tools and frameworks will beessential in the near future Integration of chemical electronicand biology tools will be essential in the further future fornano-systems Data integration and information flow amongthe companies forming the chain have to be supported Inother words it is essential that the fundamental steps of systemdesign (functional partitioning allocation on computationalresources integration and verification) be supported acrossthe entire design development cycle and across different dis-ciplines
B Complexity of OEM-Supplier Chains
The source of the above problems is clearly the increase incomplexity It is however also the difficulty of the OEMs inmanaging the integration and maintenance process with sub-systems that come from different suppliers who use differentdesign methods different software architectures and differenthardware platforms
There are also multiple challenges in defining technicalannexes to commercial contracts between OEM and suppli-ers Specifications used for procurement should be preciseunambiguous and complete However a recurrent reason forfailures causing deep iterations across supply chain boundariesrests in incomplete characterizations of the environment ofthe system to be developed by the supplier such as missinginformation about failure modes and failure rates missing in-formation on possible sources for interferences through sharedresources and missing boundary conditions This highlightsthe need to explicate assumptions on the design context inOEM-supplier commercial contracts In light of an increasedsharing of hardware resources by applications developed bymultiple suppliers a contract-based approach seems indispens-able for resolving liability issues and allowing applicationswith different criticality levels to co-exist (such as ASILlevels[175] [13] in automotive)
C Managing Requirements
We argued that the design chains should connect seamlesslyto minimize design errors and time-to-market delays Yet theboundaries among companies and between different divisionsof the same company are often not as clean as needed anddesign specs move from one company (or one division) to the
RR ndeg 8147
Contracts for System Design 10
next in non-executable and often unstable and imprecise formsthus yielding misinterpretations and consequent design errorsIn addition errors are often caught only at the final integrationstep as the specifications were incomplete and imprecisefurther nonfunctional specifications (eg timing power con-sumption size) are difficult to trace Further it is commonpractice to structure system level requirements into severalldquochaptersrdquo ldquoaspectsrdquo or ldquoviewpointsrdquo Examples include thefunctions safety timing and energy viewpoints Quite oftenthese different viewpoints are developed by different teamsusing different skills frameworks and tools Yet they are notunrelated as we already mentioned Without a clean approachto handle multiple viewpoints the only sensible way is tocollect these viewpoints into a single requirements documentwhich is then seen as a flat collection of requirements forsubsequent design Since this is clearly impracticable thecommon practice instead is to discard some of the viewpointsin a first stage eg by considering only functions and safetyDesigns are then developed based on these only viewpointsOther viewpoints are subsequently taken into account (timingenergy) thus resulting in late and costly modifications andre-designs
Requirement engineering is a discipline that aims at improv-ing this situation by paying close attention to the managementof the requirement descriptions and traceability support (egusing commercial tools such as DOORS2 in combinationwith Reqtify3) and by inserting whenever possible preciseformulation and analysis methods and tools Research in thisarea is active but we believe more needs to be done to makethis essential step a first class citizen in system design Indeedif the specification quality is low then the entire design processis marred since the very beginning The overall system productspecification is somewhat of an art today since to verify itscompleteness and its correctness there is little that it can beused to compare with
D Managing Risks
System design processes are highly concurrent distributedand typically multi-domain often involving more than onehundred sub-processes The complexity of the entire designprocess and of the relationships between players in the supplychain creates the need to elaborate risk sharing and riskmanagement plans because of the potential enormity of theimpact that design errors and supplier solidity may have onthe economics of a company Risk management has thusbecome a requirement of most of public companies as fi-nancial social and political risks are analyzed and appropriatecountermeasures have to be prepared as a requirement fromthe regulatory bodies Risk mitigation measures typically coverall phases of design processes ranging from assuring highquality initial requirements to early assessments of risks inmeeting product requirements during the concept phase toenforcing complete traceability of such requirements with
2 httpwww-01ibmcomsoftwareawdtoolsdoorsproductline3httpetc
requirements management tools to managing consistency andsynchronization across concurrent sub-processes using PLMtools4 If we will be able to change the design processalong the lines of more formal approaches better complexityhandling better requirement engineering then risks will besubstantially lower than they are today
E System-wide Optimization
We believe that since the design process is fragmentedproduct optimization is rarely carried out across more thanone company boundary and even then it is limited due tobull The lack of appropriate models encompassing both func-
tional and non-functional (Quality of Service) aspectscovering both internal use and export outside the com-pany
bull The time pressure to meet the product deadlinesbull The functional description that is over-constrained by
architectural considerations which de facto eliminate po-tentially interesting implementation alternatives
If the design process were carried out as in a unique well-integrated virtual company including all the players shownabove the overall ecosystem would greatly benefit The issuehere is to allow a reasonably efficient design space explorationby providing a framework where different architectures couldbe quickly assembled and evaluated at each layer of abstractioncorresponding to the design task being considered in the chain
III HOW CHALLENGES HAVE BEEN ADDRESSED SO FAR
In this section we present a review and a critical analysisof the design methodologies that have been deployed to copewith the challenges exposed in the previous section
A Complexity of Systems and System-wide Optimization
Multiple lines of attack have been developed by researchinstitutions and industry to cope with the exponential growth insystems complexity starting from the iterative and incrementaldevelopment several decades ago [123] Among them ofparticular interest to the development of embedded controllersare Layered design Component-based design the V-modelprocess model-based development virtual integration andPlatform-Based Design (PBD) There are two basic princi-ples followed by these methods abstractionrefinement andcompositiondecomposition Abstraction and refinement areprocesses that relate to the flow of design between differentlayers of abstraction (vertical process) while compositionand decomposition operate at the same level of abstraction(horizontal process) Layered design the V-model processand model-based development focus on the vertical processwhile component-based design deals principally with the hor-izontal process PBD combines the two aspects in a unifiedframework and hence subsumes and can be used to integrated
4 PLM Product Lifecycle Management PLM centric design is used incombination with virtual modeling and digital mockups PLM acts as a database of virtual system components PLM centric design is for exampledeployed at Dassault-Aviation httpwwwdassault-aviationcomenaviationinnovationthe-digital-companydigital-designplm-toolshtmlL=1
RR ndeg 8147
Contracts for System Design 11
the other methodologies Contracts are ideal tools to solidifyboth vertical and horizontal processes providing the theoreticalbackground to support formal methods
1) Layered design Layered design copes with complexityby focusing on those aspects of the system pertinent to supportthe design activities at the corresponding level of abstractionThis approach is particularly powerful if the details of alower layer of abstraction are encapsulated when the designis carried out at the higher layer Layered approaches are wellunderstood and standard in many application domains Asan example consider the AUTOSAR standard5 This standarddefines several abstraction layers Moving from ldquobottomrdquoto ldquotoprdquo the micro-controller abstraction layer encapsulatescompletely the specifics of underlying micro-controllers thesecond layer abstracts from the concrete configuration of theElectronic Control Unit (ECU) the employed communicationservices and the underlying operating system whereas the(highest) application layer is not aware of any aspect ofpossible target architectures and relies on purely virtual com-munication concepts in specifying communication betweenapplication components Similar abstraction levels are definedby the ARINC standard in the avionic domains
The benefits of using layered design are manifold Using theAUTOSAR layer structure as example the complete separationof the logical architecture of an application (as represented bya set of components interconnected using the so-called virtualfunction bus) and target hardware is a key aspect of AUTOSARin that it supports decoupling of the number of automotivefunctions from the number of hardware components In par-ticular it is flexible enough to mix components from differentapplications on one and the same ECU This illustrates thedouble role of abstraction layers in allowing designers to focuscompletely on the logic of the application and abstracting fromthe underlying hardware while at the same time imposing aminimal (or even no) constraint on the design space of possiblehardware architectures In particular these abstractions allowthe application design to be re-used across multiple platformsvarying in number of bus-systems andor number and class ofECUs These design layers can in addition be used to matchthe boundaries of either organizational units within a companyor to define interfaces between different organizations in thesupply chain The challenge then rests in providing the properabstractions of lower-level design entities
2) Component-based design Whereas layered designs de-compose complexity of systems ldquoverticallyrdquo component-basedapproaches reduce complexity ldquohorizontallyrdquo whereby designsare obtained by assembling strongly encapsulated design enti-ties called ldquocomponentsrdquo equipped with concise and rigorousinterface specifications Re-use can be maximized by findingthe weakest assumptions on the environment sufficient to es-tablish the guarantees on a given component implementationWhile these interface specifications are key and relevant forany system the ldquoquality attributerdquo of perceiving a subsystemas a component is typically related to two orthogonal criteria
5See httpwwwautosarorg
that of ldquosmall interfacesrdquo and that of minimally constrainingthe deployment context so as to maximize the potential for re-use ldquoSmall interfacesrdquo ie interfaces which are both smallin terms of number of interface variables or ports as wellas ldquologically smallrdquo in that protocols governing the invoca-tion of component services have compact specifications notrequiring deep levels of synchronization constitute evidenceof the success of encapsulationmdashstill small interfaces mustencompass dynamic properties of the system The secondquality attribute is naturally expressible in terms of interfacespecifications where re-use can be maximized by finding theweakest assumptions on the environment sufficient to establishthe guarantees on a given component implementation
One challenge then for component-based design of em-bedded systems is to provide interface specifications that arerich enough to cover all phases of the design cycle Thiscalls for including non-functional characteristics as part ofthe component interface specifications which is best achievedby using multiple viewpoints Current component interfacemodels in contrast are typically restricted to purely functionalcharacterization of components and thus cannot capitalize onthe benefits of virtual integration testing as outlined above
The second challenge is related to product line designwhich allows for the joint design of a family of variants of aproduct The aim is to balance the contradicting goals of striv-ing for generality versus achieving efficient component im-plementations Methods for systematically deriving ldquoquotientrdquospecifications to compensate for ldquominorrdquo differences betweenrequired and offered component guarantees by composing acomponent with a wrapper component (compensating for suchdifferences as characterized by quotient specifications) existsfor restricted classes of component models [155]
3) The V-model process A widely accepted approach todeal with complexity of systems in the defense and trans-portation domain is to structure product development processesalong variations of the V diagram originally developed fordefense applications by the German DoD6
Its characteristic V-shape splits the product developmentprocess into a design and an integration phase Specificallyfollowing product level requirement analysis subsequent stepswould first evolve a functional architecture supporting productlevel requirements Sub-functions are then re-grouped takinginto account re-use and product line requirements into alogical architecture whose modules are typically developed bydifferent subsystem suppliers The realization of such modulesoften involves mechanical hydraulic electrical and electronicsystem design Subsequent phases would then unfold thedetailed design for each of these domains such as the designof the electronic subsystem involving among others the designof electronic control units These design phases are paralleledby integration phases along the right-hand part of the Vsuch as integrating basic- and application software on theECU hardware to actually construct the electronic control unitintegrating the complete electronic subsystems integrating the
6See eg httpwwwv-model-xtde
RR ndeg 8147
Contracts for System Design 12
mechatronic subsystem to build the module and integratingmultiple modules to build the complete product Not shownbut forming an integral part of V-based development processesare testing activities where at each integration level test-suites developed during the design phases are used to verifycompliance of the integrated entity to their specification
This presentation is overly simplistic in many ways Thedesign of electronic components in complex systems suchas aircrafts inherently involves multi-site multi-domain andcross-organizational design teams reflecting eg a partition-ing of the aircraft into different subsystems (such as primaryand secondary flight systems cabin fuel and wing) differentdomains such as the interface of the electronic subsystem tohydraulic andor mechanical subsystems control-law designtelecommunications software design hardware design diag-nostics and development-depth separated design activities car-ried out at the OEM and supplier companies This partitioningof the design space (along perspectives and abstraction layers)naturally lends itself to a parallelization of design activitiesa must in order to achieve timely delivery of the overallproduct leading often into the order of hundreds of concurrentdesign processes To summarize while being popular andwidely referenced the V-model process has become a ldquosloganrdquohiding the complexity of actual design processes In realitylarge system companies develop their own processes and thenstruggle for their application both in-house and across thesupplier chain
4) Model-Based Design Model-based design (MBD) is to-day generally accepted as a key enabler to cope with complexsystem design due to its capabilities to support early require-ment validation and virtual system integration MBD-inspireddesign languages and tools such as SysML7 [149] andorAADL [152] for system level modeling Catia and Model-ica [93] for physical system modeling Matlab-Simulink [118]for control-law design and UML8 [44] [147] Scade [32]and TargetLink for detailed software design depend on de-sign layer and application class The state-of-the-art in MBDincludes automatic code-generation simulation coupled withrequirement monitoring co-simulation of heterogeneous mod-els such as UML and Matlab-Simulink model-based analy-sis including verification of compliance of requirements andspecification models model-based test-generation rapid pro-totyping and virtual integration testing as further elaboratedbelow
In MBD today non-functional aspects such as performancetiming power or safety analysis are typically addressed indedicated specialized tools using tool-specific models withthe entailed risk of incoherency between the correspond-ing models which generally interact To counteract theserisks meta-models encompassing multiple views of designentities enabling co-modeling and co-analysis of typicallyheterogeneous viewpoint specific models have been developedExamples include the MARTE UML [148] profile for real-time
7httpwwwomgorgspecSysML8httpwwwomgorgspecUML
system analysis the SPEEDS HRC metamodel [156] and theMetropolis semantic meta-model [19] [67] [16] [170] InMetropolis multiple views are accommodated via the conceptof ldquoquantitiesrdquo that annotate the functional view of a designand can be composed along with subsystems using a suitablealgebra The SPEEDS meta-model building on and extendingSysML has been demonstrated to support co-simulation andco-analysis of system models for transportation applicationsallowing co-assessment of functional real-time and safety re-quirements It forms an integral part of the meta-model-basedinter-operability concepts of the CESAR reference technologyplatform9
Meta-modeling is also at the center of the model driven(software) development (MDD) methodology MDD is basedon the concept of the model-driven architecture (MDA) whichconsists of a Platform-Independent Model (PIM) of the ap-plication plus one or more Platform-Specific Models (PSMs)and sets of interface definitions MDA tools then supportthe mapping of the PIM to the PSMs as new technologiesbecome available or implementation decisions change [146]The Vanderbilt University group [119] has evolved an em-bedded software design methodology and a set of tools basedon MDD In their approach models explicitly represent theembedded software and the environment it operates in andcapture the requirements and the design of the applicationsimultaneously using domain-specific languages (DSL) Thegeneric modeling environment (GME) [119] provides a frame-work for model transformations enabling easy exchange ofmodels between tools and offers sophisticated ways to sup-port syntactic (but not semantic) heterogeneity The KerMetametamodeling workbench [91] is similar in scope
5) Virtual Integration Rather than ldquophysicallyrdquo integratinga system from subsystems at integration stages model-baseddesign allows systems to be virtually integrated based on themodels of their subsystem and the architecture specificationof the system Such virtual integration thus allows detectingpotential integration problems up front in the early designphases Virtual system integration is often a source of het-erogeneous system models such as when realizing an aircraftfunction through the combination of mechanical hydraulicand electronic systems Heterogeneous composition of modelswith different semantics was originally addressed in Ptolemy[88] Metropolis [20] [67] [16] [48] and in the SPEEDSmeta-model of heterogeneous rich components [65] [29] [31]albeit with different approaches Virtual integration involvesmodels of the functions the computer architecture with itsextra-functional characteristics (timing and other resources)and the physical system for control Some existing frameworksoffer significant support for virtual integration Ptolemy IIMetropolis and RT-Builder Developments around Catia andModelica as well as the new offer SimScape by Simulinkprovide support for virtual integration of the physical part atan advanced level
9wwwcesarprojecteu
RR ndeg 8147
Contracts for System Design 13
6) Platform Based Design Platform-based design was in-troduced in the late 1980s to capture a design process thatcould encompass horizontal (component-based design virtualintegration) and vertical (layered and model-based design)decompositions and multiple viewpoints and in doing sosupport the supply chain as well as multi-layer optimization
The idea was to introduce a general approach that couldbe shared across industrial domain boundaries that wouldsubsume the various definition and design concepts and thatwould extend it to provide a framework to reason aboutdesign Indeed the concepts have been applied to a variety ofvery different domains from automotive to System-on-Chipfrom analog circuit design to building automation to syntheticbiology
The basic tenets of platform-based design are as followsThe design progresses in precisely defined abstraction layersat each abstraction layer functionality (what the system issupposed to do) is strictly separated from architecture (howthe functionality could be implemented) This aspect is clearlyrelated to layered design and hence it subsumes it
Each abstraction layer is defined by a design platform Adesign platform consists ofbull A set of library components This library not only con-
tains computational blocks that carry out the appropriatecomputation but also communication components that areused to interconnect the computational components
bull Models of the components that represent a characteri-zation in terms of performance and other non-functionalparameters together with the functionality it can supportNot all elements in the library are pre-existing com-ponents Some may be ldquoplace holdersrdquo to indicate theflexibility of ldquocustomizingrdquo a part of the design that isoffered to the designer In this case the models representestimates of what can be done since the components arenot available and will have to be designed At times thecharacterization is indeed a constraint for the implementa-tion of the component and it is obtained top-down duringthe refinement process typical of layered designs Thislayering of abstractions based on mathematical models istypical of model-based methods and the introduction ofnon-functional aspects of the design relates to viewpoints
bull The rules that determine how the components can beassembled and how the the functional and non-functionalcharacteristics can be computed given the ones of thecomponents to form an architectureThen a platformrepresents a family of designs that satisfies a set ofplatform-specific constraints [15] This aspect is relatedto component-based design enriched with multiple view-points
This concept of platform encapsulates the notion of re-use asa family of solutions that share a set of common features (theelements of the platform) Since we associate the notion ofplatform to a set of potential solutions to a design problem weneed to capture the process of mapping a functionality (whatthe system is supposed to do) with the platform elements thatwill be used to build a platform instance or an ldquoarchitecturerdquo
(how the system does what it is supposed to do) The strictseparation between function and architecture as well as themapping process have been highly leveraged in AUTOSARThis process is the essential step for refinement and provides amechanism to proceed towards implementation in a structuredway Designs on each platform are represented by platform-specific design models A design is obtained by a designerrsquoscreating platform instances (architectures) via composing plat-form components (process that is typical of component-baseddesign) by mapping the functionality onto the components ofthe architecture and by propagating the mapped design in thedesign flow onto subsequent abstraction layers that are dealtwith in the same way thus presenting the design process asan iterative refinement This last point dictates how to moveacross abstraction layers it is an important part of design spaceexploration and offers a way of performing optimization acrosslayers In this respect PBD supports multiple viewpoints in ageneral way
B Complexity of OEM-Supplier Chains Standardization andHarmonization
So far the main answer to the complexity of OEM-supplierchains has been standardization Standardization concerns boththe design entities and the design processes particularlythrough the mechanism of certification
1) Standardization of design entities By agreeing on (do-main specific) standard representations of design entitiesdifferent industrial domains have created their own linguafranca thus enabling a domain wide shared use of designentities based on their standardized representation Exam-ples of these standards in the automotive sector include therecently approved requirement interchange format standardRIF10 the AUTOSAR11 de-facto standard the OSEK12 operat-ing system standard standardized bus-systems such as CAN13
and Flexray14 standards for ldquocar2Xrdquo communication andstandardized representations of test supported by ASAM15Examples in the aerospace domain include ARINC stan-dards16 such as the avionics applications standard interfaceIMA RTCA17 communication standards In the automationdomain standards for interconnection of automation devicessuch as Profibus18 are complemented by standardized designlanguages for application development such as Structured Text
As standardization moves from hardware to operating sys-tem to applications and thus crosses multiple design layersthe challenge increases to incorporate all facets of designentities required to optimize the overall product while atthe same time enabling distributed development in complex
10httpwwww3org2005ruleswikiRIF_Working_Group11httpwwwautosarorg12httpwwwosek-vdxorg13httpwwwisoorgisosearchhtmqt=Controller+Area+
NetworkampsearchSubmit=Searchampsort=relamptype=simpleamppublished=true14httpwwwflexraycom15httpwwwasamnet16httpwwwaeec-amc-fsemccomstandardsindexhtml17httpwwwrtcaorg18httpwwwprofibuscom
RR ndeg 8147
Contracts for System Design 14
supply chains As an example to address the different view-points required to optimize the overall product AUTOSARextended in transitioning from release 31 to 4 its capabilityto capture timing characteristics of design entities a keyprerequisite for assessing alternate deployments with respectto their impact on timing More generally the need for overallsystem optimization calls for the standardization of all non-functional viewpoints of design entities an objective yet tobe achieved in its full generality in order to allow crosslayer optimization Within the EDA domain such richnessof design interface specifications is industrial practice Withinthe systems domain the rich component model introduced inthe Integrated Projects SPEEDS tackles this key objective incovering multiple design layers (from product requirements todeployment on target architectures) and in providing means ofassociating multiple viewpoints with each design entity it isexpressive enough to allow for cross-supply chain optimizationof product developments This approach is further elaboratedand driven towards standardization in the Artemis flagshipproject CESAR
2) Harmonization of processes and certification Harmo-nizing or even standardizing key processes (such as devel-opment processes and safety processes) provides for a fur-ther level of optimization in interactions across the supplychain As an example Airbus Directives and Procedures(ADBs) provide requirements for design processes of equip-ment manufactures Often harmonized processes across thesupply chain build on agreed maturity gates with incrementalacceptance testing to monitor progress of supplier developmenttowards final acceptance often building on incremental proto-types Shared use of Product Lifcycle Management (PLM)19
databases across the supply chain offers further potentialsfor cross-supply chain optimization of development processesAlso in domains developing safety related systems domainspecific standards clearly define the responsibilities and dutiesof companies across the supply chain to demonstrate func-tional safety such as in the ISO 2626220 for the automotivedomain IEC 6150821 for automation its derivatives CenelecEN 50128 and 5012622 for rail and Do 178 B23 for civilavionics
Yet the challenge in defining standards rests in balancingthe need for stability with the need of not blocking processinnovations As an example means for compositional con-struction of safety cases are seen as mandatory to reducecertification costs in the aerospace and rail domains Similarlythe potential of using formal verification techniques to copewith increasing system complexity is considered in the movefrom DO 178 B to DO 178 C standards
19See [162] and also footnote 420httpwwwisoorgisocatalogue_detailhtmcsnumber=4346421httpwwwiecchfunctionalsafety22httpwwwceneleceuCenelecCENELEC+in+actionWeb+Store
Standardsdefaulthtm23httpwwwdo178sitecom
C Managing Requirements Traceability and Multiple View-points
Depending on application domains up to 50 of all er-rors result from imprecise incomplete or inconsistent andthus unfeasible requirements Requirements are inherently illstructured They must address all aspects of the system andthus cannot be constrained by the lingua franca of a partic-ular domain They are fragmented in the form of large andsometimes huge DOORS files24 structured into viewpointsTwo issues have thus been identified by systems industries asessential for requirement management powerful and flexibletraceability tools to relate requirements between them and tolink them to tests for validation purposes and the developmentof domain specific ontologies as part of the PLM suiteFurther based on an assessment by the system companiesprocesses in the CESAR project25 and the German EmbeddedSystems Innovation alliance26 and building on the finding ofthe Integrated Project SPEEDS27 multiple viewpoints havebeen categorized into perspectives and aspects to provide asolid requirement and property modeling scaffold Perspectivesare viewpoints relevant to architecture modeling as carriedout by different stake-holders during the development processAspects are viewpoints that are orthogonal to the systemstructure Aspects are used to demonstrate compliance of thearchitecture to end-user concerns Example of aspects aresafety cost maintainability performance and weight Themeta-model underlying the CESAR RTP is able to maintainlinks such as the satisfy derive verify refine and allocaterelationships between design artifacts of different perspectivesand across abstraction layers
In addition to cope with the inherently unstructured prob-lem of (in)completeness of requirements industry has setup domain- and application-class specific methodologies Asparticular examples we mention learning process such asemployed by Airbus to incorporate the knowledge base ofexternal hazards from flight incidents the Code of Practiceproposed by the Prevent Project28 using guiding questions toassess the completeness of requirements in the concept phaseof the development of advanced driver assistance systemsUse-case analysis methods as advocated for UML baseddevelopment process follow the same objective All togetherrequirement engineering misses the support of formal ap-proaches for its structuring and analysis
D Cross-company Shared Risk Management
The realization of complex systems calls for design pro-cesses that mitigate risks in highly concurrent distributedand typically multi-domain engineering processes often in-volving more than one hundred sub-processes Risk mitigation
24Typical sub-systems in aeronautics would have a few thousands top-levelrequirements An aircraft can have up to several hundred thousands of them
25wwwcesarprojecteu26httpspes2020informatiktu-muenchende27httpwwwspeedseucom28Albert http
RR ndeg 8147
Contracts for System Design 15
measures typically cover all phases of design processes rang-ing from ensuring high quality initial requirements to earlyassessments of risks in realizability of product requirementsduring the concept phase to enforcing complete traceabilityof such requirements with requirements management tools tomanaging consistency and synchronization across concurrentsub-processes using PLM tools A key challenge rests inbalancing risk reduction versus development time and effortcompletely eliminating the risks stemming from concurrentengineering essentially requires a complete synchronizationalong a fine-grained milestone structure which would kill anydevelopment project due to the induced delays Another keychallenge is the ldquonot my faultrdquo syndrome in the OEM-supplierchain when errors call for costly re-design and the issue ofpenalties arises Properly assigning responsibilities to risks isstill out of reach today
E The Need for Contracts
The way system design challenges have been addressed sofar leaves huge opportunities for improvements by relying oncontract-based design In this section we briefly summarizefor each existing approach to address the design challengeshow contracts could improve the current situation
Contribution 1 Addressing Complexity of Systems andSystem-wide OptimizationWhile layered design (Section III-A1) and component baseddesign (Section III-A2) have been critical steps in breakingsystems complexity they do not by themselves provide theultimate answer When design is being performed at a consid-ered layer implicit assumptions regarding other layers (egcomputing resources) are typically invoked by the designerwithout having these explicated Hence actual properties ofthese other layers cannot be confronted against these hiddenassumptions Similarly when components or sub-systems areabstracted via their interfaces in component based design itis generally not true that such interfaces provide sufficientinformation for other components to be safely implementedbased on this sole interface Contract-based design providesthe due discipline concepts and techniques to cope with thesedifficulties
Model-based development (Section III-A4) has reached sig-nificant maturity by covering nearly all aspects of the system(physics functions computing resources) albeit not yet in afully integrated way To offer a real added value any newlyproposed technology should be rich enough for encompassingall these aspects as well Contract-based design offers in largepart this desirable feature
Virtual integration and virtual modeling (Section III-A5) isa step beyond basic model-based development by offering anintegrated view of all the above different aspects eg physics+ functions + performances Contract-based design supportsthe fusion of different systems aspects
Contract-based design is compliant with the V-model pro-cess (Section III-A3) just because it does not impose anyparticular design process Using contracts only imposes a
small set of rules that any process should accommodate seeSection IV-D for a discussion of this
Finally Platform-Based Design (PBD Section III-A6)which is being deployed in some large systems industries suchas United Technologies Corporation (UTC) is a systematicand comprehensive methodology that unifies the various de-sign methodologies that have been described in this sectionContracts offer theory and methodological support for boththe successive refinement aspect the composition aspect andthe mapping process of PBD allowing formal analysis andsynthesis processes
Contribution 2 Addressing the Complexity of OEM-Supplier ChainsThe problems raised by the complexity of OEM-SupplierChains (Section II-B) are indeed the core target of contract-based design By making the explication of implicit assump-tions mandatory contracts help assigning responsibilities toa precise stake holder for each design entity By supportingindependent development of the different sub-systems whileguaranteing smooth system integration they orthogonalize thedevelopment of complex systems Contracts are thus adequatecandidates for a technical counterpart of the legal bindingsbetween partners involved in the distributed and concurrentdevelopment of a system
Contribution 3 Managing RequirementsSo far the task of getting requirements right and managingthem well (Section III-C) has only got support for sortingthe complexity out (traceability services and ontologies whichis undoubtely necessary) However requirements can only betested on implementations and it is not clear whether properdistinctions are made when performing tests regarding thefollowing fusing the results of tests associated to differentchapters or viewpoints of a requirement document versusfusing the results of tests associated to different sub-systemstesting a requirement under the responsibility of the designerof the considered sub-system versus testing a requirementcorresponding to an assumption regarding the context of useof this sub-systemmdashsuch distinctions should be made as weshall see Also requirements are barely executable and cannotin general be simulated Requirements engineering is the otherprimary target of contract-based design the above issues areproperly handled by contracts and contracts offer improvedsupport for evidencing the satisfaction of certification con-straints
Contribution 4 Managing RisksRisk metrics and risk mitigation measures are the essentialtools in managing risks (Section III-D) By offering improvedsupport for sub-contracting and distributing design to differentteams contracts are likely to significantly reduce the ldquonot myfaultrdquo syndrome
Contribution 5 Addressing CertificationAs explained in Section III-B2 the design of critical sys-tems is subject to a number of certification standards Whilecertification steps are mostly concerned with the processesnot the designs themselves the recent move from DO 178Bto DO 178C for level A critical systems in aeronautics has
RR ndeg 8147
Contracts for System Design 16
shown for the first time the consideration of formal proofsor validations as valid evidences We believe that the samewill eventually hold for contracts In particular by providingadequate formal support for completeness consistency com-patibility and more for sets of requirements contracts wouldprovide a valuable contribution to certification
IV CONTRACTS WHAT WHY WHERE AND HOWAs we argued in the previous section there are two basic
principles followed by design methods so far developed ab-stractionrefinement and compositiondecomposition Abstrac-tion and refinement are processes that relate to the flow of de-sign between different layers of abstraction (vertical process)while composition and decomposition operate at the same levelof abstraction (horizontal process) In this section we presentbriefly contracts and the basic operations they support andthen me make the point that contracts are ideal tools to solidifyboth vertical and horizontal processes providing the theoreticalbackground to support formal methods We conclude thesection by providing a (non exhaustive) bibliography on thegeneral concept of contract
A Contracts
Here we propose a ldquoprimerrdquo on contracts using a simpleexample as the reference for their use
1) Components and their Environment Contracts We startfrom a model that consists of a universal set M of com-ponents each denoted by the symbol M A component Mis typically an open system ie it contains some inputsthat are provided by other components in the system or theexternal world and it generates some outputs This collectionof other components and the exterior world is referred to as theenvironment of the component The environment is often notcompletely known when the component is being developedAlthough components cannot constrain their environment theyare designed to be used in a particular context
In the following example we define a component M1 thatcomputes the division between two real inputs x and y andreturns the result through the real output z The underlyingassumption is that M1 will be used within a design contextthat prevents the environment from giving the input y = 0Since M1 cannot constrain its input variables we handle theexceptional input y = 0 by generating an arbitrary output
M1
variables
inputs x y
outputs z
types x y z isin Rbehaviors (y 6= 0rarr z = xy) and (y = 0rarr z = 0)
A contract contract denoted by the symbol C is a de-scription of a component with the following characteristicproperties
1) Contracts are intentionally abstract2) Contracts distinguish responsibilities of a component
from that of its environmentProperty 1) of a contract highlights the goal of handlingcomplexity of the systems Thus contracts expose enough
information about the component but not more than necessaryfor the intended purpose We can see a contract as an under-specified description of a component that can be either veryclose to the actual component or specify only a singleproperty of a componentrsquos behavior Regarding Property 2)and in contrast to components a contract explicitly makes adistinction between assumptions made about the environmentand guarantees provided mirroring different roles and respon-sibilities in the design of systems
A contract can be implemented by a number of differentcomponents and can operate in a number of different envi-ronments Hence we define a contract C at its most abstractlevel as a pair C = (EC MC ) of subsets of components thatimplement the contract and of subsets of environments inwhich the contract can operate We say that a contract C isconsistent if MC 6= empty and compatible if EC 6= empty
This definition of contracts and the implementation relationis very general and as such it is not effective In concretecontract- based design theories a contract needs to have afinite description that does not directly refer to the actualcomponents and the implementation relation needs to beeffectively computable and establish the desired link betweena contract and the underlying components that implement it
For our present simple example of static systems wepropose the following way to specify contracts
C1
variables
inputs x y
outputs z
types x y z isin Rassumptions y 6= 0
guarantees z = xy
C1 defines the set of components having as variablesinputs x y output z of type real and whose behaviorssatisfy the implication
ldquoassumptionsrArr guaranteesrdquo
ie for the above example y 6= 0rArr z = xy Intuitivelycontract C1 specifies the intended behavior of components thatimplement division It explicitly makes the assumption that theenvironment will never provide the input y = 0 and leaves thebehavior for that input undefined
This contract describes an infinite number of environmentsin which it can operate namely the set EC1
of environmentsproviding values for x and y with the condition that y 6=0 Itdescribes an infinite number of components that implementthe above specification where the infinity comes from theunderspecified case on how an implementation of C1 shouldcope with the illegal input y = 0 In particular we have thatM1 implements C1 Thus contract C1 is consistent We nowshow a variant of contract C1 that is not consistent
Cprime1
variables
inputs x y
outputs z
types x y z isin Rassumptions T
guarantees z = xyRR ndeg 8147
Contracts for System Design 17
where symbol T denotes the boolean constant ldquotruerdquo Incontrast to C1 the contract Cprime1 makes no assumption on valuesof the input y Hence every component that implements Cprime1has to compute the quotient xy for all values of y includingy = 0 which makes no sense
B Contract Operators
There are three basic contract operators that are used insupport of the design methodologies we presented previouslycomposition refinement and conjunction
1) Contract Composition and System Integration Intu-itively the composition operator supports component-baseddesign and in general horizontal processes The compositionoperator that we denote by the symbol times is a partial functionon components The composition is defined with respect to acomposability criterion where two components M and M prime
are composable if their variable types match Composabilityis a syntactic property on pairs of components that definesconditions under which the two components can interactComposition times must be both associative and commutative inorder to guarantee that different composable components maybe assembled together in any order
Consider the component M2 defined as follows
M2
variables
inputs x
outputs y
types x y isin Rbehaviors y = ex
The component M2 computes the value of the output variabley as the exponential function of the input variable x M1 andM2 are they are composable since both common variables xand y have the same type x is an input variable to both M1
and M2 and the output variable y of M2 is fed as an input toM1 It follows that their composition M1 timesM2 has a singleinput variable x and computes the output z as a function ofx that is z = xex
Now consider component M prime2 that consists of an inputvariable x and an output variable z both of type real wherez = abs(x)
M prime2
variables
inputs x
outputs z
types x z isin Rbehaviors z = abs(x)
The component M prime2 is not composable with M1 becausethe two components share the same output variable z Theircomposition is illegal as it would result in conflicting rulesfor updating z
We now lift the above concepts to contracts The compo-sition operator between two contracts denoted by otimes shallbe a partial function on contracts involving a more subtlecompatibility criterion Two contracts C and Cprime are compatibleif their variable types match and if there exists an environmentin which the two contracts properly interact The resultingcomposition C otimes Cprime should specify through its assumptions
this set of environments By doing so the resulting contractwill expose how it should be used Unlike component com-posability contract compatibility is a combined syntactic andsemantic property
Let us formalize this For C a contract let AC and GC beits assumptions and guarantees and define
GC1otimesC2 = GC1andGC2
AC1otimesC2 = max
A∣∣∣∣∣∣AandGC2rArrAC1andAandGC1rArrAC2
(1)
where ldquomaxrdquo refers to the order of predicates by implica-tion thus AC1otimesC2 is the weakest assumption such that thetwo referred implications hold Thus this overall assumptionwill ensure that when put in the context of a componentimplementing the second contract then the assumption ofthe first contract will be met and vice-versa Since the twoassumptions were ensuring consistency for each contract theoverall assumption will ensure that the resulting compositionis consistent This definition of the contract compositiontherefore meets our previously stated requirements The twocontracts C1 and C2 are called compatible if the assumptioncomputed as in (1) differs from F the ldquo falserdquo predicate
Consider contracts C2 and Cprime2 that we define as follows
C2
variables
inputs u
outputs x
types u x isin Rassumptions T
guarantees x gt u
Cprime2
variables
inputs v
outputs y
types v y isin Rassumptions T
guarantees y = minusv
C2 specifies components that for any input value u generatesome output x such that x gt u and Cprime2 specifies componentsthat generate the value of the output variable y as functiony = minusv of the input v Observe that both C2 and Cprime2 areconsistent A simple inspection shows that C1 and C2 can becomposed and their composition yields
C1 otimes C2
variables
inputs u y
outputs x z
types x y u z isin Rassumptions y 6= 0
guarantees x gt u and z = xy
C1 and Cprime2 can also be composed and their composition yields
C1 otimes Cprime2
variables
inputs v x
outputs y z
types v x y z isin Rassumptions v 6= 0
guarantees y = minusv and z = xyRR ndeg 8147
Contracts for System Design 18
Both compositions possess a non-empty assumption (observealso that they are both free of exception) reflecting that thetwo pairs (C1 C2) and (C1 Cprime2) are compatible
In our example we require that compositions C1otimes(C2otimesC3)and (C1 otimes C2) otimes C3 result in equivalent contracts as well ascompositions C1otimesC2 and C2otimesC1 thus providing support forincremental system integration
A quotient operation can be defined that is dual to thecomposition operation Given a system-wide contract C anda contract C1 that specifies pre-existing components and theirinteractions the quotient operation CC1 defines the part ofthe system-wide contract that still needs to be implementedIt formalizes the practice of ldquopatchingrdquo a design to make itbehave according to another contract
2) Contract Refinement and Independent DevelopmentIn all vertical design processes the notions of abstractionand refinement play a central role The concept of contractrefinement must ensure the following if contract Cprime refinescontract C then any implementation of Cprime should 1) implementC and 2) be able to operate in any environment for C Hencethe following definition for refinement pre-order betweencontracts we say that the contract Cprime refines the contract C ifECprime supe EC andMCprime subeMC Since is a pre-order refinementis a transitive relation For our current series of examples andusing previous notations Cprime C amounts to requiring that 1AC implies ACprime and 2 ACprimerArrGCprime implies ACrArrGC
In Figure 4 we start with the contract C1 that representsthe general system-wide requirements We decompose theserequirements into requirements of three subsystems resultingin three contracts C11 C12 and C13 with the property thatC11otimesC12otimesC13 C1 Now these three contracts can be handedto different design teams and refined further independentlyIn particular C12 is further decomposed into contracts C121
and C122 such that C121 otimes C122 C12 and similarly C13 isfurther decomposed into contracts C131 and C132 such thatC131 otimes C132 C13
For all contracts C1 C2 Cprime1 and Cprime2 if C1 is compatible withC2 and Cprime1 C1 and Cprime2 C2 then Cprime1 is compatible with Cprime2and Cprime1 otimes Cprime2 C1 otimes C2
We now give a concrete example where we start withvery abstract requirements for a component that implementsa function z = xex Consider contracts Cprimeprime1 and Cprimeprime2 that wedefine as follows
Cprimeprime1
variables
inputs y
outputs z
types y z isin Rassumptions y 6= 0
guarantees z isin R
Cprimeprime2
variables
inputs x
outputs y
types x y isin Rassumptions T
guarantees y gt 0
The contract Cprimeprime1 formalizes the most crude and abstractrequirements for a divider It requires that the denominatorvalue (input variable y) is not equal to 0 and only ensuresthat the output value of z is any real Note that the contractCprimeprime1 does not declare the nominator input variable x Thecontract Cprimeprime2 specifies components that have an input variablex and an output variable of type y The only requirement onthe behavior of Cprimeprime2 is that y is strictly greater than 0 Thecomposition Cprimeprime1 otimes Cprimeprime2 is well defined The contract C1 refinesCprimeprime1 since it allows more inputs (the nominator input variable x)and restricts the behavior of the output variable z by definingits behavior as the division xy It follows that C1 is alsocompatible with Cprimeprime2 and that C1 otimes Cprimeprime2 Cprimeprime1 otimes Cprimeprime2 Finally wehave that M1 and M2 are implementations of their respectivecontracts It follows that M1 timesM2 implements C1 otimes Cprimeprime2
3) Contract Conjunction and Viewpoint Fusion We nowintroduce the conjunction operator between contracts denotedby the symbol and Conjunction is complementary to composi-tion
1) In the early stages of design the system-level speci-fication consists of a requirements document that is aconjunction of requirements
2) Full specification of a component can be a conjunctionof multiple viewpoints each covering a specific (func-tional timing safety etc) aspect of the intended designand specified by an individual contract see Figure 4 foran illustration
3) Conjunction supports reuse of a component in differentparts of a design see Figure 5 for an illustration
We state the desired properties of the conjunction operatoras follows Let C1 and C2 be two contracts If C1 and C2 areshared refinable then C1 andC2 C1 and C1 andC2 C2 and forall contracts C if C C1 and C C2 then C C1 and C2
To illustrate the conjunction operator we consider a contractCT1 that specifies the timing behavior associated with C1 Forthis contract we introduce additional ports that allow us tospecify the arrival time of each signal
CT1
variables
inputs tx ty
outputs tz
types tx ty tz isin R+
assumptions Tguarantees tzlemax(tx ty) + 1
The contract CT1 is shared refinable with C1 Their conjunctionC1 and CT1 yields a contract that guarantees in addition to C1itself a latency with bound 1 (say in ms) for it Becausethere are no assumptions this timing contract specifies thesame latency bound also for handling the illegal input y = 0In fact the contract says more because it does not mentionthe input y it assumes any value of y is acceptable Asa result the conjunction inherits the weakest T assumptionof the timing contract and cancels the assumption of C1This however is clearly not the intent since the timingcontract is not concerned with the values of the signals andis a manifestation of the weakness of this simple contract
RR ndeg 8147
Contracts for System Design 19
framework in dealing with contracts with different alphabetsof ports and variables We will further explain this aspect andshow how to address this problem in Section VII For themoment we can temporarily fix the problem by introducing yin the interface of the contract and use it in the assumptionsas in the following contract CT2
CT2
variables
inputs y tx ty
outputs tz
types y isin R tx ty tz isin R+
assumptions y 6=0guarantees tzlemax(tx ty) + 1
Note that this timing contract does not specify any bound forhandling the illegal input y = 0 since the promise is notenforced outside the assumptions
So far this example was extremely simple In particularit was stateless Extension of this kind of AssumeGuaranteecontracts to stateful contracts will be indeed fully developedin the coming sections and particularly in Section VII
C Contracts in requirement engineering
In this section we introduce a motivating example that isrepresentative of early requirements capturemdashthe specificationof a parking garage Its full development requires technicalmaterial that we introduce later and we thus defer it toSection XI This example illustrates the following features ofcontract based requirements capture namelybull Top-level system specification is by writing a require-
ments document Different formalisms may be used fordifferent kinds of requirements Here we illustrate thisby blending textual requirements written in constrainedEnglish (possibly obtained using boilerplates) with smallsized automata
bull The document itself is structured into chapters describingvarious aspects of the system such as how gates shouldbehave how payment should proceed plus some overallrules
bull Some requirements are under the responsibility of thesystem under development they contribute to specifyingthe guarantees that the system offers Other requirementsare not under the responsibility of the system underdevelopment they contribute to defining the assumptionsregarding the context in which the system should operateas specified
bull Requirements are written in constrained English languageor by using automata
We now begin with the top-level requirements The systemunder specification is a parking garage subject to paymentby the user At its most abstract level the requirementsdocument comprises the different chapters gate payment andsupervisor see Table III The gate chapter will collect thegeneric requirements regarding entry and exit gates Thesegeneric requirements will then be specialized for entry andexit gates respectively
Focus on the ldquogaterdquo chapter It consists of the three require-ments shown on Table III Requirement Rg1 is best described
gateRg1ldquovehicles shall not pass when gate is closedrdquo see Fig 7Rg2 after vehicle_pass vehicle_pass is forbiddenRg3 after gate_open gate_open is forbidden and
after gate_close gate_close is forbiddenpaymentsupervisor
Table IIITHE TOP-LEVEL SPECIFICATION WITH CHAPTER gate EXPANDED
REQUIREMENTS WRITTEN IN italics ARE ASSUMPTIONS UNDER WHICHgate SHOULD OPERATE
0
gate_close
1gate_opengate_close
vehicle_passgate_open
Figure 1 Requirement Rg1 specified as an io-automaton Prefix ldquordquoindicates an input and prefix ldquordquo indicates an output
by means of an io-automaton shown in Figure 1mdashwe providean informal textual explanation for it between quotes Supposethat some requirement says ldquogate_open never occursrdquo Thisis translated by having no mention of gate_open in thecorresponding io-automaton To express this ldquonegativerdquo factwe must keep track of the fact that gate_open belongs tothe alphabet of actions of the io-automaton Thus when per-forming the translation the explicit list of inputs and outputsshould be explicitly given To avoid such additional notationalburden we have cheated by omitting this unless necessaryThe other two requirements are written using constrainednatural language which can be seen as a boilerplate styleof specification Prefix ldquordquo indicates an input and prefix ldquordquoindicates an output
The first two requirements are not under the responsibilityof the system since they rather concern the car driver Thus itdoes not make sense to include them as part of the guaranteesoffered by the system Should we remove them This wouldbe problematic If drivers behave the wrong way unexpectedthings can occur for sure The conclusion is that 1) we shouldkeep requirements Rg1 and Rg2 and 2) we should handlethem differently than Rg3 which is a guarantee offered by thesystem Indeed Rg1 and Rg2 are assumptions under whichthe gate operates as guaranteed We take the convention thatassumptions are written in italics
So far we have specified gate as a list of requirementsRequirement Rg1 specified as an io-automaton can be con-sidered formal Requirements Rg2 and Rg3 are formulatedin constrained natural language and are ready for subsequentformalization eg as io-automata Are we done Not yetWe need to give a formal meaning to what it means to havea collection of requirements and what it means to distinguishassumptions from guarantees Similarly we must give a formalmeaning to what it means to combine different chapters of arequirements document Intuitively all requirements must be
RR ndeg 8147
Contracts for System Design 20
met for a chapter to be satisfied and similarly all chaptersmust be satisfied for the whole specification to be correctlyimplemented Thus we propose to write the top-level specifi-cation C as the following conjunction
C = Cgate and Cpayment and Csupervisor
As we said formally defining what conjunction and is requirestechnical material that is developed later in this paper Thefollowing issues arise regarding this top-level specificationFirst of all since a conjunction operator is involved in theconstruction of C there is a risk of formulating contradictingrequirementsmdashthis is referred to as the issue of consistencySecond are we sure that the top-level specification C iscomplete ie precise enough to rule out undesirable imple-mentations One good way of checking for completeness is tobe able to execute or simulate this top-level specification CWe provide answers to all these issues in Section XI wherethis example is fully developed
request enter
ticket issue
entry gate open
entry gate closeEntryGate
vehicle enter
vehicle exit
exit ticket insert ExitGateexit gate open
exit gate close
ticket insert payment
coin insert paymentPaymentMachine exit ticket issue
Figure 2 System architecture as specified by the designer
Having the top-level specification C at hand the designerthen specifies an architecture ldquoagrave la SysMLrdquo as shown onFigure 2 Some comments are in order regarding this archi-tecture The considered instance of a parking garage consistsof one entry gate one exit gate and one payment machineCompare with the top-level specification of Table III Thelatter comprises a generic gate a payment machine and asupervisor each one with its set of requirements In contrastthe architecture of Figure 2 involves no supervisor Thesupervisor is meant to be distributed among the two gatesThe architecture of Figure 2 seems to be very loosely coupledFirst the PaymentMachine seems to be totally independent Infact the ticket that is inserted in the exit gate must coincidewith the one issued by the PaymentMachine It turns out thatthis reflects a missing assumption regarding the environmentof the system (namely the user of the parking) Then thetwo gates seem to have the shared input ldquovehicle exitrdquo astheir only interaction But this shared input is involved in
requirement Rs3 which forbids the entry if the parking isfull
The next step in the design consists in subcontractingthe development of each of the three sub-systems of thearchitecture of Figure 2 This amounts to specifying threesubcontracts CEntryGate CExitGate and CPaymentMachinesuch that
CEntryGate otimes CExitGate otimes CPaymentMachine C (2)
The symbol in (2) means that any implementation of theleft hand side is also a valid implementation of the top-level C Then the contract composition operator otimes ensuresthat each supplier can develop its sub-system based on itsown sub-contract only and still integrating the so designedsub-systems yields a correct implementation of the top-levelspecification Once the three sub-contracts are found checkingthat they satisfy (2) requires formalizing the contract compo-sition operator otimes Furthermore guessing such sub-contractsis a difficult task In our development of this example inSection XI we propose adequate answers to these issues
D Contract Support for Design Methodologies
The three operators introduced above fit naturally in anydesign methodology developed so far In particular contractcomposition and conjunction supports horizontal processesand contract refinement supports vertical processes We showhow this is so by first analyzing the use of contract conjunc-tion for requirement management then of composition andrefinement for design chain management re-use and indepen-dent development to close with conjunction composition andrefinement for deployment and mapping
1) Supporting open systems When designing componentsfor reuse their context of use is not fully known in advanceWe thus need a specification of components exposing boththe guarantees offered by the component and the assumptionson its possible context of usemdashits ldquoenvironmentrdquo This stateswhat contracts should be
2) Managing Requirements and Fusing Viewpoints Re-ferring to Section III-C complex systems involve a numberof viewpoints (or aspects) that are generally developed bydifferent teams using different skills As a result there is aneed for fusing these viewpoints in a mathematically soundway Structuring requirements or specifications is a desirableobjective at each step of the design Finally we must formal-ize some key properties that must be evidenced as part ofcertification processes
This process is illustrated in Figure 3 In this figure weshow three viewpoints the behavioral viewpoint where thefunctions are specified the timing viewpoint where timingbudgets are allocated to the different activities and the safetyviewpoint where fault propagation effect and handling arespecified Typically different viewpoints are developed bydifferent teams using different frameworks and tools Devel-opment of each viewpoint is performed under assumptionsregarding its context of use including the other viewpoints To
RR ndeg 8147
Contracts for System Design 21
VIEWPOINT VIEWPOINT VIEWPOINTBEHAVIORAL TIMING SAFETY
is a conjunctionevery contract
C =and
i Ci
CB1 CB2 CT CS1 CS2
CB1 and CB2 and CT and CS1 and CS2
Figure 3 Conjunction of requirements and viewpoints in top-level design
get the full system specification the different viewpoints mustbe fused As the notations of Figure 3 suggest conjunctionis used for fusing viewpoints thus reflecting that the systemunder design must satisfy all viewpoints Similarly eachviewpoint is itself a conjunction of requirements seen as theldquoatomicrdquo contractsmdashall requirements must be met
3) Design Chain Management Re-using and IndependentDevelopment In Figure 4 we show three successive stages ofthe design At the top level sits the overall system specificationas developed by the OEM As an example it can be obtained asthe conjunction of several viewpoints as illustrated on Figure 3
is delegated forimplementation by a supplier
is delegated forimplementation by a supplier
C11 otimes (C121 otimes C122)otimes (C131 otimes C132)
C11
C12
C13
C11
C121 C122 C131 C132
C121 otimes C122 C131 otimes C132
C11 otimes C12 otimes C13
C1
is refined by the OEM
Figure 4 Stepwise refinement
As a first design step the OEM decomposes its system intoan architecture made of three sub-systems for independentdevelopment by (possibly different) suppliers For each ofthese sub-systems a contract C1j j = 1 2 3 is developedA contract composition denoted by the symbol ldquootimesrdquo
C11 otimes C12 otimes C13
mirrors the composition of sub-systems that defines the archi-tecture For our method to support independent development
this contract composition operator must satisfy the following
if designs are independently performed for eachsub-contract C1j j = 1 2 3 then integratingthese sub-systems yields an implementation thatsatisfies the composed contract C11 otimes C12 otimes C13
(3)
This contract composition must then be qualified against thetop-level contract C1 This qualification must ensure that anydevelopment compliant with C11 otimes C12 otimes C13 should alsocomply with C1 To ensure substitutability in any legal contextcompliance concerns both how the system behaves and whatits allowed contexts of use are any legal context for C1 shouldbe also legal for C11otimesC12otimesC13 and under any legal contextthe integrated system should behave as specified by C1 This isformalized as the refinement relation denoted by the symbol
C11 otimes C12 otimes C13 C1 (4)
Overall the satisfaction of (4) guarantees the correctness ofthis first design step performed by the OEM
Obtaining the three sub-contracts C11 C12 and C13 is the artof the designer based on architectural considerations Contracttheories however offer the following services to the designerbull The formalization of parallel composition and refinement
for contracts allows the designer to firmly assess whether(4) holds for the decomposition step or not
bull In passing the compatibility of the three sub-contractsC11 C12 and C13 can be formally checked
bull Using contracts as a mean to communicate specificationsto suppliers guarantees that the information provided tothe supplier is self-contained the supplier has all theneeded information to develop its sub-system in a waythat subsequent system integration will be correct
Each supplier can then proceed with the independent devel-opment of the sub-system it is responsible for For instance asupplier may reproduce the above procedure
Alternatively this supplier can develop some sub-systemsby reusing off-the-shelf components For example contractC121 would be checked against the interface specification of apre-defined component M121 available from a library and thefollowing would have to be verified does component M121
satisfy C121 In this context shared implementations are ofinterest This is illustrated on Figure 5 where the same off-the-shelf component implements the two referred contracts
To conclude on this analysis the two notions of refinementdenoted by the symbol ldquordquo and composition of contractsdenoted by the symbol ldquootimesrdquo are key Condition (3) ensuresindependent development holds
4) Deployment and Mapping Here we address a specificbut important point related to Contribution 1 At some pointin the design of the system specifications must be realized byusing resources Resources can be pre-defined sub-systems orcomponents or they can consist of computing resources com-prising computing units and communication media (networksbusses and protocols) This methodology was advocated and
RR ndeg 8147
Contracts for System Design 22
C11
C121 C122 C131 C132
C11 otimes (C121 otimes C122)otimes (C131 otimes C132)
C121 otimes C122 C131 otimes C132
C122 and C132
Figure 5 Conjunction for component reuse
systematically exploited in Platform Based Design [171] orPLM-centric design see footnote 4 in Section II How sucha step can be captured in contract based design is explainednext
When deploying an application over a computing plat-form in addition to the functional viewpoint non-functionalviewpoints (safety timing energy and possibly other) areof importance as well The safety viewpoint is concernedwith the risk of primary faults and failures how they couldpropagate throughout the system and what the consequencesfor the resilience of the overall system would be in termsof failure probability The timing viewpoint collects timingrequirements regarding the application (requirements on la-tencies throughput jitter and schedulability) The effectivesatisfaction of safety or timing viewpoints by a considereddeployment depends on 1) the supporting execution platformand 2) the mapping of the application to this executionplatform We thus need to formalize what ldquomappingrdquo meansThe reader is referred to Figure 6 for the following discussion
M4M3
M5M6
M1
M2
M3
M1
M4
M2
M5
M6x34
xd63 xo
63
x34
C2 C1
C3
P
C
xo63
xd63
Figure 6 Mapping the application to the execution platform as C and P
Suppose one has a virtual model of the execution platform
as an architecture composed of several components Suchcomponents would in the context of Figure 6 consist of adescription of the available computing units a descriptionof the bus protocol and frame structure andor a library ofRTOS (Real-Time Operating System) services The resultingcomponents are enhanced with timing information (for thetiming viewpoint) and fault propagation information (for thesafety viewpoint) Application contracts are attached to thedifferent sub-systems or components as described on the toppart of the figure Similarly platform contracts are attachedto the different sub-systems or components of the executionplatform as described on the bottom part of the figureAccordingly we assume
C =andk
(otimesiisinIk Cik
)P =
otimesjisinJ
(and`isinLj
Pj`)
where
bull The overall platform contract P decomposes asotimes
jisinJ Pj(eg the bus and the different computing units inFigure 6) where each Pj is the conjunction of its differentviewpoints (the function what can be computed and theassociated performance how much time it takes and howmuch energy it consumes)
bull The overall application contract is the conjunction ofits different viewpoints Ci with their own architecturaldecomposition
In Figure 6 we only show a single viewpoint29 and we assumethat distant communication between C2 and C3 has alreadybeen refined to a communication medium compliant with thecommunication resources offered by the execution platform
The mapping of the application over the architecture ismodeled by the conjunction CandP defined by the following setof synchronization tuples30 depicted in red in the Figure 6
bull The wire x34 linking M3 to M4 in the application issynchronized in the deployment P with the variablex34 of the left computing unit where x34 represents theoutput of the module implementing M3 and the input ofthe module implementing M4 And similarly for the wirelinking M5 to M6
bull In the deployment the wire x63 linking M6 to M3
must traverse the bus To capture this we first refinethe application architecture by distinguishing the originxo63 of this wire from its destination xd63 In the refinedapplication architecture we assume that xo63 and xd63 arerelated by some buffer of bounded size The deploymentis then captured by synchronizing xo63 with the output xo63
of the module implementing M6 in the right computingunit and by synchronizing xd63 with the input xd63 of themodule implementing M3 in the left computing unit
29Here we assume that the different application viewpoints are developedfor the whole application and then combined by conjunctionmdashthis is just amethodological proposal we could proceed differently
30In in a synchronization tuple both occurrences and values of the differentelements are unified
RR ndeg 8147
Contracts for System Design 23
This formalizes the deployment as the conjunction
C and P =[and
k
(otimesiisinIk Cik
) ]and [otimesjisinJ(and
`isinLjPj`) ]
ensuring that C and P refines C by construction There ishowever no free lunch The formula C and P expressing de-ployment involves a conjunction and is as such a possiblesource of inconsistencies If this happens then C and P cannotbe implemented Finding an execution platform P causingno inconsistency in C and P requires a good understanding ofthe application and its needs The more advanced techniquesdeveloped in Section XI provide assistance for this
Since C and P relates application and computing platformmdashwhich sit at different layers of the designmdashwe call suchcontracts vertical contracts Contracts that are not vertical aresometimes called horizontal in that they are meant to relatecomponents sitting at a same level of the design hierarchymdashapplication level or computing platform level or ECU (Elec-tronic Computing Unit) level
Techniques of mapping application to its execution platformthat are similar to the above one are used in the RT-Buildertool 31 and in the Metropolis platform [20] [80]
E Bibliographical note
Having collected the ldquorequirementsrdquo on contract theories itis now timely to confront these to the previous work referringto or related to the term ldquocontractrdquo
It is difficult to write a comprehensive bibliography onthe general aspects of contract based design The topic ismulti faceted and has been addressed by several communitiessoftware engineering language design system engineeringand formal methods in a broad sense We report here a partialand limited overview of how this paradigm has been tackledin these different communities While we do not claim beingexhaustive we hope that the reader will find her way to thedifferent literatures
Contracts in SW engineering This part of the biblio-graphical note was inspired by the report [168] Design byContract is a software engineering technique popularized byBertrand Meyer [139] [140] following earlier ideas fromFloyd-Hoare logic [169] [113] Floyd-Hoare logic assignsmeaning to sequential imperative programs in the form oftriples of assertions PCQ consisting of a preconditionon program states and inputs a command and a postcondi-tion on program states and outputs Meyerrsquos contracts weredeveloped for Object-Oriented programming They exposethe relationships between systems in terms of preconditionsand postconditions on operations and invariants on states Acontract on an operation asserts that given a state and inputswhich satisfy the precondition the operation will terminatein a state and will return a result that satisfy the postcondi-tion and respects any required invariant properties Contractscontribute to system substitutability Systems may be replacedby alternative systems or assemblies that offer the same or
31httpwwwgeensoftcomenarticlertbuilder
substitutable functionality with weaker or equivalent precon-ditions and strongerequivalent postconditions With the aimof addressing service oriented architectures Meyerrsquos contractswere proposed a multiple layering by Beugnard et al [37]The basic layer specifies operations their inputs outputs andpossible exceptions The behavior layer describes the abstractbehavior of operations in terms of their preconditions andpostconditions The third layer synchronisation correspondsto real-time scheduling of component interaction and messagepassing The fourth quality of service (QoS) level detailsnon-functional aspects of operations The contracts proposedby Beugnard et al are subscribed to prior to service invo-cation and may also be altered at runtime thus extendingthe use of contracts to Systems of Systems [141] So farcontracts consisting of prepostconditions naturally fit imper-ative sequential programming In situations where programsmay operate concurrently interference on shared variablescan occur RelyGuarantee rules [115] were thus added tointerface contracts Rely conditions state assumptions aboutany interference on shared variables during the execution ofoperations by the systemrsquos environment Guarantee conditionsstate obligations of the operation regarding shared variables
The concepts of interface and contract were subse-quently further developed in the Model Driven Engineering(MDE) [120] [172] [131] In this context interfaces aredescribed as part of the system architecture and comprisetyped ports parameters and attributes Contracts on interfacesare typically formulated in terms of constraints on the en-tities of components using the Object Constraint Language(OCL) [150] [180] Roughly speaking an OCL statementrefers to a context for the considered statement and expressesproperties to be satisfied by this context (eg if the context isa class a property might be an attribute) Arithmetic or set-theoretic operations can be used in expressing these propertiesThis method however does not account for functional andextra-functional properties of interfaces ie for behavior andperformance To account for behavior the classical approachin MDE consists in enriching components with methods thatcan be invoked from outside andor state machines Likewiseattributes on port methods have been used to represent non-functional requirements or provisions of a component [51]The effect of a method is made precise by the actual codethat is executed when calling this method The state machinedescription and the methods together provide directly animplementation for the component mdash actually several MDErelated tools such as GME and Rational Rose automaticallygenerate executable code from this specification [21] [132][161] The notion of refinement is replaced by the concept ofclass inheritance From a contract theory point of view thisapproach has several limitations Inheritance for instance isunable to cover aspects related to behavior refinement Noris it made precise what it means to take the conjunctionof interfaces which can only be approximated by multipleinheritance or to compose them
In a continuing effort since his joint work with W Dammon Life Sequence Charts (LSC) in 2000 [64] with its Play-
RR ndeg 8147
Contracts for System Design 24
Engine implementation [107] David Harel has developed theconcept of behavioral programming [108] [106] [109] whichputs in the forefront scenarios as a program developmentparadigmmdashnot just a specification formalism In behavioralprogramming b-threads generate a flow of events via anenhanced publishsubscribe protocol Each b-thread is a pro-cedure that runs in parallel to the other b-threads When ab-thread reaches a point that requires synchronization it waitsuntil all other b-threads reach synchronization points in theirown flow At synchronization points each b-thread specifiesthree sets of events requested events the thread proposes thatthese be considered for triggering and asks to be notifiedwhen any of them occurs waited-for events the thread doesnot request these but asks to be notified when any of themis triggered and blocked events the thread currently forbidstriggering any of these events When all b-threads are at asynchronization point an event is chosen (according to somepolicy) that is requested by at least one b-thread and is notblocked by any b-thread The selected event is then triggeredby resuming all the b-threads that either requested it or arewaiting for it This mechanism was implemented on top ofJava and LSCs The execution engine uses planning and modelchecking techniques to prevent the system from falling intodeadlock where all requested events are blocked Behavioralprogramming is incremental in that new threads can be addedto an existing program without the need for making any changeto this original program new deadlocks that are created bydoing so are pruned away by the execution engine Whilebehavioral programming cannot be seen as a paradigm ofcontracts it shares with contracts the objectives of incrementaldesign and declarative style of specification
Our focusmdashcontracts for systems and CPS The frame-works of contracts developed in the area of Software En-gineering have established as useful paradigms for compo-nent based software system development In this paper wetarget the wider area of computer controlled systems morerecently referred to as Cyber-Physical systems where reactivesystems [104] [110] [100] [136] are encountered that issystems that continuously interact with some environmentas opposed to transformational systems [100] considered inObject-Oriented programming For reactive systems model-based development (MBD) is generally accepted as a keyenabler due to its capabilities to support early validationand virtual system integration MBD-inspired design lan-guages and tools include SysML [149] or AADL [152] forsystem level modeling Modelica [93] for physical systemmodeling Matlab-Simulink [118] for control-law design andScade [144] [32] and TargetLink for detailed software designUML-related standardisation efforts in this area also includethe MARTE UML32 profile for real-time systems Contracttheories for model based development were considered inthe community of formal verification They were initiallydeveloped as specification formalisms able to refuse certaininputs from the environment Dill proposed asynchronous
32 wwwomgmarteorg
trace structures with failure behaviors [81] A trace structureis a representation of a component or interface with two setsof behaviors The set of successes are those behaviors whichare acceptable and guaranteed by the component Converselythe set of failures are behaviors which drive the componentinto unacceptable states and are therefore refused This workfocuses primarily on the problem of checking refinement anddoes not explore further the potentials of the formalism froma methodological point of view The work by Dill was laterextended by Wolf in the direction of synchronous systemsNegulescu later generalizes the algebra to Process Spaceswhich abstract away the specifics of the behaviors and derivesnew composition operators [143] This particular abstractiontechnique was earlier introduced by Burch with Trace Algebrasto construct conservative approximations [47] and later gen-eralized by Passerone and Burch [154] to study generic tracestructures with failure behaviors and to formalize the problemof computing the quotient (there called mirror) [153] Thispaper aims at proposing for model based design of systemsand CPS a new vista on contracts In the next section wepropose an all encompassing meta theory of contracts
V A MATHEMATICAL META-THEORY OF CONTRACTS
In software engineering meta-models are ldquomodels of mod-elsrdquo ie formal ways of specifying a certain family ofmodels Similarly we call here meta-theory a way to specifya particular family of theories In this section we proposea meta-theory of contracts This meta-theory is summarizedin Table IV It comes as a few primitive concepts on topof which derived concepts can be built A number of keyproperties can be proved about the resulting frameworkThese properties demonstrate that contracts are a convenientparadigm to support incremental development and independentimplementability in system design The meta-theory will serveas a benchmark for our subsequent review of concrete contracttheories
The meta-theory we develop here is novel There are veryfew attempts of that kind In fact the only ones we are awareof are the recent works by Bauer et al [22] and Chen et al [59]which follow a different (and complementary) approach Thediscussion of this work is deferred to the bibliographicalsection V-H
A Components and their composition
To introduce our meta-theory we start from a universe Mof possible components each denoted by the symbol M orE and a universe of their abstractions or contracts eachdenoted by the symbol C Our meta-theory does not presumeany particular modeling style neither for components nor forcontractsmdashwe have seen in Section IV an example of a (verysimple) framework for static systems More generally someframeworks may represent components and contracts with setsof discrete time or even continuous time traces other theoriesuse logics or state-based models of various kinds and so on
We assume a composition M1 timesM2 acting on pairs ofcomponents Component composition times is partially not to-
RR ndeg 8147
Contracts for System Design 25
Concept Definition and generic properties What depends on the particulartheory of contracts
Primitive
Component Components are denoted by M they can be open or closed How components are specified
Composabilityof components A type property on pairs of components (M1M2) How this type property is defined
Compositionof components
M1timesM2 is well defined if and only if M1 and M2 are composableIt is required that times is associative and commutative The definition of the composition
Environment An environment for component M is a componentE such that EtimesM is defined and closed
Derived
Contract A contract is a pair C = (EC MC ) where MC is a subsetof components and EC a subset of legal environments
Which family C of contractscan be expressed andhow they are expressedunless otherwise specifiedquantifying is implicitly over C isin C
Consistency C is consistent iff it has at least one component MC 6= empty How consistency is checked
Compatibility C is compatible iff it has at least one environment EC 6= empty How compatibility is checked
Implementation M |=M C if and only if M isinMCE |=E C if and only if E isinEC
How implementation is checked
Refinement Cprime C iff ECprime supe EC and MCprime subeMC Property 1 holds How refinement is checked
GLB andLUBof contracts
C1andC2 = Greatest Lower Bound (GLB) for we assume GLB existC1orC2 = Least Upper Bound (LUB) for we assume LUB exist
Property 2 holds
Whether and howGLB and LUB can beexpressed and computed
Compositionof contracts
C1otimesC2 is defined if M1 |=M C1M2 |=M C2
rArr (M1M2) composable
C1otimesC2 =andC
∣∣∣∣∣∣M1 |=M C1 and M2 |=M C2 and E |=E C
dArrM1 timesM2 |=M C and EtimesM2 |=E C1 and EtimesM1 |=E C2
Assumption 1 is in force Properties 3 4 and 5 holdSay that C1 and C2 are compatible if so is C1otimesC2
How composition isexpressed and computed
Quotient C1C2 =or C | C otimes C2 C1 Property 6 holds How quotient is
expressed and computed
Table IVSummary of the meta-theory of contracts We first list primitive concepts and then derived concepts introduced by the meta-theory
tally defined Two components that can be composed arecalled composable Composability of components is meantto be a typing property In order to guarantee that differentcomposable components may be assembled together in anyorder it is required that component composition times is asso-ciative and commutative Components that exhibit no meansfor interacting with the outside world are called closed othercomponents are open An environment for a component Mis another component E composable with M and such thatM times E is closed
B Contracts
In our primer of Section IV we have highlighted the im-portance of the legal environments associated with contractsfor which an implementation will operate satisfactorily At theabstract level of the meta-theory we make this explicit next
Definition 1 A contract is a pair C = (EC MC ) where
bull MC subeM is the set of implementations of C andbull EC subeM is the set of environments of C
For any pair (EM) isin EC times MC E is an environmentfor M Hence MtimesE must be well defined and closed Acontract possessing no implementation is called inconsistentA contract possessing no environment is called incompatibleWrite
M |=M C and E |=E C
to express that M isinMC and E isin EC respectivelyIn concrete theories of contracts both components and con-tracts are described in some finite (preferably concise) wayIn turn it is not true that every set Mprime subeM of componentscan be represented as Mprime = MC for some contract C andsimilarly for sets of environments To highlight this
we assume a family C of expressible contracts (5)
Only contracts belonging to this family can be consideredThis is made explicit in Table IV
C Refinement and conjunctionTo support independent implementability the concept of
contract refinement must ensure the following if contract Cprime
RR ndeg 8147
Contracts for System Design 26
refines contract C then any implementation of Cprime should 1)implement C and 2) be able to operate in any environment forC Hence the following definition for refinement preorder between contracts Cprime refines C written Cprime C if and onlyif MCprime sube MC and ECprime supe EC As a direct consequence thefollowing property holds which justifies the use of the termldquorefinementrdquo for this relation
Property 1 (refinement)1) Any implementation of Cprime is an implementation of C
M |=M Cprime rArrM |=M C and2) Any environment of C is an environment of Cprime
E |=E C rArr E |=E CprimeThe conjunction of contracts C1 and C2 written C1 and C2 isthe greatest lower bound (GLB) of these two contracts withrespect to refinement ordermdashwe assume such a GLB existsThe intent is to define this conjunction as the intersection ofsets of implementations and the union of sets of environmentsHowever due to (5) not every set of components is thecharacteristic set of a contract The best approximation consistsin taking the greatest lower bound for the refinement relationThe following immediate properties hold
Property 2 (shared refinement)1) Any contract that refines C1 and C2 also refines C1 and C2
Any implementation of C1 and C2 is a shared implementa-tion of C1 and C2 Any environment of C1 or C2 is anenvironment of C1 and C2
2) For C sube C a subset of contractsandC is compatible if
and only if there exists a compatible C isin C
The conjunction operation formalizes the intuitive notion of aldquoset of contractsrdquo or a ldquoset of requirementsrdquo
D Contract composition
The objective of contract composition is to ensure that1) composing respective implementations of each contract
yields an implementation for the composition and2) composing an environment for the resulting composition
with an implementation for C2 yields an environment forC1 and vice-versa
These two properties are essential in supporting top-downdesign by successive decompositions and refinements of con-tracts Contract composition C1 otimes C2 is thus defined on topof component composition as indicated in Table IV with thefollowing assumption in force throughout this meta-theory
Assumption 1 The following condition holds
C1 otimes C2 isin CC1otimesC2
(Note that this assumption is non trivial since it is not true foran arbitrary set C sube C that
andCisinC C isin C) The condition
for C1 otimes C2 to be defined is that every pair (M1M2) ofrespective implementations is composable so that M1 timesM2
is well definedmdashrecall that component composability is atyping property Consequently if E is an environment forM1timesM2 E is composable with both M1 and M2 and EtimesM1
is an environment for M2 and vice-versa Referring to the
formula defining C1 otimes C2 denote by CC1otimesC2 sube C the set ofcontracts specified in the brackets The following lemma willbe instrumental
Lemma 1 Let four contracts be such that Cprime1 C1Cprime2 C2 and C1 otimes C2 is well defined Then so is Cprime1 otimes Cprime2and CCprime1otimesCprime2 supe CC1otimesC2
Proof Since C1otimesC2 is well defined it follows that every pair(M1M2) of respective implementations of these contracts is acomposable pair of components Hence Cprime1otimesCprime2 is well definedaccording to the formula of Table IV Next since Cprime1 C1 andCprime2 C2 and using Assumption 1 M1 |=M Cprime1 and M2 |=M Cprime2implies M1 |=M C1 and M2 |=M C2 similarly E timesM2 |=E C1and EtimesM1 |=E C2 implies EtimesM2 |=E Cprime1 and EtimesM1 |=E Cprime2Therefore replacing in the big brackets defining the contractcomposition C1 by Cprime1 and C2 by Cprime2 can only increase the setCC1otimesC2 2
To conform to the usage we say that C1 and C2 arecompatible contracts if their composition C1 otimes C2 is definedand compatible in the sense of Table IV The followingproperties are a direct corollary of Lemma 1
Property 3 (independent implementability) For all con-tracts C1 C2 Cprime1 and Cprime2 if
1) C1 is compatible with C22) Cprime1 C1 and Cprime2 C2 hold
then Cprime1 is compatible with Cprime2 and Cprime1 otimes Cprime2 C1 otimes C2
Thus compatible contracts can be independently refined Thisproperty holds in particular if Cprime1 and Cprime2 are singletons
Corollary 1 Compatible contracts can be independentlyimplemented
Property 3 is fundamental particularly in top-down designTop-down incremental design consists in iteratively decom-posing a system-level contract C into sub-system contractsCi i isin I for further independent development To ensure thatindependent development will not lead to integration problemsit is enough to verify that
otimesiisinI Ci C We insist that since
contracts are purposely abstract and subsystems are not manythe composition of contracts Ci will not typically result in stateexplosion33
The following property is essential as it states that contractcomposition can be performed in any order and changesin architecture (captured by changes in parenthesizing) areallowed
Property 4 (associativity and commutativity) For all con-tracts C1 C2 C3 and C4 if C1 and C2 are compatible C3 andC4 are compatible and C1otimesC2 is compatible with C3otimesC4 thenC1 is compatible with C3 C2 is compatible with C4 C1 otimes C3is compatible with C2 otimes C4 and
(C1 otimes C2)otimes (C3 otimes C4) = (C1 otimes C3)otimes (C2 otimes C4) (6)
33 This is unlike in compositional verification where timesiisinIMi |=M Pis to be checked where Mi are detailed implementations and P is aproperty In this case the composition timesiisinIMi typically gives raise to stateexplosion Techniques have thus been proposed to verify such properties inan incremental way [176] [62] [98] [1] [121]
RR ndeg 8147
Contracts for System Design 27
Proof To shorten notations write C12 instead of C1 otimesC2 andsimilarly for any subset of 1 2 3 4 By Assumption 1 andthe associativity and commutativity of component composi-tion C1234 is characterized by the following two propertieswhere index i ranges over the set 1 4
Mi |=M Ci rArr M1times timesM4 |=M C1234
E |=E C1234 rArr Etimes (timesj 6=iMj) |=E Ci(7)
Observe that (7) is fully symmetric which proves (6) Nextusing the assumptions regarding compatibility we derive theexistence of at least one environment E satisfying the premiseof the second implication of (7) Since (7) is fully symmetricthis proves the conclusions of Property 4 regarding compati-bility 2
Property 5 (distributivity) If the following contract compo-sitions are all well defined then the following holds
[(C11 and C21)otimes (C12 and C22)] [(C11 otimes C12) and (C21 otimes C22)] (8)
Proof By Lemma 1 C(C11andC21)otimes(C12andC22) supe CC11otimesC12 Taking the GLB of these two sets thus yields[(C11 and C21)otimes (C12 and C22)] (C11 otimes C12) and similarlyfor (C21 otimes C22) Thus (8) follows 2
The use of distributivity is best illustrated in the followingcontext Suppose the system under design decomposes intotwo sub-systems labeled 1 and 2 and each subsystem hastwo viewpoints associated with it labeled by another indexwith values 1 or 2 Contract (C11 and C21) is then the contractassociated with sub-system 1 and similarly for sub-system 2Thus the left hand side of (8) specifies the set of imple-mentations obtained by first implementing each sub-systemindependently and then composing these implementationsProperty 5 states that by doing so we obtain an implemen-tation of the overall contract obtained by first getting thetwo global viewpoints (C11 otimes C12) and (C21 otimes C22) andthen taking their conjunction This property supports inde-pendent implementation for specifications involving multipleviewpoints Observe that only refinement not equality holdsin (8)
E Quotient
The quotient of two contracts is defined in Table IV It isthe adjoint of the product operation otimes in that C1C2 is themost general context C in which C2 refines C1 It formalizesthe practice of ldquopatchingrdquo a component to make it behavingaccording to another specification From its definition inTable IV we deduce the following property
Property 6 (quotient) The following holds
C C1C2 hArr C otimes C2 C1
Proof Immediate from the definition 2
F Discussion
By inspecting Table IV the different notions can be classi-fied into the following two categories
bull Primitive notions that are assumed by the meta-theoryThis category comprises components component com-posability and composition
bull Derived notions comprise contract refinement conjunc-tion composition and quotient consistency and com-patibility for contracts The derived notions follow fromthe primitive ones through set theoretic non effectivedefinitions
The meta-theory offers by itself a number of fundamentalproperties that underpin incremental development and inde-pendent implementability Concrete theories will offer defini-tions for the primitive notions as well as effective means toimplement (or sometimes approximate) the derived notionsObservers and then abstract interpretation we develop nextprovide generic approaches to recover effectiveness
G Observers
Notion Observer
C = (EC MC )(bEC b
MC)
C = C1andC2 bEC = bE
C1 or bEC2 b
MC = bM
C1 and bMC2
C = C1orC2 bEC = bE
C1 and bEC2 b
MC = bM
C1 or bMC2
C = C1otimesC2bEC(E) =
bMC1 (M1) and bM
C2 (M2)
dArrbEC2 (EtimesM1) and bE
C1 (EtimesM2)
bMC(M1 timesM2) = bM
C1 (M1) and bMC2 (M2)
Table VMirroring the algebra of contracts with observers
A typical obstacle in getting finite (or more generallyeffective) representations of contracts is the occurrence ofinfinite data types and functions having infinite domains Thesecan be dealt with by using observers which originate from thebasic notion of test for programs
Definition 2 Let C be a contract An observer for Cis a pair (bE
C bMC) of non-deterministic boolean functions
M 7rarr F T called verdicts such that
bEC(M) outputs F =rArr M 6isin ECbMC(M) outputs F =rArr M 6isin MC
(9)
The functions M 7rarr bEC(M) and M 7rarr bM
C(M) being bothnon-deterministic accounts for the fact that the outcome of atest depends on the stimuli from the environment and possiblyresults from internal non-determinism of the tested componentitself Note the single-sided implication in (9) which reflectsthat tests only provide semi-decisions
Relations and operations of the meta-theory can be mirroredby relations and operations on observers as explained inTable Vmdashwe omit the formulas for the quotient as semi-effectiveness of testing makes it useless Despite GLB andLUB can be mirrored using the formulas of the table nothingcan be said about the relationship of observers for contractsbased on the fact that they are in a refinement ordering Dually
RR ndeg 8147
Contracts for System Design 28
nothing can be inferred in terms of their refinement fromsuch a relationship between the observers Still the followingweaker result holds which justifies how GLB and LUB arerepresented using observers in Table V
Lemma 2 Let (bEC b
MC) be an observer for C and let Cprime C
Then any pair (bE bM) satisfying bE ge bEC and bM le bM
C is anobserver for CprimeThe following immediate results hold regarding consistencyand compatibility
Lemma 31) If bE
C(E) outputs F for all tested environment E then Cis incompatible
2) If bMC(M) outputs F for all tested component M then C
is inconsistent
To summarize Definition 2 provides semi-decision proceduresto check whether a component or an environment are validfor a contract Lemma 3 provides semi-decision proceduresfor checking consistency and compatibility Finally Table Vindicates how operations from the contract algebra can bereflected into operations on observers
Due to the need for exercising all components or environ-ments using observers for checking consistency or compat-ibility is still non-effective For concrete theories exhibitingsome notion of ldquostrongestrdquo environment or component for theconsidered contract a reinforcement of Lemma 3 will ensureeffectiveness
In Section VI where concrete theories are reviewed weindicate for each theory how observers can be constructedand how Lemma 3 specializes
H Bibliographical note
Abstract contract theories and features of our presen-tation Our presentation here is new There is only a smallliterature providing an abstract formalization of the notion ofcontracts The only attempts we are aware of are the recentworks by Bauer et al [22] and Chen et al [59] albeit withdeeply different and complementary approaches
The publication [22] develops an axiomatization of thenotion of specification from which contracts can be derivedin a second step More precisely specifications are abstractentities that obey the following list of axioms it possesses arefinement relation that is a preorder which induces a notionof equivalence of specifications and a parallel compositionthat is associative commutative (modulo equivalence) andmonotonic with respect to refinement It is assumed thatif two specifications possess a common lower bound thenthey possess a greatest lower bound A quotient is alsoassumed which is the residuation of the parallel composi-tion From specifications contracts are introduced as pairs ofspecifications very much like AssumeGuarantee contracts wedevelop in Section VII are pairs of assertions Sets of legalenvironments and sets of implementations are associated tocontracts Finally modal contracts are defined by borrowingideas from modal specifications we discuss in Section VIIIThis abstract theory nicely complements the one we develop
here in that it shows that both specifications and contracts canbe defined as primitive entities and be used to build moreconcrete theories
The work [59] develops the concept of declarative speci-fication which consists of a tuple P = (ΣinΣout TΣ FΣ)where Σin and Σout are input and output alphabets of actionsΣ = Σin ] Σout and TΣ FΣ sube Σlowast such that FΣ sube TΣ
are sets of permissible and inconsistent traces respectivelymdashthis approach find its origins in earlier work by Dill [81]and Negulescu [143] Outputs are under the control of thecomponent whereas inputs are issued by the environmentThus after any successful interaction between the componentand the environment the environment can issue any input αeven if it will be refused by the component If α is refusedby the component after the trace t isin TΣ tα isin FΣ is aninconsistent trace capturing that a communication mismatchhas occurred An environment is called safe if it can preventa component from performing an inconsistent trace For Qto be used in place of P it is required that Q must existsafely in any environment that P can exist in safely this isthe basis on which refinement is defined Alphabet extensionis used by which input actions outside the considered alphabetare followed by an arbitrary behavior for the declarativespecification A conjunction is proposed that is the GLB forrefinement order A parallel composition is proposed whichis monotonic with respect to refinement A quotient is alsoproposed which is the residuation of parallel composition
Observers Observers being related to the wide areaof software and system testing have been widely studiedA number of existing technologies support the design ofobservers and we review some of them now
Synchronous languages [28] [100] [30] are a formalism ofchoice in dealing with observers The family of SynchronousLanguages comprises mainly the imperative language Es-terel [92] [84] and the dataflow languages Lustre [144] andSignal [157] The family has grown with several childrenoffering statecharts-like interfaces and blending dataflow andstatechart-based styles of programming such as in Scade V634Synchronous languages support only systems governed bydiscrete time not systems with continuous time dynamics(ODEs) They benefit from a solid mathematical semantics Asa consequence executing a given program always yields thesame results (results do not depend on the type of simulator)The simulated or analysed program is identical to the codefor embedding Thanks to these unique features specificationscan easily be enhanced with timing andor safety viewpointsThe RT-Builder35 tool on top of Signal is an example offramework supporting the combination of functional and tim-ing viewpoints while analyzing an application deployed overa virtual architecture (see Section IV-D4) The widely usedSimulinkStateflow36 tool by The Mathworks offers similarfeatures One slight drawback is that its mathematical seman-
34httpwwwesterel-technologiescomproductsscade-suite35httpwwwgeensoftcomenarticlertbuilder36httpwwwmathworkscomproductssimulink
RR ndeg 8147
Contracts for System Design 29
tics is less firmly defined (indeed results of executions maydiffer depending on the code executed simulation or generatedC code) On the other hand Simulink supports continuoustime dynamics in the form of systems of interconnectedODEs (Ordinary Differential Equations) thus supporting themodeling of the physical part of the system Using Simulinkpossibly enhanced with SimScape37 allows for includingphysical system models in observers eg as part of the systemenvironment The same comment holds regarding Modelica38
Actually observers have been proposed and advocated in thecontext of Lustre and Scade [101] [102] [103] Esterel [45]and Signal [137] [138] More precisely Scade advocatesexpressing tests using Scade itself Tests can then easily beevaluated at run time while executing a Scade program Toconclude observe that synchronous languages and formalismsdiscussed in this section are commercially available and widelyused
Another good candidate for expressing observers is theProperty Specification Language (PSL) PSL is an industrialstandard [151] [86] [85] for expressing functional (or behav-ioral) properties targeted mainly to digital hardware designWe believe that PSL is indeed very close to several lessestablished but more versatile formalisms based on restrictedEnglish language that are used in industrial sectors otherthan digital hardware eg in aeronautics automobile orautomation Consider the following property
ldquo For every sequence that starts with an a imme-diately followed by three occurrences of b and endswith a single occurrence of c d holds continuouslyfrom the next step after the end of the sequence untilthe subsequent occurrence of e rdquo
This property is translated into its PSL version
[]ab[3]c |=gt (d until e)
PSL is a well-suited specification language for expressingfunctional requirements involving sequential causality of ac-tions and events Although we are not aware of the usageof PSL in the particular context of contract-based design wemention the tool FoCS [2] that translates PSL into checkersthat are attached to designs The resulting checker takes theform of an observer if the PSL specification is properlypartitioned into assumption and guarantee properties More re-cently PSL was also used for the generation of transactors thatmay adapt high-level requirements expressed as transaction-level modules to the corresponding register-transfer implemen-tation [18] [17] It follows that the existing tool support forPSL makes this specification language suitable in the contract-based design using observers We note that the availabilityof formal analysis tools allows the design to be checkedexhaustivelymdashthis is of course at the price of restrictionson data types Another benefit in using PSL as an observer-based interface formalism is an existing methodology for user-guided automated property exploration built around this lan-
37httpwwwmathworkscomproductssimscape38httpswwwmodelicaorg
guage [158] [42] that is supported by the tool RATSY [43]As previously stated PSL is built on top of LTL and regularexpressions One can thus express liveness properties in PSLwhich are not suitable for online monitoring There are twoorthogonal ways to avoid this potential issue (1) restrictingthe PSL syntax to its safety fragment or (2) adapting the PSLsemantics to be interpreted over finite traces [87] A survey ofusing PSL in runtime verification can be found in [85]
Another relevant formalism for building observers consistsof the Live Sequence Charts (LSC) [64] [107] [105] LSCare a graphical specification language based on scenarios thatis an extension of Message Sequence Charts (MSC)39 Atypical LSC consists of a prechart and a main chart Thesemantics is that whenever the prechart is satisfied in a run ofthe system eventually the main chart must also be satisfiedPrecharts should not be confused with assumptions howeverthey are rather sort of ldquoprerequisitesrdquo LSCs are multi-modalin that any construct in the language can be either cold orhot with a semantics of ldquomay happenrdquo or ldquomust happenrdquorespectively If a cold element is violated (say a conditionthat is not true when reached) this is considered a legalbehavior and some appropriate action is taken Violation ofa hot element however is considered a violation of thespecification and is not allowed to happen in an executionLSC are executable The execution of a set of LSCs is calledplay out by the authors [107] Play out is useful for checkingan LSC specification against a property [66] LSC can beused as (expressive) tests to monitor the execution of a designover non-terminating runs While doing so the same rules asabove are applied except that the design controls the emissionof events and the LSC specification is used to react in caseof violation of the specification This is manifested by theabsence of rules explaining the occurrence of some event atrun-time This procedure is called play in by the authors Toconclude LSCs are well suited to express observers
VI PANORAMA OF CONCRETE THEORIES
For the coming series of sections where concrete contracttheories are reviewed the reader is referred to Table IV ofSection V where the meta-theory of contracts is developedWe will illustrate how various concrete contract theories canbe developed by specializing the meta-theory
VII PANORAMA ASSUMEGUARANTEE CONTRACTS
Our static example of Section IV provided an exampleof contract specified using Assumptions and Guarantees As-sumeGuarantee contracts (AG-contracts) Assumptions char-acterize the valid environments for the considered compo-nent whereas the Guarantees specify the commitments ofthe component itself when put in interaction with a validenvironment Various kinds of AG-contract theories can beobtained by specializing the meta-theory in different waysVariations concern how the composition of components isdefined We will review some of these specialization and relatethem to the existing literature
39httpwwwsdl-forumorgMSCindexhtm
RR ndeg 8147
Contracts for System Design 30
In general AG contract theories build on top of componentmodels that are assertions ie sets of behaviors or tracesassigning successive values to variables As we shall seedifferent kinds of frameworks for assertions can be consid-ered including asynchronous frameworks of Kahn ProcessNetworks (KPN) [117] and synchronous frameworks in whichbehaviors are sequences of successive reactions assigningvalues to the set of variables of the considered system We firstdevelop the theory for the simplest case of a fixed alphabetThen we develop the other cases
A Dataflow AG contracts
For this simplest variant all components and contractsinvolve a same alphabet Σ of variables possessing identical40
domain DWith this simplification a component M identifies with an
assertion
P sube Σ 7rarr Dlowast cupDω (10)
ie a subset of the set of all finite or infinite behaviors overalphabet Σ such a behavior associates to each symbol x isin Σa finite or infinite flow of values The flows are not mutuallysynchronized and there is no global clock or logical step Wediscuss in Section VII-D variants of this framework with moresynchronous models of behaviors For convenience we feelfree to use both set theoretic and boolean notations for therelations and operations on assertions
Two components are always composable and we definecomponent composition by the intersection of their respectiveassertions
P1timesP2 = P1andP2 (11)
Formulas (10) and (11) define a framework of asynchronouscomponents with no global clock and no notion of reac-tion Instead a component specifies a relation between thehistories of its different flows When input and output portsare considered as in Section VII-B and components are in-putoutput functions we obtain the model of Kahn ProcessNetworks [117] widely used for the mapping of synchronousprograms over distributed architectures [159] [160]
Definition 3 A contract is a pair C = (AG) of assertionscalled the assumptions and the guarantees The set EC of thelegal environments for C collects all components E such thatE sube A The set MC of all components implementing C isdefined by AtimesM sube GThus any component M such that M le G or notA is animplementation of C and MC = G or notA is the maximalimplementation Observe that two contracts C and Cprime withidentical input and output alphabets identical assumptionsand such that Gprime or notAprime = G or notA possess identical sets ofimplementations MC =MCprime According to our meta-theorysuch two contracts are equivalent Any contract C = (AG)is equivalent to a contract in saturated form (AGprime) such that
40This is only an assumption intended to simplify the notations It is by nomeans essential
Gprime supe notA or equivalently G or A = T the true assertionto exhibit Gprime just take Gprime = G or notA A saturated contractC = (AG) is consistent if and only if G 6= empty and compatibleif and only if A 6= empty
Next for C and Cprime two saturated contracts with identicalinput and output alphabets
refinement Cprime C holds iffAprimegeAGprimeleG (12)
Conjunction follows from the refinement relation for C1 andC2 two saturated contracts with identical input and outputalphabets C1 and C2 = (A1orA2 G1andG2)
Focus now on contract composition C = C1 otimes C2 for twosaturated contractsmdashthis is no loss of generality as we haveseen Contract composition instantiates through the followingformulas cf (1) in Section IV
G = G1andG2
A = max
A∣∣∣∣∣∣AandG2rArrA1
andAandG1rArrA2
(13)
which satisfies Assumption 1 of the meta-theory If further-more contracts are saturated then (13) reformulates as theformulas originally proposed in [29]
G = G1 andG2
A = (A1 andA2) or not(G1 andG2)(14)
Observe that the so obtained contract (AG) is saturatedG orA = (G1 andG2) or (A1 andA2) or not(G1 andG2) = T
No quotient operation is known for AssumeGuaranteecontracts
We finish this section by observing that the two contractsC1 and Cprime1 of Section IV-A1 satisfy Cprime1 C1 according to thetheory of this section guarantees are identical but assumptionsare relaxed
B Capturing exceptions
Referring to the primer of Section IV-A1 and its staticsystem example dividing by zero may raise an exception Forinstance a careless designer may consider instead of M1 aslight variation M prime1 of it where the behaviors are only partiallydefined
M prime1 behaviors (y 6= 0rarr z = xy)
leaving what happens if a value 0 is submitted for y unspeci-fied In practice y = 0 would raise an exception leading to anunpredictable outcome and possibly a crash unless exceptionhandling is offered as a rescue by the execution platform
In this section we show how a mild adjustment of ourtheory of AG contracts can capture exceptions and theirhandling To simplify we develop this again for the case ofa fixed alphabet Σ We only present the add-ons with respectto the previous theories the parts that remain unchanged arenot repeated
Since exceptions are undesirable events caused by the com-ponent itself and not by its inputsmdashfor our simple example the
RR ndeg 8147
Contracts for System Design 31
exception is the improper handling of the division by zeromdashweneed to include inputs and outputs as part of our frameworkfor components
A component is thus a tuple M = (ΣinΣout P ) whereΣ = Σin cup Σout is the decomposition of alphabet Σ intoits inputs and outputs and P sube (Σ 7rarr (Dlowast cupDω)) is anassertion Whenever convenient we shall denote by Σin
M QM PM etc the items defining component M Components M1
and M2 are composable if Σout1 cap Σout
2 = empty If so thenM1timesM2 = (ΣinΣout P ) is well defined with Σout =Σout
1 cup Σout2 Σin = Σminus Σout and P = P1 cap P2
Let us now focus on exceptions To capture improper re-sponse (leading to a ldquocrashrdquo) we distinguish a special elementfail isin D We assume that crash is not revertible ie inany behavior of the component any variable remains at failwhen it reaches that value Referring to the static example ofSection IV we would then set x0 = fail for any x We arenow ready to formalize what it means for a component to befree of exception
Definition 4 A component M is free of exception if1) It accepts all inputs
prΣinM
(PM ) = ΣinM 7rarr (DlowastcupDω)
2) It does not cause by itself the occurrence of fail in itsbehaviors for any behavior σ isin PM if the projectionprΣin
M(σ) of σ to the input alphabet Σin
M does not involvefail then neither does σ
Exception freeness defined in this way is such that if M1 andM2 are both composable and free of exception then M1timesM2
is also free of exception Hence we are free to restrict ouruniverse of components to exception free componentsmdashthusDefinition 4 defines our family of components AG contractsare re-defined accordingly
Definition 5 A contract is a tuple C = (ΣinΣout AG)where Σin and Σout are the input and output alphabets andA and G are assertions over Σ called the assumptions andthe guarantees The set EC of the legal environments for C areall free of exception components E such that Σin
E = ΣoutC
ΣoutE = Σin
C and PE sube A The set MC of all componentsimplementing C is defined by M is free of exception Σin
M =ΣinC and Σout
M = ΣoutC and PEtimesM sube G for every environment
E of CFocus now on the issue of consistency and compatibility forcontracts The following holds
Property 7 Let C = (ΣinΣout AG) be a contract satis-fying the following conditions
prΣinC
(G) = ΣinM 7rarr (DlowastcupDω) (15)
prΣoutC
(A) = ΣoutM 7rarr (DlowastcupDω) (16)
fail does not occur in G andA (17)
Then C is consistent and compatibleProof By condition (15) the component M = (ΣinΣout G)satisfies condition 4 of Definition 4 It may not satisfy condi-tion 2 however To achieve this we must modify in M the
behaviors not belonging to A to avoid fail to occur PreservingM on A will ensure that implementation of C is preservedTo get M prime replace any behavior σ isin G and notA by a behaviorσprime such that prΣin
C(σprime) = prΣin
C(σ) and prΣout
C(σprime) 63 fail
Component M prime obtained in this way is free of exception andimplements C showing that C is consistent Consider next thecomponent E = (ΣoutΣin A) If E is free of exception thenit is an environment for C If this is not the case then we canmodify E on AandnotG as we did for obtaining M prime This yieldsan environment Eprime for C showing that C is compatible 2
Conditions (15) and (16) express that assumptions andguarantees are both input enabled Condition (17) is the keyone Observe that now contract Cprime1 of Section IV-A1 isinconsistent since it has no implementationmdashimplementationsmust be free of exception In turn contract C1 is consistentThis is in contrast to the theory of Section VII-A whereboth contracts were considered consistent (crashes were notruled out) Indeed contract C1 of Section IV-A1 satisfies theconditions of Property 7 whereas Cprime1 does not Addressingexceptions matters
C Dealing with variable alphabets
Since contracts aim at capturing incomplete designs wecannot restrict ourselves to a fixed alphabetmdashit is not known inadvance what the actual alphabet of the complete design willbe Thus the simple variants of Sections VII-A and VII-B haveno practical relevance and we must extend them to dealingwith variable alphabets In particular components will now bepairs M = (ΣM PM ) where ΣM is the alphabet of M andPM is an assertion over ΣM Similarly contracts are triplesC = (ΣC AC GC) where assumptions AC and guarantees GCare assertions over alphabet ΣC
Key to dealing with variable alphabet this is the operationof alphabet equalization that we introduce next For P an as-sertion over alphabet Σ and Σprime sube Σ we consider its projectionprΣprime(P ) over Σprime which is simply the set of all restrictionsto Σprime of all behaviors belonging to P We will also need theinverse projection prminus1
Σprimeprime (P ) for Σprimeprime supe Σ which is the set ofall behaviors over Σprimeprime projecting to Σ as behaviors of P For(Σi Pi) i = 1 2 we call alphabet equalization of (Σ1 P1)and (Σ2 P2) the two assertions (Σprminus1
Σ (Pi)) i = 1 2 whereΣ = Σ1 cup Σ2
We also need to define alphabet equalization when thealphabet Σ decomposes as Σ = Σin ] Σout Equalizing theabove decomposition to a larger alphabet Σprimeprime supe Σ yieldsΣprimeprimeout = Σout whence Σprimeprimein = Σprimeprime Σprimeprimeout follows
Alphabet equalization serves as a preparation step to reusethe framework of Section VII-A when alphabets are variable
This being defined all operations and relations introducedin Section VII-A are extended to the case of variable alphabetsby 1) applying alphabet equalization to the involved assertionsand 2) reusing the operation or relation as introduced inSection VII-A
As pointed out in [29] this generalization yields a contracttheory that is a valid instantiation of the meta-theory (up tothe missing quotient) It is not satisfactory from the practical
RR ndeg 8147
Contracts for System Design 32
standpoint however The reason is that the conjunction oftwo contracts with disjoint alphabets yields a trivial assump-tion T which is very demandingmdashany environment must beaccommodatedmdashand does not reflect the intuition (more onthis will be discussed in Section VIII-D
To summarize Sections VII-A VII-B and VII-C togetherdefine a framework for asynchronous AssumeGuarantee con-tracts where components are of Kahn Process Network type
D Synchronous AG contracts
We obtain variants of this framework of AssumeGuaranteecontracts by changing the concrete definition of what anassertion is and possibly revisiting what the component com-position is We can redefine assertions as
P sube (Σ 7rarr D)lowast cup (Σ 7rarr D)ω (18)
Compare (18) with (10) In both cases assertions are sets ofbehaviors With reference to (10) behaviors were tuples offinite or infinite flows one for each symbol of the alphabetIn contrast in (18) behaviors are finite or infinite sequencesof reactions which are the assignment of a value to eachsymbol of the alphabet By having a distinguished symbolperp isin D to model the absence of an actual data we getthe multiple-clocked synchronous model used by synchronouslanguages [30] Definition (18) for assertions correspond to thesynchronous model of computation whereas (10) correspondsto the Kahn Process Network type of model [117] [142] Thematerial of Sections VII-A VII-B and VII-C can be adaptedto this new model of component composition thus yielding aframework of synchronous AssumeGuarantee contracts
E Observers
The construction of observers for this case is immediate Wedevelop it for the most interesting case in which exceptions arehandled see Sections VII-A and VII-B Let P be an assertionaccording to (10) P defines a verdict bP by setting
bP (σ) = T if and only if σ isin P (19)
Observers must return their verdict in some finite amount oftime Hence on-line interpretation based on Definition 3 isappropriate With this interpretation for C = (ΣinΣout AG)a contract its associated observer is obtained as follows withreference to Definition 2
bull bEC(E) is performed by drawing non-deterministically a
behavior σ of E and then evaluating bA(σ)bull bMC(M) is performed by drawing non-deterministically a
behavior σ of M and then evaluating bA(σ)rArr bM (σ)
Lemma 3 for generic observers specializes to the followingeffective semi-decision procedure
Lemma 4
1) If bA outputs F then C is incompatible2) If bA rArr bG outputs F then C is inconsistent
F Discussion
AssumeGuarantee contracts are a family of instantiationsof our meta-theory This family is flexible in that it canaccommodate different models of communication and differentmodels of exceptions AssumeGuarantee contracts are anadequate framework for use in requirements capture Indeedrequirements are naturally seen as assertions When categoriz-ing requirements into assumptions (specifying the context ofuse of the system under development) and guarantees (that thesystem offers) formalizing the resulting set of requirements asan AG contract seems very natural
Regarding exceptions the special value fail that we intro-duced to capture exceptions is not something that is given inpractice Value fail may subsume various run time errors Al-ternatively for the synchronous AssumeGuarantee contractsfail can capture the failure of a component to be input enabled(able in each reaction to accept any tuple of inputs)
In its present form the framework of AssumeGuaranteecontracts (synchronous or asynchronous) suffers from theneed to manipulate negations of assertions an operation thatis generally not effective except if the framework is restrictedto finite state automata and finite alphabets of actions Forgeneral frameworks using observers or abstract interpretationcan mitigate this in part
G Bibliographical note
By explicitly relying on the notions of Assumptions andGuarantees AG-contracts are intuitive which makes themappealing for the engineer In AG-contracts Assumptions andGuarantees are just properties The typical case is when theseproperties are languages or sets of traces which includes theclass of safety properties [122] [58] [136] [14] [61] AG-contracts were advocated by the SPEEDS project [29] Theywere further experimented in the framework of the CESARproject [63] with the additional consideration of weak andstrong assumptions The theory developed in [29] turns outto be closest to this presentation still exceptions were nothandled in [29] The presentation developed in this paperclarifies the design choices in AG-contract theories
Inspired by [126] another form for AG-contract was pro-posed by [97] [99] when designs are expressed using theBIP programming language [41] [174] To achieve separatedevelopment of components and to overcome the problemsthat certain models have with the effective computation ofthe operators the authors avoid using parallel compositionotimes of contracts Instead they replace it with the concept ofcircular reasoning which states as follows in its simplestform if design M satisfies property G under assumptionA and if design N satisfies assumption A then M times Nsatisfies G When circular reasoning is sound it is possibleto check relations between composite contracts based ontheir components only without taking expensive compositionsIn order for circular reasoning to hold the authors deviserestricted notions of refinement under context and show howto implement the relations in the contract theory for the BIP
RR ndeg 8147
Contracts for System Design 33
framework Compatibility is not addressed and this proposaldoes not consider conjunction
Regarding extensions a notion of contract for real-timeinterfaces is proposed in [40] Sets of tasks are associated tocomponents which are individually schedulable on a processorAn interface for a component is an ω-language containing alllegal schedules Schedulability of a set of components on asingle processor then corresponds to checking the emptinessof their intersection The interface language considered isexpressive enough to specify a variety of requirements likeperiodicity the absence or the presence of a jitter etc An as-sumeguarantee contract theory for interfaces is then developedwhere both assumptions and guarantees talk about boundson the frequency of task arrivals and time to completionsDependencies between tasks can also be captured Refinementand parallel product of contracts are then defined exactly asin the SPEEDS generic approach
In [145] a platform-based design methodology that usesAG analog contracts is proposed to develop reliable ab-stractions and design-independent interfaces for analog andmixed-signal integrated circuit design Horizontal and verti-cal contracts are formulated to produce implementations bycomposition and refinement that are correct by constructionThe effectiveness of the methodology is demonstrated on thedesign of an ultra-wide band receiver used in an intelligenttire system an on-vehicle wireless sensor network for activesafety applications
AG-contracts have been extended to a stochastic setting byDelahaye et al [75] [76] [77] In this work the implementa-tion relation becomes quantitative More precisely implemen-tation is measured in two ways reliability and availabilityAvailability is a measure of the time during which a systemsatisfies a given property for all possible runs of the system Incontrast reliability is a measure of the set of runs of a systemthat satisfy a given property Following the lines of the contracttheories presented earlier satisfaction is assumption-dependentin the sense that runs that do not satisfy the assumptions areconsidered to be ldquocorrectrdquo the theory supports refinementstructural composition and logical conjunction of contractsand compositional reasoning methods have been proposedwhere the stochastic or non-stochastic satisfaction levels canbe budgeted across the architecture For instance assume thatimplementation Mi satisfies contract Ci with probability αifor i = 1 2 then the composition of the two implementationsM1timesM2 satisfies the composition of the two contracts C1otimesC2
with probability at least α1 + α2 minus 1Features of our presentation This presentation of AG-
contracts is new in may respects For the first time it iscast into the meta-theory of contracts with the advantage ofclarifying the definition of refinement and parallel compositionof contractsmdashthis involved some hand waving in the originalwork [29] Also this allowed us to handle exceptions properly
VIII PANORAMA INTERFACE THEORIES
Interface theories are an interesting alternative to As-sumeGuarantee contracts They aim at providing a merged
specification of the implementations and environments associ-ated to a contract via the description of a single entity calledan interface We review some typical instances of interfacetheories with emphasis on interface automata and modalinterfaces Interface theories generally use (a mild variation of)Lynch InputOutput Automata [135] [134] as their frameworkfor components and environments As a prerequisite we thusrecall the background on InputOutput Automata io-automatafor short
A Components as io-automataAn io-automaton is a tuple M = (ΣinΣout Q q0rarr)
wherebull Σin and Σout are disjoint finite input and output alpha-
bets set Σ = Σin cup Σoutbull Q is a finite set of states and q0isinQ is the initial statebull rarr sube QtimesΣtimesQ is the transition relation as usual we
write q αminusrarr qprime to mean (q α qprime) isin rarr and qαminusrarr to
indicate the existence of a qprime such that q αminusrarr qprimeBy concatenation transition relation rarr extends to a relationrarrlowast on Q times Σlowast times Q where Σlowast is the set of all finite wordsover Σ Say that a state qprime is reachable from q if there existssome word m such that q mminusrarrlowast qprime To considerably simplifythe development of the theory we restrict ourselves to
deterministic io-automata ie such thatq
αminusrarr q1 and q αminusrarr q2 implies q2 = q1(20)
Two io-automata M1 and M2 having identical alphabet Σare composable if the usual inputoutput matching conditionholds Σout
1 capΣout2 = empty and their composition M = M1timesM2
is given by
Σin = Σin1 cap Σin
2
Σout = Σout1 cup Σout
2
Q = Q1 timesQ2 and q0 = (q10 q20)
and the transition relation rarr is given by
(q1 q2)αminusrarr (qprime1 q
prime2) iff qi
αminusrarri qprimei i = 1 2
An io-automaton is said closed whenever Σin = empty and openotherwise For Mi i = 1 2 two io-automata and two statesqi isin Qi say that q1 simulates q2 written q2leq1 if
forallα qprime2 such that q2αminusrarr2 qprime2 rArr
q1
αminusrarr1 qprime1
and qprime2leqprime1(21)
Say that
M1 simulates M2 written M2leM1 if q20leq10 (22)
Observe that simulation relation (2122) does not distinguishinputs from outputs neither it distinguishes the componentfrom its environment It is the classical simulation relationmeant for closed systems Due to condition (20) of determin-ism simulation coincides with language inclusion
Variable alphabet is again dealt with using the mechanismof alphabet equalization For M = (ΣinΣout Q q0rarr) anio-automaton and Σprime sup Σ we define
MuarrΣprime
=(Σin cup (Σprime Σ)Σout Q q0rarrprime
)RR ndeg 8147
Contracts for System Design 34
whererarrprime is obtained by adding torarr for each state and eachadded action a self-loop at this state labeled with this action
Componentsmdashand consequently environmentsmdashfor use ininterface theories will be receptive io-automata (also termedinput enabled) ie they should react by proper response toany input stimulus in any state41
M is receptive iff forallq isin Qforallα isin Σin qαminusrarr (23)
Receptiveness is stable under parallel composition
B Interface Automata with fixed alphabet
For reasons that will become clear later we restrict thepresentation of interface automata to the case of a fixedalphabet Σ We begin with the definition of Interface Automatawhich are possibly non-receptive io-automata Moreover wegive their interpretation as contracts according to the meta-theory
Definition 6 An Interface Automaton is a tuple C =(ΣinΣout Q q0rarr) where ΣinΣout Qrarr are as inio-automata
The initial state q0 however may not satisfy q0isinQ If q0isinQholds Interface Automaton C defines a contract by fixing apair (EC MC ) as followsbull The set EC of the legal environments for C collects all
components E such that1) Σin
E = Σout and ΣoutE = Σin Thus E and C seen as
io-automata are composable and E timesC is closed2) For any output action α isin Σin of environment E
such that qEαminusrarrE and any reachable state (qE q)
of E times C then (qE q)αminusrarrEtimesC holds
There exists a unique maximal environment EC isin EC inthat EC timesC simulates EtimesC in the sense of (22) for anyE isin EC EC = (ΣoutΣin Q cup gt q0rarrEC ) where(a) the restriction to Qtimes ΣtimesQ of transition relationrarrEC coincides with rarr
(b) forallq isin Q q αminusrarrEC gt holds if and only if not[qαminusrarr ]
and α isin Σout(c) gt αminusrarrEC gt holds for any α isin Σ
bull The setMC of the implementations of C collects all com-ponents M such that io-automaton C simulates ECtimesMin the sense of (22)
Condition 2) means that environment E is only willing toemit an output if it is accepted as an input by C in thecomposition E times C Regarding the existence and uniquenessof EC observe first that conditions (a) and (b) together implythat EC is receptive Also by (a) and (b) EC times C is strictlyidentical with (emptyΣ Q q0rarr) ie it is obtained from Cseen as an io-automaton by simply turning inputs to outputsConsequently Condition 2) holds and thus EC isin EC By (b)and (c) EC is maximal
The above definition of Interface Automata is heterodoxcompare with the original references [72] [5] Definition 6
41In fact receptiveness is assumed in the original notion of io-automatonby Nancy Lynch [135] [134] We use here a relaxed version of io-automatonfor reasons that will become clear later
introduces the two sets EC and MC whereas no notionof implementation or environment is formally associated toan Interface Automaton in the original definition Also thehandling of the initial state is unusual Failure of q0isinQ tohold typically arises when the set of states Q is emptyOur Definition 6 allows to cast Interface Automata in theframework of the meta-theory of Table IV
Corresponding relations and operations must be instantiatedand we do this next As a first immediate result
Lemma 5 q0 isin Q is the necessary and sufficient conditionfor C to be both consistent and compatible in the sense of themeta-theory ie EC 6= empty and MC 6= empty
Refinement and conjunction Contract refinement as de-fined in Table IV is equivalent to alternate simulation [10]defined as follows for Ci i = 1 2 two contracts say that tworespective states qi i = 1 2 are in alternate simulation writtenq2q1 if
forallα isin Σout2 qprime2 st q2
αminusrarr2 qprime2 rArr
α isin Σout
1
q1αminusrarr1 qprime1
qprime2qprime1
forallα isin Σin1 q
prime1 st q1
αminusrarr1 qprime1 rArr
α isin Σin
2
q2αminusrarr2 qprime2
qprime2qprime1
(24)
Say that C2 refines C1 written C2C1 if q20q10 The firstcondition of (24) reflects the inclusionMC2
subeMC1 whereas
the second condition of (24) reflects the opposite inclusionEC2supe EC1
Alternate simulation can be effectively checkedsee [70] for issues of computational complexity Unfortunatelyno simple formula for the conjunction of contracts is knownSee [83] for the best results in this direction
Parallel composition and quotient Contract compositionC2otimesC1 as defined in the meta-theory is effectively computedas follows for Ci two Interface Automata satisfying the con-ditions of Lemma 5 Consider as a first candidate for contractcomposition the composition C2timesC1 where Ci i = 1 2 areseen as io-automata This first guess does not work becauseof the condition involving environments in the contract compo-sition of the meta-theory More precisely by the meta-theorywe should have
E |=E C rArr [EtimesM2 |=E C1 and EtimesM1 |=E C2]
which requires forallα isin Σouti qi
αminusrarri rArr (q1 q2)αminusrarrC2timesC1
Pairs (q1 q2) not satisfying this are called illegal In words apair of states (q1 q2) is illegal when one Interface Automatonwants to submit an output whereas the other one refuses toaccept itmdashreferring to AssumeGuarantee contracts one couldinterpret this as a mismatch of assumptions and guaranteesin this pair of interfaces Illegal pairs must then be prunedaway Pruning away illegal pairs from C2timesC1 together withcorresponding incoming transitions may cause other illegalpairs to occur The latter must also be pruned away untilfixpoint occurs The result is the contract composition C2otimesC1
RR ndeg 8147
Contracts for System Design 35
As a result of this pruning it may be the case that theresulting contract has empty set of states which by Lemma 5expresses that the resulting composition of the two interfacesis inconsistent and incompatiblemdashin the original literature onInterface Automata [72] [5] it is said that the two interfacesC1 and C2 are incompatible
In [39] incremental design of deterministic Interface Au-tomata is studied Let Cdarr be the interface C with input andoutput actions interchanged Given two Interface Automata C1and C2 the greatest interface compatible with C2 such that theircomposition refines C1 is given by (C2 C1darr)darr Hence the partregarding quotient in the meta-theory is correctly addressed fordeterministic Interface Automata
Dealing with variable alphabets So far we have pre-sented the framework of interface automata for the case of afixed alphabet The clever reader may expect that dealing withvariable alphabets can be achieved by using the mechanismof alphabet equalization via inverse projections42 This is acorrect guess for contract composition It is however not clearif it is also adapted for conjunction for which no satisfactoryconstruction exists as previously indicated
In contrast alphabet equalization and conjunction are el-egantly addressed by the alternative framework of ModalInterfaces we develop now
C Modal Interfaces with fixed alphabet
Modal Interfaces inherit from both the Interface Au-tomata and the originally unrelated notion of Modal Automa-ton (or Modal Transition System) see the bibliographicalnote VIII-G As Interface Automata Modal Interfaces usereceptive io-automata as their components and environmentsThe presentation of Modal Interfaces we develop here isaligned with our meta-theory and thus differs from classicalpresentations Again we begin with the case of a fixedalphabet Σ
Definition 7 We call Modal Interface a tuple of the formC = (ΣinΣout Q q0rarr 99K) where ΣinΣout Q q0 are asin Interface Automata and rarr 99Ksube Q times Σ times Q are twotransition relations called must and may respectively
A Modal Interface C such that q0isinQ induces two (possiblynon receptive) io-automata
and Cmust = (ΣinΣout Q q0rarr)and Cmay = (ΣinΣout Q q0 99K)
A Modal Interface is deterministic if Cmay is deterministic inthe sense of 20 C defines a contract by fixing a pair (EC MC )as follows
The set EC of the legal environments for C collects allcomponents E such that
1) ΣinE = Σout and Σout
E = Σin consequently E andCmust seen as io-automata are composable and E timesCmust is closed the same holds with Cmay in lieu ofCmust
42The inverse projection of an io-automaton is simply achieved by addingin each state a self-loop for each missing symbol
2) For any α isin Σin such that qEαminusrarrE and any reachable
state (qE q) of E times Cmay (qE q)αminusrarrEtimesCmust
There exists a unique maximal environment EC isin EC in thatEC times Cmay simulates E times Cmay in the sense of (22) for anyE isin EC EC = (ΣoutΣin Q cup gt q0rarrEC ) where(a) the restriction to QtimesΣintimesQ of transition relationrarrEC
coincides with rarr the restriction to Q times Σout times Q oftransition relation rarrEC coincides with 99K
(b) for any q isin Q q αminusrarrEC gt holds if and only if not[qα99K ]
and α isin Σout(c) gt αminusrarrEC gt holds for any α isin Σ
The set MC of the implementations of C collects all compo-nents M such that
3) ECtimesCmay simulates ECtimesM in the sense of (22)[only may transitions are allowed for ECtimesM ]
4) for any reachable state (qE qM ) of ECtimesM and (qE q)of ECtimesCmay such that (qE qM )le(qE q) and any ac-tion α isin Σout
M such that q αrarr then (qE qM )αminusrarrECtimesM
[must transitions are mandatory in ECtimesM ]
The first paragraph is a verbatim of the original definition ofModal Interfaces [166] Definition 7 introduces the two setsEC and MC whereas the classical theory of Modal Interfacesconsiders and develops a different notion of model (oftenalso called ldquoimplementationrdquo which is unfortunate) As forInterface Automata in Section VIII-B the handling of initialstate q0 is heterodox Our Definition 7 allows to cast ModalInterfaces in the framework of the meta-theory
To justify the existence and uniqueness of EC observe firstthat conditions (a) and (b) together imply that EC is receptiveCondition (2) follows from (a) Maximality in the sense of(22) follows from (b) and (c)
Consistency and Compatibility We begin with consis-tency Say that state q isin Q of C is consistent if q αrarr impliesq
α99K otherwise we say that it is inconsistent Assume thatC has some inconsistent state q isin Q meaning that for someaction α q αrarr holds but q
α99K does not hold By conditions 3)
and 4) of Definition 7 for any environment E and anyimplementation M of C no state (qE qM ) of EtimesM satisfies(qE qM )leq Hence all may transitions leading to q can bedeleted from C without changing MC Performing this makesstate q unreachable in Cmay thus Condition 2 of Definition 7is relaxed and the set of environments is possibly augmentedSince we have removed may transitions some more stateshave possibly become inconsistent So we must repeat thesame procedure Since the number of states is finite thisprocedure eventually reaches a fixpoint At fixpoint the setQ of states partition as Q = Qcon ]Qincon where Qincon
collects all states that were or became inconsistent as a resultof this procedure and Qcon only collects consistent statesIn addition since the fixpoint has been reached Qincon isunreachable from Qcon As a final step we delete Qincon andcall [C] the so obtained contract The following result holds
Lemma 6
RR ndeg 8147
Contracts for System Design 36
1) Modal Interface [C] satisfies
M[C]
=MC and E[C]supe EC (25)
where the inclusion is strict unless C possesses noinconsistent state
2) [C] offers the smallest set of environments among theModal Interfaces satisfying (25)
3) C is consistent and compatible if and only if Qcon 3 q0In the sequel unless otherwise specified we will only considerModal Interfaces that are consistent and compatible
Refinement and conjunction Conjunction and refinementare instantiated in a very elegant way in the theory of ModalInterfaces Contract refinement in the sense of the meta-theoryis instantiated by the effective notion of Modal refinement weintroduce now Roughly speaking modal refinement consistsin enlarging the must relation (thus enlarging the set of legalenvironments) and restricting the may relation (thus restrictingthe set of implementations) The formalization requires the useof simulation relations
For C a Modal Interface and qisinQ a state of it introducethe following may and must sets
may(q) = α isin Σ | q α99K
must(q) = α isin Σ | q αrarr
Definition 8 (modal refinement) Let Ci i = 1 2 be twoModal Interfaces and let qi be a state of Ci for i = 1 2Say that q2 refines q1 written q2 q1 if
may2(q2) sube may1(q1)must2(q2) supe must1(q1)
and forallα isin Σ
q1
α99K1 qprime1
q2α99K2 qprime2
=rArr qprime2 qprime1
Say that C2 C1 if q20 q10
The following result relates modal refinement with contractrefinement as defined in the meta-theory It justifies the con-sideration of modal refinement Its proof follows by direct useof Definition 7 and Lemma 6
Lemma 7 For C1 and C2 two Modal Interfaces the follow-ing two properties are equivalent(i) MC2
sube MC1and EC2
supe EC1 meaning that contract C2
refines contract C1 following the meta-theory(ii) [C2] [C1] ie [C2] refines contract [C1] in the sense of
modal refinementThe conjunction of two Modal Interfaces is thus the GreatestLower Bound (GLB) with respect to refinement order Itscomputation proceeds in two steps In a first step we wildlyenforce the GLB and compute a pre-conjunction by takingunion of must sets and intersection of may sets
Definition 9 The pre-conjunction43 C1andC2 of two ModalInterfaces is only defined if Σin
1 = Σin2 and Σout
1 = Σout2
43Pre-conjunction was originally denoted by the symbol amp in [164] [167][166]
and is given by Σin = Σin1 Σout = Σout
1 Q = Q1timesQ2q0 = (q10 q20) and its two transition relations are given by
must(q1 q2) = must1(q1) cupmust2(q2)may(q1 q2) = may1(q1) capmay2(q2)
(26)
Due to (26) C1andC2 may involve inconsistent states and thusin a second step the pruning introduced in Lemma 6 must beapplied
C1 and C2 = [C1andC2] (27)
Say that the two Modal Interfaces C1 and C2 are consistent44
if C1 and C2 is consistent in the sense of Lemma 6Parallel composition and quotient For Modal Interfaces
we are able to define both parallel composition and quotient inthe sense of the meta-theory As it was the case for InterfaceAutomata parallel composition for Modal Interfaces raisescompatibility issues and thus a two-step procedure is againfollowed for its computation
Definition 10 The pre-composition C1otimesC2 of two ModalInterfaces is only defined if Σout
1 capΣout2 = empty and is given by
Σout = Σout1 cup Σout
2 Q = Q1timesQ2 q0 = (q10 q20) and itstwo transition relations are given by
must(q1 q2) = must1(q1) capmust2(q2)may(q1 q2) = may1(q1) capmay2(q2)
(28)
Say that a state (q1 q2) of C1otimesC2 is illegal if
may1(q1) cap Σin2 6sube must2(q2)
or may2(q2) cap Σin1 6sube must1(q1)
Illegal states are pruned away from C1otimesC2 as follows Removefrom Cmay
1 times Cmay2 all transitions leading to (q1 q2) As
performing this may create new illegal states the same isrepeated until fixpoint is reached As a final step we delete thestates that are not may-reachable This finally yields C1otimesC2which no more possesses illegal states
The above construction is justified by the following resultLemma 8 C1otimesC2 as defined in Definition 10 instantiates
the contract composition from the meta-theory
Proof (sketch) E is an environment for C iff for any reachablestate (qE q1 q2) of E times Cmay
1 times Cmay2 we have
rs(qE ) sube must1(q1) capmust2(q2) (29)
where rs(q) the ready set of state q is the subset of actionsα such that q αminusrarr holds Let M1 be any implementation ofC1 and consider EtimesM1 We need to prove that EtimesM1 is anenvironment for C2 ie satisfies Condition 2 of Definition 7(we must also prove the symmetric property) Let (qE q1 q2)be a reachable state of EtimesM1timesCmay
2 We must prove
rs(qE ) cap rsM1 (q1 ) cap Σ in2 sube must2(q2)
By (29) it suffices that the following property holds
rsM1(q1 ) cap Σ in
2 sube must2(q2) (30)
44This is the usual wording in the literature
RR ndeg 8147
Contracts for System Design 37
However we only know that rsM1(q1 ) sube may1 (q1 ) Hence
to guarantee (30) we must prune away illegal pairs of statesTo this end we use the same procedure as before we makestate (q1 q2) unreachable in Cmay
1 timesCmay2 by removing all may
transitions leading to that state We complete the reasoning aswe did for the study of consistency 2
Definition 11 The quotient C1C2 of two modal interfacesC1 and C2 is only defined if Σin
1 cap Σout2 = empty and is defined
according to the following two steps procedure First defineC as follows Σout = Σout
1 Σout2 Q = Q1 times Q2 q0 =
(q10 q20) and its two transition relations are given by
must(q1 q2) = must1(q1)
may(q1 q2) = not [may1(q1) cap notmust1(q1)] cupnot [must1(q1) capmust2(q2)] cupnot [may1(q1) cupmay2(q2)]
These formulas may give raise to inconsistent states and thusin a second step we set C1C2 = [C]This definition is justified by the following result [166]showing that Definition 11 instantiates the meta-theory
Lemma 9 C1 otimes C2 C if and only if C2 CC1
Now it may be that (C1C2)otimesC2 possess illegal pairs of states(Definition 10) whence the following improvement whereΣout and Σin are as in Definition 11 and may and mustrefer to the quotient C1C2
Definition 12 Let Cprime be the interface defined on the samestate structure as C1C2 with however the following modali-ties
may prime(q1 q2) = may(q1 q2) cap(may2(q2) cup Σin
)must prime(q1 q2) = must(q1 q2) cup (Σout
1 cap Σout2 capmay2(q2))
define the compatible quotient written C1C2 to be thereduction of Cprime C1C2 = [Cprime]
This construction is justified by the following result
Lemma 10 The compatible quotient C1C2 solves thefollowing problem
max
C∣∣∣∣∣∣C has no inconsistent stateC otimes C2 has no illegal pair of statesC otimes C2 C1
Proof Denote C = C1C2 the compatible quotient definedabove The proof is threefold (i) C is proved to be a solutionof the inequality CotimesC2 C1 (ii) C is proved to be compatiblewith C2 and (iii) every Cprime satisfying the two conditions aboveis proved to be a refinement of C
Remark that reachable states in (C1C2)otimesC2 are of the form(q1 q2 q2) and that for every reachable state pair (q1 q2) inC1C2 state (q1 q2 q2) is reachable in (C1C2)otimes C2
(i) Remark that may prime sube may and must prime supe must HenceC1C2 C1C2 Since the parallel composition is monotonic(C1C2)otimes C2 (C1C2)otimes C2 C1
(ii) For every state (q1 q2 q2) reachable in (C1C2)otimes C2one among the following three cases occurs
bull Assume e isin Σin1 meaning that e is an input for both C2
and C1C2 Hence state (q1 q2 q2) is not illegal becauseof e
bull Assume e isin Σout1 cap Σout
2 Therefore e is an input of thecompatible quotient Remark must prime(q1 q2) sube may2(q2)Hence state (q1 q2 q2) is not illegal because of e
bull Assume e isin Σout1 capΣin
2 meaning that e is an output of thecompatible quotient Remark may prime(q1 q2) sube must2(q2)Therefore state (q1 q2 q2) is not illegal because of e
(iii) Let Cprimeprime be a modal interface such that C1C2 Cprimeprime C1C2 We shall prove that either Cprimeprime C1C2 or that Cprimeprime is notcompatible with C2 Remark that every reachable state (q1 q2)of C1C2 is related to exactly one state qprimeprime of Cprimeprime by the twomodal refinement relations Assume that Cprimeprime is not a refinementof C1C2 meaning that there exists related states (q1 q2)and qprimeprime such that may prime(q1 q2) sube may primeprime(qprimeprime) sube may(q1 q2)and must prime(q1 q2) supe must primeprime(qprimeprime) supe must(q1 q2) and eithermay prime(q1 q2) ( may primeprime(qprimeprime) or must prime(q1 q2) ) must primeprime(qprimeprime)Remark e isin Σin
1 implies that e isin may prime(q1 q2) iff e isinmay(q1 q2) and that e isin must prime(q1 q2) iff e isin must(q1 q2)Therefore the case e isin Σin
1 does not have to be considered
1) Assume there exists e such that e isin may primeprime(qprimeprime) may prime(q1 q2) Remark this implies e isin Σout
1 cap Σin2
meaning that e is an output of the compatible quo-tient Remark also that e 6isin must2(q2) Therefore state(qprimeprime q2) is illegal in Cprimeprime otimes C2
2) Assume there exists e such that e isin must prime(q1 q2) must primeprime(qprimeprime) Remark this implies e isin Σout
1 cap Σout2
meaning that e is an input of the compatible quotientRemark also that e isin may2(q2) Therefore state (qprimeprime q2)is illegal in Cprimeprime otimes C2
2
D Modal Interfaces with variable alphabet
As a general principle every relation or operator introducedin Section VIII-C (for Modal Interfaces with a fixed alphabetΣ) is extended to the case of variable alphabets by 1) extendingand equalizing alphabets and then 2) applying the relations oroperators of Section VIII-C to the resulting Modal InterfacesFor all frameworks we studied so far alphabet extension wasperformed using inverse projections see Section VII-C Forinstance this is the procedure used in defining the compositionof io-automata extending alphabets in io-automata is byadding at each state and for each added action a self-loop labeled with this action The very reason for using thismechanism is that it is neutral for the composition in thefollowing sense it leaves the companion io-automaton freeto perform any wanted local action
So for Modal Interfaces what would be a neutral procedurefor extending alphabets Indeed considering (26) or (28)
RR ndeg 8147
Contracts for System Design 38
yields two different answers namely
for (26)
α isin may1(q1) and α isin whatever2(q2)dArr
α isin whatever(q1 q2)
for (28)
α isin must1(q1) and α isin whatever2(q2)dArr
α isin whatever(q1 q2)
where ldquowhateverrdquo denotes either may or must Consequentlyneutral alphabet extension is by adding
bull may self-loops for the conjunction andbull must self-loops for the composition
The bottom line is that we need different extension proceduresThese observations explain why alphabet extension is properlyhandled neither by Interface Automata (see the last paragraphof Section VIII-B) nor by AG-contracts (see the end ofSection VII-C) These theories do not offer enough flexibilityfor ensuring neutral extension for all relations or operators
We now list how alphabet extension must be performed foreach relation or operator for two Modal Interfaces C1 and C2(the reader is referred to [166] for justifications) Alphabetsare extended as follows where Σprime supe Σ Define the strongextension of C to Σprime written CuarrΣprime
as follows
CuarrΣprime
(Σin)uarrΣprime
= Σin cup (Σprime Σ)
(Σout)uarrΣprime
= Σout
QuarrΣprime
= Q
quarrΣprime
0 = q0
mayuarrΣprime
= may cup (Σprime Σ)
mustuarrΣprime
= must cup (Σprime Σ)
(31)
In (31) the added may and must transitions are all self-loopsThe weak extension of C written CuArrΣprime
is defined using thesame formulas with the only following modification
CuArrΣprime
=
mustuArrΣprime= must
(32)
Observe that the strong extension uses the classical inverseprojection everywhere The weak extension however proceedsdifferently with the must transitions in that it forbids the legalenvironments to submit additional actions as its outputs
Using weak and strong alphabet equalization the relationsand operations introduced in Section VIII-C extend to variablealphabets as indicated now In the following formulas (ΣΣprime)is a pair such that Σ sube Σprime and (Σ1Σ2Σ) denotes a triplesuch that Σ = Σ1 cup Σ2 and satisfying the typing constraints
Σini = Σin cap Σi and Σout
i = Σout cap Σi for i = 1 2
It is understood that contract C has alphabet Σ and so on
Theorem 1 The following relations and operators
M prime |=M C = M prime |=M CuArrΣprime
Eprime |=E C = Eprime |=E CuarrΣprime
C1 C2 = C1 CuArrΣ2
C1 and C2 = CuArrΣ1 and CuArrΣ
2
C1 otimes C2 = CuarrΣ1 otimes CuarrΣ2
C1C2 = CuArrΣ1 CuarrΣ2
(33)
instantiate the meta-theory
Proof The first two formulas just provide definitions so noproof is needed for them Their purpose is to characterizethe weakly and strongly extended Modal Interfaces in termsof their sets of environments and implementations For bothextensions allowed output actions of the implementations areaugmented whereas mandatory actions are not For the weakextension legal environments are not modified in that noadditional output action is allowed for them In contrast for thestrong extension legal environments are allowed to submit anyadditional output action These observations justify the otherformulas 2
E Projecting and Restricting
A difficult step in the management of contracts was illus-trated in Figure 4 of Section IV-D It consists in decomposinga contract C into a composition of sub-contractsotimes
iisinI Ci C (34)
where sub-contract Ci has alphabet Σi = Σini ] Σout
i As aprerequisite to (34) the designer has to guess some topologicalarchitecture by decomposing the alphabet of actions of C as
Σ =⋃iisinI Σi Σi = Σin
i ] Σouti (35)
such that composability conditions regarding inputs and out-puts hold Guessing architectural decomposition (35) relies onthe designerrsquos understanding of the system and how it shouldnaturally decomposemdashthis typically is the world of SysMLFinding decomposition (34) is however technically difficultin that it involves behaviors It is particularly difficult if Cis itself a conjunction of viewpoints or requirements whichtypically occurs in requirements engineering see Section XI
C =andkisinK Ck (36)
The algorithmic means we develop in the remaining part ofthis section will be instrumental in solving (34) They will beused in the Parking Garage example of Section XI
Projecting over a subalphabet Projecting a contract overa sub-alphabet is the first natural tool for consideration Itis the dual operation with respect to alphabet extension thatwas developed in Section VIII-D Two projections can bedefined which can be seen as under- and over-approximationsrespectively by referring to the refinement order
RR ndeg 8147
Contracts for System Design 39
Let C be a Modal Interface with alphabet Σ = Σin cup Σout
and let Σprime sub Σ be a sub-alphabet Define respectively theabstracted projection and refined projection
CdarrΣprime= min Cprime | ΣCprime = Σprime and Cprime C
CdArrΣprime= max Cprime | ΣCprime = Σprime and Cprime C
(37)
where ldquominrdquo and ldquomaxrdquo refer to refinement order for ModalInterfaces with different alphabets see (33) The projectionCdArrΣprime
(respectively CdarrΣprime) is computed via the following on-
the-fly algorithm 1) Perform ε-closure on the set of states byconsidering unobservable the actions not belonging to Σprime andthen 2) Perform determinization by giving priority to mustover may (respectively to may over must) see Table VI fordetails Step 2) of the procedure for computing CdArrΣprime
is apossible source of inconsistencies
The abstracted projection CdarrΣprimeprovides a projected view
of a system-level contract over a small subset of actionsThe abstracted projection is thus a useful tool for contractexploration and debug It is not a synthesis tool however
This is in contrast to the refined projection CdArrΣprime which
satisfies the following result For any finite set Ci | i isin Iof Modal Interfaces with respective alphabets Σi we haveassuming that the left and right hand sides are properlydefinedmdasha typing property on input and output alphabetsotimes
iisinI
[Ci and
(andkisinK C
dArrΣi
k
)]
andkisinK Ck (38)
To show this by symmetry it is enough to show (38) withthe conjunction on the right hand side replaced by any singleCk for k selected from finite set K For any i isin I we haveCdArrΣi
k Ck and thus
Cprimei =def
[Ci and
(andkisinK C
dArrΣi
k
)] Ck (39)
holds for every i from which (38) follows Unfortunately therefined projection quite often gives raise to inconsistenciesIn addition the contract composition arising in left hand sideof (38) is subject to incompatibilities Informally said thistechnique works if the sub-systems are only ldquoloosely coupledrdquoso that neither inconsistencies nor incompatibilities occur Tomitigate this problem we propose an alternative technique forturning a conjunction into a composition
Restricting to a sub-alphabet Let C be a Modal Interfacewith alphabet Σ = Σin cup Σout and let (ΣprimeinΣprimeout) be twoinput and output sub-alphabets such that Σprimeout sube Σout SetΣprime = Σprimein]Σprimeout and define the restriction of C to Σprime denotedby CdarrΣprime via the procedure shown in see Table VII comparewith Table VI Observe that the states of the restriction cor-respond to sets of states of the original Modal Interface Therestriction aims at avoiding incompatibilities when consideringthe composition as the following lemma shows
Lemma 11 If C and CdarrΣprime are both consistent then so istheir compatible quotient CCdarrΣprime see Definition 12Proof Consider two alphabets Σ supe Σprime and a consistent C onalphabet Σ such that CdarrΣprime is also consistent The only casewhere quotient produces inconsistent states is whenever there
input CΣΣprime output Cprime
let proj(OpX) =if X has not been visitedthen
1 mark X visited2 for every α isin Σprime do
21 let Y = ε-closure(Σminus Σprime next(αX))22 let m = OpmC(q α) | q isin X23 add to Cprime a transition (Xα Y ) with modality m24 proj(Op Y )
done
let project(Op C) =1 let X0 = ε-closure(Σminus Σprime q0)2 set initial state of Cprime to X0
3 proj(OpX0)4 reduce Cprime5 return Cprime
let order (cannot maymustle) =
must le may
cannot le may
in CdarrΣprime= project(or C)
CdArrΣprime= project(and C)
Table VIALGORITHM FOR COMPUTING THE PROJECTIONS (37)
input CΣinΣoutΣprimeinΣprimeout output Cprime
let order(cannot maymustlein) = cannot lein may lein must
order(cannot maymustleout) =
must le may
cannot le mayin let rest(X) =
if X has not been visitedthen
1 mark X visited2 for every α isin Σprime do
21 let Y = ε-closure(Σminus Σprime next(αX))22 let m = OpmC(q α) | q isin X
where Op = if α isin Σprimein then orin else andout
23 add to Cprime a transition (Xα Y ) with modality m24 rest(Op Y )
done
let restrict(C) =1 let X0 = ε-closure(Σminus Σprime q0)2 set initial state of Cprime to X0
3 rest(OpX0)4 reduce Cprime5 return Cprime
Table VIIALGORITHM FOR COMPUTING THE RESTRICTION CdarrΣprime
exists an action e and a state pair (qR) in CCdarrΣprime such thate has modality must in q and does not have modality mustin R We prove by contradiction that no such reachable statepair (qR) and action e exist Remark that by definition of therestriction q isin R The restriction is assumed to be in reducedform meaning that it does not contain inconsistent states Twocases have to be considered
1) Action e has modality cannot in R Several sub-caseshave to be considered depending on the IO status ofe and on the fact that the reduction of the restrictionhas turned a may modality for e into a cannot In allcases action e has modality cannot or may in q which
RR ndeg 8147
Contracts for System Design 40
contradicts the assumption2) Action e has modality may in R This implies that e also
has modality may in q which contradicts the assumptionThis finishes the proof of the lemma 2
The following holds by Lemma 10
CdarrΣprime otimes (CCdarrΣprime ) CCCdarrΣprime has no inconsistent state
(CdarrΣprime CCdarrΣprime ) has no incompatible pair of states(40)
By Lemma 11 the only property for checking is the consis-tency of CdarrΣprime This is a significant improvement comparedto the issues raised by the refined projection as explained inthe paragraph following (39) Decomposition (40) can be usedwhile sub-contracting through the following algorithm
Algorithm 1 We are given some system-level contract CThe top-level designer guesses some topological architectureaccording to (35) Then she recursively decomposes
C = C0 C0darrΣ1otimes C1
C0darrΣ1otimes C1darrΣ2
otimes C2 C0darrΣ1
otimes otimes Cnminus1darrΣn
=def C(Σ1) otimes otimes C(Σn)
(41)
which ultimately yields a refinement of C by a compatiblecomposition of local sub-contracts 2
Discussion The operations of projection and restrictionthat we introduced here can probably be made be genericat the level of the meta-theory Observe however that suchoperations explicitly refer to the notion of sub-alphabet whichdoes not exist at the level of the meta-theory In additionModal Interfaces are the only concrete theory in which variablealphabets are properly supported For these two reasons wepreferred to develop these operations for Modal Interfacesonly
F Observers
Here we develop observers for a Modal InterfaceC = (ΣinΣout Q q0rarr 99K) having no inconsistent statemeaning that rarrsube99K With this consistency assumption inforce observers are then obtained as follows with referenceto Definition 2bull Condition 2 of Definition 7 boils down to requiring thatE times Cmust simulates E Simulation testing can thus beused to check this call bE
C(E) the corresponding verdictbull To test for implementations we first construct the max-
imal environment EC and apply testing to check sim-ulation of EC times M by Cmay call bM
C1 the corre-sponding verdict Performing this requires maintainingpairs of states ((qE qM ) (qE q)) in simulation relation(qE qM )le(qE q) For any such pair of states let bM
C2 de-note the verdict answering whether (qE qM )
αminusrarrECtimesMholds each time q αminusrarr holds for any α isin Σout Theoverall verdict for implementation testing is then
bMC1(EC timesM) and bM
C2(EC timesM)
Lemma 3 for generic observers specializes to the followingeffective semi-decision procedure
Lemma 121) If bE
C outputs F then C is incompatible2) If bM
C1 and bMC2 outputs F then C is inconsistent
G Bibliographical note
As explained in [72] [56] [127] [83] [165] [166] Inter-face Theories make no explicit distinction between assump-tions and guarantees
Interface Automata variants and extensions InterfaceAutomata were proposed by de Alfaro and Henzinger [72][70] [5] [54] as a candidate theory of interfaces In thesereferences Interface Automata focused primarily on parallelcomposition and compatibility Quoting [72]
ldquoTwo interfaces can be composed and are compatibleif there is at least one environment where they canwork togetherrdquo
The idea is that the resulting composition exposes as aninterface the needed information to ensure that incompatiblepairs of states cannot be reached This can be achieved byusing the possibility for a component to refuse selectedinputs from the environment at a given state [72] [56] Incontrast to our development in Section VIII-B no sets ofenvironments and implementations are formally associated toan Interface Automaton in the original developments of theconcept A refinement relation for Interface Automata wasdefined in [72]mdashwith the same definition as oursmdashit couldnot however be expressed in terms of sets of implementationsProperties of interfaces are described in game-based logicseg ATL [9] with a theoretical high-cost complexity Theoriginal semantics of an Interface Automaton was given by atwo-player game between an input player that represents theenvironment (the moves are the input actions) and an outputplayer that represents the component itself (the moves are theoutput actions) Despite the availability of partial results [83]the framework of Interface Automata lacks support for theconjunction of interfaces in a general setting and does notoffer the flexibility of modalities Sociable Interfaces [71]combine the approach presented in the previous paragraphwith interface automata [72] [73] by enabling communicationvia shared variables and actions45 First the same actioncan appear as a label of both input and output transitionsSecondly global variables do not belong to any specificinterface and can thus be updated by multiple interfaces Con-sequently communication and synchronization can be one-to-one one-to-many many-to-one and many-to-many Symbolicalgorithms for checking the compatibility and refinement ofsociable interfaces have been implemented in TICC [3]Software Interfaces were proposed in [55] as a pushdownextension of interface automata (which are finite state) Push-down interfaces are needed to model call-return stacks ofpossibly recursive software components This paper contains
45This formalism is thus not purely synchronous and is mentioned in thissection with a slight abuse
RR ndeg 8147
Contracts for System Design 41
also a comprehensive interface description of Tiny OS46 anoperating system for sensor networks Moore machines andrelated reactive synchronous formalisms are very well suitedto embedded systems modeling Extending interface theoriesto a reactive synchronous semantics is therefore meaningfulSeveral contributions have been made in this direction startingwith Moore and Bidirectional Interfaces [56] In Moore Inter-faces each variable is either an input or an output and thisstatus does not change in time Bidirectional Interfaces offeradded flexibility by allowing variables to change IO statusdepending on the local state of the interface Communicationby shared variable is thus supported and for instance allowsdistributed protocols or shared buses to be modeled In bothformalisms two interfaces are deemed compatible wheneverno variable is an output of both interfaces at the same timeand every legal valuation of the output variables of oneinterface satisfies the input predicate of the other The mainresult of the paper is that parallel composition of compatibleinterfaces is monotonic with respect to refinement Note thatMoore and Bidirectional Interfaces force a delay of at leastone transition between causally dependent input and outputvariables exactly like Moore machines In [83] the frame-work of Synchronous Interfaces is enriched with a notion ofconjunction (called shared refinement) This development wasfurther elaborated in [78] In Moore interfaces legal values ofthe input variables and consequent legal values of the outputvariables are not causally related Synchronous Relational In-terfaces [177] [178] have been proposed to capture functionalrelations between the inputs and the outputs associated toa component More precisely inputoutput relations betweenvariables are expressed as first-order logic formulas over theinput and output variables Two types of composition are thenconsidered connection and feedback Given two relationalinterfaces C1 and C2 the first one consists in connecting someof the output variables of C1 to some of the input variablesof C2 whereas feedback composition allows one to connectan output variable of an interface to one of its own inputsThe developed theory supports refinement compatibility andalso conjunction The recent work [112] studies conditions thatneed to be imposed on interface models in order to enforceindependent implementability with respect to conjunctionFinally [53] develops the concept of simulation distancesfor interfaces thereby taking robustness issues into accountby tolerating errors Finally Web services Interfaces wereproposed in [38]
The discussion of variants and extensions related to timeresources and probability is deferred to corresponding sec-tions
Modal Interfaces variants and extensions Propertiesexpressed as sets of traces can only specify what is forbiddenUnless time is explicitly invoked in such properties it isnot possible to express mandatory behaviors for designsModalities were proposed by Kim Larsen [130] [11] [46] asa simple and elegant framework to express both allowed and
46httpwwwtinyosnet
mandatory properties Modal Specifications basically consist inassigning a modality may or must to each possible transition ofa system They have been first studied in a process-algebraiccontext [130] [125] in order to allow for loose specificationsof systems Since then they have been considered for automata[128] and formal languages [163] [164] and applied to a widerange of application domains (see [11] for a complete survey)Informally a must transition is available in every componentthat realizes the modal specification while a may transitionneeds not be A modal specification thus represents a set ofmodelsmdashunfortunately models of modal transition systems areoften call ldquoimplementationsrdquo in the literature which is unfor-tunate in our context We prefer keeping the term ldquomodelrdquoand reserve the term ldquoimplementationrdquo for the entities intro-duced in Sections VIII-B and VIII-C Modal Specificationsoffer built-in conjunction of specifications [129] [167] Theexpressiveness of Modal Specifications has been characterizedas a strict fragment of the Hennessy-Milner logic in [46]and also as a strict fragment of the mu-calculus in [89] Theformalism is rich enough to specify safety properties as well asrestricted forms of liveness properties Modal Interfaces withthe right notion of compatibility were introduced in [165][166] and the problem of alphabet equalization with weakand strong alphabet extensions was first correctly addressed inthe same references In [23] compatibility notions for ModalInterfaces with the passing of internal actions are definedContrary to the approach reviewed before a pessimistic viewof compatibility is followed in [23] ie two Modal Interfacesare only compatible if incompatibility between two interfacescan occur in any environment A verification tool called MIOWorkbench is available The quotient of Modal Specificationswas studied in [124] [164] Determinism plays a role in themodal theory Non-deterministic Modal Interfaces have pos-sibly non-deterministic io-automata as class of componentsThey are much more difficult to study than deterministic onesand corresponding computational procedures are of highercomplexity A Modal Interface is said to be deterministic if itsmay-transition relation is deterministic For nondeterministicModal Interfaces modal refinement is incomplete [128] thereare nondeterministic Modal Interfaces C1 and C2 for whichthe set of implementations of C1 is included in that of C2without C1 being a modal refinement of C2 Hence refinementaccording to the meta-theory is not exactly instantiated butonly approximated in a sound way A decision procedure forimplementation inclusion of nondeterministic Modal Interfacesdoes exist but turns out to be EXPTIME-complete [12] [25]whereas the problem is PTIME-complete if determinism isassumed [167] [26] The benefits of the determinism assump-tion in terms of complexity for various decision problemson modal specifications is underlined in [26] The ldquomergerdquoof non-deterministic Modal Specifications regarded as partialmodels has been considered in [179] This operation consistsin looking for common refinements of initial specifications andis thus similar to the conjunction operation presented hereIn [179] [90] algorithms to compute the maximal commonrefinements (which are not unique when non-determinism is
RR ndeg 8147
Contracts for System Design 42
allowed) are proposed They are implemented in the toolMTSA [82] Assumeguarantee contracts viewed as pairs ofModal Specifications were proposed in [96] It thus com-bines the flexibility offered by the clean separation betweenassumptions and guarantees and the benefits of a modalframework Several operations are then studied refinementparallel composition conjunction and priority of aspects Thislast operation composes aspects in a hierarchical order suchthat in case of inconsistency an aspects of higher priorityoverrides a lower-priority contract The synthesis of ModalInterfaces from higher-level specifications has been studiedfor the case of scenarios In [173] Existential Live SequenceCharts are translated into Modal Specifications hence provid-ing a mean to specify modal contracts Regarding extensionsAcceptance Interfaces were proposed by J-B Raclet [163][164] Informally an Acceptance Interface consists of a set ofstates with for each state a set of ready sets where a readyset is a set of possible outgoing transitions from that stateIn intuitive terms an Acceptance Interface explicitly specifiesits set of possible models Acceptance Interfaces are moreexpressive than Modal Interfaces but at the price of a pro-hibitive complexity for the various relations and operators ofthe theory Modal Interfaces have been enhanced with markedstates by Caillaud and Raclet [27] Having marked statessignificantly improves expressiveness It is possible to specifythat some state must be reachable in any implementation whileleaving the particular path for reaching it unspecified As anexample of use Modal Interfaces with marked states have beenapplied in [4] to the separate compilation of multiple clockedsynchronous programs
The discussion of variants and extensions related to timeresources and probability is deferred to corresponding sec-tions
Features of our presentation The presentation of in-terface theories in this paper is new in many aspects Forthe first time all interface theories are clearly cast in theabstract framework of contracts following our meta-theory Inparticular the association to an interface C of the two sets ECandMC is new It clarifies a number of concepts In particularthe interface theories inherit from the properties of the meta-theory without the need for specific proofs The projectionand restriction operators for Modal Interfaces are new Castinginterface theories into the meta-theory was developed for thebasic interface theories only It would be useful to extend thisto the different variants and see what the benefit would beBenoicirct Caillaud has developed the MICA tool [49] whichimplements Modal Interfaces with all the operations andservices discussed in this section
IX PANORAMA TIMED INTERFACE THEORIES
In this section we develop an instance of an interface theoryfor timed systems This section is meant to be illustrative ofour approach to concrete instances of contract theories It doesnot claim to expose the good instance Our presentation buildson top of [35] To simplify the exposure we restrict ourselves
to the case of a fixed alphabet Σ As usual now we begin withthe component model
A Components as Event-Clock Automata
Timed Automata [6] constitute the basic model for systemsdealing with time and built on top of automata In wordstimed automata are automata enhanced with clocks Predicateson clocks guard both the states (also called ldquolocationsrdquo) andthe transitions Actions are attached to transitions that resultin the resetting of some of the clocks
Event-Clock Automata [7] [8] [35] form a subclass oftimed automata where clock resets are not arbitrary eachaction α comes with a clock hα which is reset exactlywhen action α occurs The interest of this subclass is thatevent-clock automata are determinizable which facilitates thedevelopment of a (modal) theory of contracts The definitionof event-clock automata requires some prerequisites
We are given an underlying finite set H of clocks A clockvaluation is a map ν H 7rarr R+ where R+ denotes the set ofnonnegative reals The set of all clock valuations is denotedby V We denote by 0 the clock valuation assigning 0 to allclocks and by ν + t the clock obtained by augmenting ν withthe constant t For ν a valuation the valuation ν[0hα] assigns0 to hα and keeps the valuation of other clocks unchanged
Clocks can be used to define guards The class of guardsconsidered by [35] consists of finite conjunctions of expres-sions of the form h sim n where h is a clock n is an integerand sim is one of the following relations ltle=ge gt Forg a guard write ν |= g to mean that valuation ν satisfiesguard g For N an integer G(H N) denotes the set of allguards over H involving only integers n lt N + 1 and wewrite G(H) = G(Hinfin)
Definition 13 An event-clock automaton over alphabet Σis a tuple M = (ΣinΣout Q q0 Nrarr) wherebull ΣinΣout Q q0 are as for io-automata elements of Q
are called locationsbull HΣ = hα | α isin Σ is the set of clocksbull N is a finite integer and rarrsube Q times G(HΣ N) times Σ times Q
is the transition relation write qgαminusrarr qprime to mean that
(q g α qprime) isinrarr
The semantics of M is a timed transition system with infinitestate space QtimesV defined as follows transition q
gαminusrarr qprime canfire from state (q ν) isin Q times V iff ν |= g as a result of thisfiring the clock hα is reset to zero thus resulting in the newstate (qprime ν[0hα]) isin Q times V In our Timed Interface theorycomponents are event-clock automata that are
1) deterministic in the following sense
forall(q α ν) isin Qtimes Σtimes V there is at mostone transition q
gαminusrarr qprime such that ν |= g(42)
2) receptive meaning that
forallq isin Qforallα isin Σin qTαminusrarr
holds where T denotes the trivial guard ldquotruerdquo
RR ndeg 8147
Contracts for System Design 43
Instead of further developing our theory we will show how totake advantage of previously developed theories by showingthat event-clock automata are finitely encoded by means of re-gion automata that we introduce next Fix bound N A regionis an equivalence class ϑ of clock valuations ν satisfying thesame set of guards from G(H N) Denote by Θ the set of allsuch regions (bound N is understood) For ϑ isin Θ consider
τ(ϑ) = ϑprimeprime | existνprimeprime isin ϑprimeprimeexistν isin ϑexistt ge 0 st νprimeprime = ν + t
which is the set of all regions that can be obtained from ϑ byletting time elapse Finally for ϑ a region and α an actionϑdarrα is the region obtained from ϑ by resetting clock hα Usingthese notations we associate to each event-clock automatonM = (ΣinΣout Q q0 Nrarr) a Region Automaton which isthe following finite state automaton
R [M ] =(Σin timesΘΣout timesΘ QtimesΘ (q00)rArr
)(43)
where the transition relation rArr is given by
(q ϑ)ϑrdquoα
===rArr (qprime ϑprime) iff
q gαrarr qprime withϑrdquo sube τ(ϑ) cap g andϑprime = ϑrdquodarrα
(44)
Vice-versa any Region Automaton R defines a uniqueevent-clock automaton M [R] by deducing from (44) theminimal guards associated to its transitions Starting from anevent-clock automaton M M [R [M ]] is related to M by astrengthening of its guards However it holds that47
R [M [R [M ]]] = R [M ] (45)
Under the above correspondence components in theevent-clock automaton domain are mapped to components inthe io-automaton domain
B Modal Event-Clock Specifications
In this section we develop the framework of con-tracts on top of our component model of deterministicevent-clock automata To simplify we only develop the caseof a fixed alphabet Σ
Definition 14 A Modal Event-Clock Specification (MECS)is a tuple C = (ΣinΣout Q q0rarr 99K) where ΣinΣoutQ q0 are as in Interface Automata and
rarr sube 99K sube Qtimes G(HΣ)times ΣtimesQ
Using the same construction as above MECS C induces aRegion Modal Event-Clock Specification (RMECS) denoted byR [C] which is a Modal Interface according to Definition 7Accordingly R [C] defines a pair (ER[C]
MR[C]) of sets of
io-automata and we finally define
(EC MC ) =def
(M[ER[C]
]M[MR[C]
])The map C 7rarr R [C] satisfies48
R [M [R [C]]] = R [C] (46)
47It is shown in [35] that M 7rarr R [M ] forms a Galois connection48Again it is a Galois connection [35]
This allows us to lift the contract theory of RMECS (whichare Modal Interfaces) to a contract theory of MECS Whilethis is conceptually elegant it is not efficient since movingfrom MECS to RMECS (from timed models to region models)is ExpTime which is costly To cope with this difficulty theauthors of [35] have provided direct cheap formulas expressedin the MECS domain These formulas provide a partial answerto the issue of complexity In particular the following lemmaholds that was stated and proved in [35]
Lemma 13 For C1 and C2 two MECS having identical inputand output alphabets define C1andC2 symbolically with rules ofthe following form
Glbmay q1
g1α99K qprime1 and q2
g2α99K qprime2
(q1 q2)g1andg2α99K (qprime1 q
prime2)
Glbmustleft q1
g1αrarr qprime1 and q2g2α qprime2
(q1 q2)g1andg2αrarr (qprime1 q
prime2)
where denotes ad libitumrarr or 99K and with Glbmustright
defined symmetrically (see [35] for the complete set of rules)Then we have
R [C1andC2] = R [C1]andR [C2] (47)
Inconsistent states for both sides of (47) correspond A similarlemma holds for contract quotient C1C2 Unfortunately thepruning of inconsistent states cannot be performed directlyin the MECS domain and mapping to regions is mandatoryNevertheless dedicated rules to handle directly inconsistentstates exist in the symbolic versions of the different relationsand operations on MECS As a result the computation ofthe regions is only mandatory when the designer aims atcleaning its contract by pruning the inconsistencies A similarlemma holds for contract composition C1otimesC2 Again pruningincompatible pairs of states cannot be performed directly inthe MECS domain and mapping to regions is mandatory49
C Bibliographical note
This note focuses on interface types of framework Thereader is referrect to the bibliographical note of Section VII-Gfor extensions of AG-contracts addressing time
A first interface theory able to capture the timing aspectsof components is Timed Interfaces [74] Timed Interfacesallows specifying both the timing of the inputs a componentexpects from its environment and the timing of the outputsit can produce Compatibility of two timed interfaces is thendefined and refers to the existence of an environment such thattiming expectations can be met The Timed Interface theoryproposed in [68] fills a gap in the work introduced in [74]by defining a refinement operation In particular it is shownthat compatibility is preserved by refinement This theoryalso proposes a conjunction and a quotient operation and is
49Authors of [35] do not mention this fact for the following reason Theydo not consider the issue of receptiveness for components and therefore theissue of compatibility does not arise
RR ndeg 8147
Contracts for System Design 44
implemented in the tool ECDAR [69] Timed SpecificationTheories are revisited from a linear-time perspective in [60]
The first timed extension of modal transition systems waspublished in [52] It is essentially a timed (and modal) versionof the Calculus of Communicating Systems (by Milner) Basedon regions tool support for refinement checking were imple-mented and made available in the tool EPSILON [95] Anothertimed extension of Modal Specifications was proposed in [36]In this formalism transitions are equipped with a modality anda guard on the component clocks very much like in timedautomata For the subclass of modal event-clock automataan entire algebra with refinement conjunction product andquotient has been developed in [33] [34]
Resources other than time were also consideredmdashwithenergy as the main target Resource Interfaces [57] can beused to enrich a variety of interface formalisms (InterfaceAutomata [72] AssumeGuarantee Interfaces [73] etc) witha resource consumption aspect Based on a two player game-theoretic presentation of interfaces Resource Interfaces allowfor the quantitative specification of resource consumptionWith this formalism it is possible to decide whether compo-sitions of interfaces exceed a given resource usage thresholdwhile providing a service expressed either with Buumlchi condi-tions or thanks to quantitative rewards Because resource usageand rewards are explicit rather then being defined implicitlyas solutions of numerical constraints this formalism doesnot allow one to reason about the variability of resourceconsumption across a set of logically correct models
X PANORAMA PROBABILISTIC INTERFACE THEORIES
Probabilistic systems are non-deterministic systems inwhich choice is controlled by random trial Such systems areuseful for many purposes ranging from physical or biologicalsystems to security protocols intrusion detection and up tosafety and reliability analyses in system design In this sectionas another illustration of our meta-theory we develop a simpleinstance of a probabilistic interface theory Again to simplifythe exposure we restrict ourselves to the case of a fixedalphabet Σ
A Components as Probabilistic Automata
We first introduce Probabilistic Automata with inputs andoutputs also called InputOutput Markov Decision Processesand then we motivate their use in safety analysis
Definition 15 A Probabilistic Automaton with inputs andoutputs (io-PA) is a tuple M = (ΣinΣout Q q0Πrarr)wherebull Σin and Σout are disjoint finite input and output alpha-
bets such that Σin cup Σout = Σbull Q is a finite set of states and q0isinQ is the initial state
we denote by Π(Q) the finite set of all probabilities overQ also called the probabilistic states
bull rarr sube Qtimes ΣtimesΠ(Q) is the transition relation we writeq
αminusrarr π to mean (q α π) isinrarr and q αminusrarr if q αminusrarr πholds for some π
bull In addition we require M to be deterministic in thefollowing sense for any pair (q α) isin Q times Σ q αminusrarr πand q αminusrarr πprime implies π = πprime
A run σ of M starts from initial state q0 and then progressesby a sequence of steps of the form q
αminusrarr π 7rarr qprime wheresupplementary transitions π 7rarr qprime are drawn at random byselecting a successor state qprime isin Q according to probabilityπ A strategy consists in fixing a function ϕ Q rarr Σand using it to select the next action Once a strategy hasbeen fixed jumping from a probabilistic state to the next onegives raise to a time-invariant Markov Chain whose invariantprobability can be computed or statistically estimated Whenall probabilistic states are Dirac measures δqprime selecting qprime asa next state with probability one io-PA M boils down to anio-automaton Thus io-PA subsume io-automata
Two io-PA M1 and M2 are composable if Σout1 capΣout
2 = emptyTwo composable io-PA M1 and M2 compose into M = M1timesM2 as follows
(q1 q2)αminusrarrM π1 otimes π2 iff
q1
αminusrarrM1π1 and
q2αminusrarrM2
π2(48)
where otimes denotes the product of two probabilities thus makingthe two components independent Parallel composition definedin this way has all the desired properties
Similarly the concept of simulation relation is easily de-rived from that of io-automata by preserving probabilitiesfor Mi i = 1 2 two io-PA and two states qi isin Qi say that q1
simulates q2 written q2le q1 if there exists a surjective mapf Q1 7rarr Q2 such that
forallα st q2αminusrarr2 π2 existπ1 isin Π(Q1)
dArr (49) q1αminusrarr1 π1
π2(qprime2) =sumf(qprime1)=qprime2
π1(qprime1)
π1(qprime1) gt 0rArr f(qprime1) le qprime1
Observe that since we consider only deterministic io-PAthere exists at most one π2 such that q2
αminusrarr2 π2 hence thereis no need to quantify over π2 in the precondition of (49) Inprobability theory relation π2(qprime2) =
sumf(qprime1)=qprime2
π1(qprime1) writesπ2 = f(π1) Say that M1 simulates M2 written M2leM1 ifq20leq10 Simulation relation is preserved by composition IfM2leM1 then every strategy ϕ2 Q2 7rarr Σ2 defined over M2
has its counterpart into a matching strategy ϕ1 Q1 7rarr Σ1
over M1 by setting ϕ1(q1) = ϕ2(f(q1)) For i = 1 2 letΩi = QN
i be the set of all sequences of states of Qi and let(ΩiPi) i = 1 2 be the two resulting probability spaces whenmatching strategies are used for M1 and M2 Then the mapf induces a measurable map ψ = (f f ) Ω1 7rarr Ω2 suchthat
intZ(ω2)dP2(ω2) =
intZ(ψ(ω1))dP1(ω1) In particular
the probability distributions with respect to P1 and P2 of anymeasurable function depending only on the successive actionsperformed are identical
The natural use of io-PAs for safetyreliability analysis isto capture faulty situations through states Component states
RR ndeg 8147
Contracts for System Design 45
are partitioned into safe states and faulty states that can beequipped with different fault labels (names of states can dothis no semantic adaptation is needed) The probabilistic partof io-PAs naturally captures the spontaneous occurrence offaults When in a faulty state a component outputs actionsthat can either be used to model fault propagation or maybe alarms for use in system supervision Input actions in afaulty state can be used to either model denial of servicefrom other components (thus resulting in a risk of movingto a faulty state) or may be reconfiguration actions Thusspontaneous occurrence of failures with fault propagation iscaptured by this framework To summarize io-PAs offer anatural framework in which to combine functional and safetyviewpoints
B Simple Modal Probabilistic Interfaces
By following the same steps as for Modal Interfacessee Definition 7 we can define Simple Modal ProbabilisticInterfaces as pairs C = (Cmay Cmust) of io-PAs There is nonew difficulty in doing this Expressiveness of this frameworkhowever is modest whence the attribute ldquosimplerdquo When usedin the context of safetyreliability analysis Simple ModalProbabilistic Interfaces support the specification of fault ac-commodation in systems For example one can specify abouta componentbull that it does not accommodate denial of service inputs
representing fault propagation are disallowed (ldquomust notoccurrdquo)
bull that it must be prepared to possible denial of serviceinputs representing fault propagation are allowed (ldquomustbe acceptedrdquo)
bull that it never generates spontaneous failures actions lead-ing to a probabilistic state from which a faulty state can beimmediately reached are disallowed (ldquomust not occurrdquo)
bull that spontaneous failures are unavoidable actions leadingto a probabilistic state from which a faulty state can beimmediately reached are allowed (ldquomust be acceptedrdquo)
One could argue that io-PA by themselves offer a similarexpressiveness by playing with probabilities Simple ModalProbabilistic Interfaces however offer the full algebra ofcontracts which io-PA donrsquot
C Bibliographical note
This note focuses on interface types of framework Thereader is referred to the bibliographical note of Section VII-Gfor extensions of AG-contracts addressing probability
Exactly like the Interval Markov Chain (IMC) for-malism [116] they generalize Constraint Markov Chains(CMC) [50] are abstractions of a (possibly infinite) sets ofDiscrete Time Markov Chains Instead of assigning a fixedprobability to each transition transition probabilities are keptsymbolic and defined as solutions of a set of first orderformulas Variability across implementations is made possiblenot only with symbolic transition probabilities but also thanksto the labelling of each state by a set of valuations or setsof atomic propositions This allows CMCs to be composed
thanks to a conjunction and a product operators While theexistence of a residuation operator remains an open problemCMCs form an interface theory in which satisfaction andrefinement are decidable and compositions can be computedusing quantifier elimination algorithms In particular CMCswith polynomial constraints form the least class of CMCsclosed under all composition operators Abstract ProbabilisticAutomata (APA) [79] is another specification algebra withsatisfaction and refinement relations product and conjunctioncomposition operators Despite the fact that APAs generalizeCMCs by introducing a labeled modal transition relationdeterministic APAs and CMCs coincide under the mild as-sumption that states are labeled by a single valuation Forboth formalisms parallel composition is restricted to non-interacting components since alphabets of actions must bedisjoint
Our formalism of Simple Modal Probabilistic Interfaces ex-hibits the whole contract algebra Regarding limitations unlikeIMC CMC and APA this model does not allow for specifyingfamilies of transition probabilities and hence it cannot helpfor quantitative reasoning about reliability analysis
XI THE PARKING GARAGE AN EXAMPLE INREQUIREMENTS ENGINEERING
In this section we develop the parking garage exampleintroduced in Section IV-C Some of the material is repeatedfor better readability Despite being simple and small this ex-ample quickly becomes complex for reasons that are intrinsicto the formal management of requirements The MICA tooldeveloped by Benoicirct Caillaud was used to develop it [49]
Requirements are written in constrained English languageand then translated into Modal Interfacesmdashwhile the pre-sented translation is manual automatic translation can beenvisioned50 Once this is completed contracts are formallydefined and the apparatus of contracts can be used In par-ticular important properties regarding certification can beformally defined and checked eg consistency compatibilitycorrectness and completeness In addition support is providedfor turning top-level requirements into an architecture of sub-systems each one equipped with its own requirements Thelatter can then be submitted to independent suppliers forfurther development
A The contract framework
We shall use Modal Interfaces (with variable alphabet) asdeveloped in Sections VIII-C and subsequent ones There arethree main reasons for this choice
1) By offering the may and must modalities Modal Inter-faces are well suited to express mandatory and optionalbehaviors in the specification which we consider impor-tant for requirements engineering
50In fact the contract specification languages proposed in the projectsSPEEDS [29] and CESAR (httpwwwcesarprojecteu) are examples oftranslations from a constrained English language to a formal models ofcontracts similar to Modal Interfaces
RR ndeg 8147
Contracts for System Design 46
2) Being large sets of requirements structured into chaptersrequirements documents are a very fragmented style ofspecification Only Modal Interfaces offer the neededsupport for an accurate translation of concepts such asldquoset of requirementsrdquo ldquoset of chaptersrdquo together with aqualification of who is responsible for each requirement(the considered component or sub-system versus itsenvironment)
3) As we shall see at the top-level conjunction prevailsHowever as soon as the designer refines the top-levelrequirements into an architecture of sub-systems com-position enters the game Turning a conjunction of top-level requirements into a composition of sub-systemsspecifications thus becomes a central task Only ModalInterfaces provide significant assistance for this
Overall the problem considered in claim 3) can be stated asfollows The designer begins with some system-level contractC which is typically specified as a conjunction of viewpointsandor requirements The designer guesses some topologicalarchitecture by decomposing the alphabet of actions of C as
Σ =⋃iisinI Σi Σi = Σin
i ] Σouti (50)
such that composability conditions regarding inputs and out-puts hold Once this is done we expect our contract frameworkto provide help in generating a decomposition of C asotimes
iisinI Ci C (51)
where sub-contract Ci has alphabet Σi = Σini ] Σout
i Guess-ing architectural decomposition (50) relies on the designerrsquosunderstanding of the system and how it should naturallydecomposemdashthis typically is the world of SysML Findingdecomposition (51) is however technically difficult in that itinvolves behaviors The algorithmic means that were presentedin Section VIII-E provide the due answer In this ParkingGarage example we will use both the abstracted projectionand the restriction that were developed in that section
B Top level requirements
In this section we begin with the top-level requirementsThe system under specification is a parking garage subjectto payment by the user At its most abstract level the re-quirements document comprises the different chapters gatepayment and supervisor see Table VIII The gate chapterwill collect the generic requirements regarding entry and exitgates These generic requirements will then be specialized forentry and exit gates respectively
0
gate_close
1gate_opengate_close
vehicle_passgate_open
Figure 7 Requirement Rg1 specified as an io-automaton Prefix ldquordquoindicates an input and prefix ldquordquo indicates an output
gateRg1ldquovehicles shall not pass when gate is closedrdquo see Fig 7Rg2 after vehicle_pass vehicle_pass is forbiddenRg3 after gate_open gate_open is forbidden and
after gate_close gate_close is forbiddenpaymentsupervisor
Table VIIITHE TOP-LEVEL SPECIFICATION WITH CHAPTER gate EXPANDED
REQUIREMENTS WRITTEN IN italics ARE ASSUMPTIONS UNDER WHICHgate SHOULD OPERATE
Focus on the ldquogaterdquo chapter It consists of the three re-quirements shown on Table VIII Requirement Rg1 is bestdescribed by means of an io-automaton shown in Figure 7mdashwe provide an informal textual explanation for it betweenquotes51 The other two requirements are written using con-strained natural language which can be seen as a boilerplatestyle of specification Prefix ldquordquo indicates an input and prefixldquordquo indicates an output
The first two requirements are not under the responsibilityof the system since they rather concern the car driver Thus itdoes not make sense to include them as part of the guaranteesoffered by the system Should we remove them This wouldbe problematic If drivers behave the wrong way unexpectedthings can occur for sure The conclusion is that 1) we shouldkeep requirements Rg1 and Rg2 and 2) we should handlethem differently than Rg3 which is a guarantee offered by thesystem Indeed Rg1 and Rg2 are assumptions under whichthe gate operates as guaranteed In the sequel assumptions arewritten in italics
So far we have specified gate as a list of requirementsRequirement Rg1 specified as an io-automaton can be con-sidered formal Requirements Rg2 and Rg3 are formulatedin constrained natural language and are ready for subsequentformalization eg as io-automata Are we done Not yetWe need to give a formal meaning to what it means to havea collection of requirements and what it means to distinguishassumptions from guarantees The contract framework wedevelop next will provide support for this
C Formalizing requirements as contracts
We shall use Modal Interfaces (with variable alphabet) asdeveloped in Sections VIII-C and subsequent ones Thuswe first need to explain how the specification of ldquogaterdquo inTable VIII translates into Modal Interfaces
We first observe that each requirement Rgj of Table VIIIis a sentence that can be formalized as an io-automaton see
51 We take the convention that the variables of the resulting io-automatonare those mentioned in the text of the requirement Some adjustment is neededto this convention however as exemplified by Figure 7 Suppose that somerequirement says ldquogate_open never occursrdquo This is translated by havingno mention of gate_open in the corresponding io-automaton To expressthis ldquonegativerdquo fact we must keep track of the fact that gate_open belongsto the alphabet of actions of the io-automaton Thus when performing thetranslation the explicit list of inputs and outputs should be explicitly givenTo avoid such additional notational burden we have cheated by omitting thisunless necessary
RR ndeg 8147
Contracts for System Design 47
Figure 7 for such a formalization of requirement Rg1 Ac-cordingly each chapter D = gatepaymentsupervisorof Table VIII is structured as a pair
D = ((A1 Am) (G1 Gn)) (52)
where the Ais (the assumptions) and the Gjs (the guarantees)are io-automata in which all involved actions possess thesame status (input or output) throughout all Ais and Gjs Thetranslation of a specification of the form (52) into a ModalInterface is performed by applying the following two series ofrules
Rules 1 We adopt the following rules for the translation ofguarantees (in the form of io-automata) into Modal InterfacesRG
1 Unless otherwise explicitly stated transitions labeledby an output action of the considered system are givena may modality the rationale for doing this is that thedefault semantics for guarantees is ldquobest effortrdquo A mustmodality is assigned if the requirement specifies itmdashegby having a ldquomustrdquo in the sentence
RG2 Transitions labeled by an input action of the considered
system are given a must modality the rationale for doingthis is that as part of its guarantees the component mustnot refuse an input that is ldquolegallyrdquo submitted by theenvironment
RG3 Guarantees in a same requirements chapter D combine
by conjunctionApplying Rules 1 to the set of guarantees of D yields thecontract encoding these guarantees denoted by GD 2
Performing this for the single guarantee Rg3 of gate yieldsthe Modal Interface shown in Figure 8
0 1gate_opengate_close
0 1gate_opengate_close
Figure 8 Translating the guarantee Rg3 of gate as an io-automaton (top)and then as a Modal Interface Ggate (bottom) using Rules 1
Rules 2 We adopt the following rules for the translationof assumptions (in the form of io-automata) into ModalInterfacesRA
1 We exchange the status inputoutput in every assump-tion thus taking the point of view of the environment
RA2 Having done this we apply Rules 1 to the assumptions
So far this yields a draft Modal Interface A that must besatisfied by every environment
RA3 This is not enough however as we really want envi-
ronments that submit all legal stimuli To ensure this wesimply turn in A all may transitions to must transitionswhich yields A
Applying Rules 2 to the set of assumptions of D yields theModal Interface AD encoding these assumptions 2
Performing this for the assumptions Rg1 and Rg2 of gateyields the Modal Interface shown in Figure 9
1 0
gate_close
1gate_opengate_close
gate_openvehicle_pass
2 0
gate_open
1vehicle_passgate_open
3 (11)
gate_close
(10)
gate_opengate_closevehicle_pass
gate_open
4 0
gate_close
1gate_openvehicle_passgate_close
gate_open
Figure 9 Translating the assumptions of gate as a Modal Interface Agate
using Rules 2 1 translation of Rg1 2 translation of Rg2 3 the resultingconjunction 4 the final result after applying rule RA
3 and renaming the states
So far we have represented any chapter D of the require-ments document as a pair of Modal Interfaces (AD GD) withmirroring inputoutput statuses for their actionsmdashevery inputof AD is an output of GD and vice-versa It is the merit ofModal Interfaces to allow for a direct representation of thispair of assumption and guarantee in the form of a single ModalInterface by using the following formula for A and G twoModal Interfaces with mirroring inputoutput statuses for theiractions
(AG) is represented by the quotient (AotimesG)A (53)
which is the contract characterizing the components thatimplement G in the context of A see Section V-E Performingthis for the whole chapter gate yields the Modal Interfaceshown in Figure 10 Some comments are in order regardingthis Modal Interfacebull Regarding the guarantees offered by the component
Allowed outputs possess a may modality which reflectsthat Guarantees specify what the component may deliverOther actions are forbidden
bull Regarding the context of operation Legal inputs to thegate (eg vehicle_through when exiting state ldquo1rdquo) havea must modality This complies with the intuition that
RR ndeg 8147
Contracts for System Design 48
gate(x) where x isinentry exitRg1(x) ldquovehicles shall not pass when x_gate is closedrdquo see Fig 7Rg2(x) after vehicle_pass vehicle_pass is forbiddenRg3 after x_gate_open x_gate_open is forbidden and after x_gate_close x_gate_close is forbidden
paymentRp1 ldquouser inserts a coin every time a ticket is inserted and only thenrdquo Fig omittedRp2 ldquouser may insert a ticket only initially or after an exit ticket has been issuedrdquo Fig omittedRp3 ldquoexit ticket is issued after ticket is inserted and payment is made and only thenrdquo Fig omitted
supervisorRg1(entry)Rg1(exit)Rg2(entry)Rg2(exit)Rs1 initially and after entry_gate close entry_gate open is forbiddenRs2 after ticket_issued entry_gate open must be enabledRs3 ldquoat most one ticket is issued per vehicle entering the parking and tickets can be issued only if requested
and ticket is issued only if the parking is not fullrdquo see Fig 12Rs4 ldquowhen the entry gate is closed the entry gate may not open unless a ticket has been issuedrdquo Fig omittedRs5 ldquothe entry gate must open when a ticket is issuedrdquo Fig omittedRs6 ldquoexit gate must open after an exit ticket is inserted and only thenrdquo Fig omittedRs7 ldquoexit gate closes only after vehicle has exited parkingrdquo Fig omitted
Table IXREQUIREMENTS FOR THE TOP-LEVEL
0
1vehicle_pass
2gate_open
vehicle_passgate_closegate_open
gate_close3vehicle_pass
gate_close
vehicle_pass
Figure 10 Chapter gate of the top-level requirements document translatedinto a Modal Interface Cgate
the component should not refuse legal stimuli from itsenvironment Violation of the contract by its environmentoccurs when an illegal input is submitted by the environ-ment (vehicle_through when exiting state 0 or state 3) Asa consequence the whole contract gets relaxed which isreflected by the move to the special state ldquo2rdquo from whichany action is allowedmdashsuch a state is often called a ldquotoprdquostate Note that this top state resulted from computing thequotient
The same procedure applies to all chapters gate paymentand supervisor of the top-level textual specification shownin Table IX (it is an expansion of Table VIII) In particu-lar the Modal Interfaces encoding chapters payment andsupervisor of the top-level are displayed in Figures 11 to 13Figure 13 showing the contract associated to the supervisor isunreadable and the reader may wonder why we decided to putit here We indeed wanted to show that when contract designis performed formally and carefully top-level contracts rapidlybecome complex even for modest sets of requirements So theformal management of requirements and their translation intoformal contracts must be tool-assisted
Finally the whole top-level contract C is the conjunctionof the contracts representing chapters gate payment and
supervisor of the top-level requirements document
C = Cgate and Cpayment and Csupervisor (54)
Owing to the complexity of Csupervisor shown in Figure 13we do not show the Modal Interface C formalizing the fulldocument Nevertheless the latter was generated and can thenbe exploited as we develop next The above specificationonly covers the functional viewpoint of the system Otherviewpoints might be of interest as well eg regarding timingbehavior and energy consumption They would be developedwith the same method and combined to the above contract Cusing conjunction
D Sub-contracting to suppliers
In this section we apply the technique developed in Sec-tion VIII-E for generating an architecture of sub-systems withtheir associated sets of requirements Each sub-system canthen be submitted for independent development to a differentsupplier
The duty of the designer is to specify an architecture ldquoagravela SysMLrdquo as shown on Figure 14 Some comments arein order regarding this architecture The considered instanceof a parking garage consists of one entry gate one exitgate and one payment machine Compare with the top-levelspecification of Table IX The latter comprises a generic gatea payment machine and a supervisor each one with its setof requirements In contrast the architecture of Figure 14involves no supervisor The supervisor is meant to be dis-tributed among the two gates The architecture of Figure 14seems to be very loosely coupled First the PaymentMachineseems to be totally independent In fact the ticket that isinserted in the exit gate must coincide with the one issued bythe PaymentMachine It turns out that this reflects a missingassumption regarding the environment of the system (namelythe user of the parking) Then the two gates seem to have the
RR ndeg 8147
Contracts for System Design 49
0 1ticket_insert_payment 2
coin_insert_paymentticket_insert_payment
3
coin_insert_payment
ticket_insert_paymentcoin_insert_paymentexit_ticket_issue
exit_ticket_issueticket_insert_paymentcoin_insert_payment
Figure 11 Chapter payment of the top-level requirements documenttranslated into a Modal Interface Cpayment
(a0)
vehicle_exit (b0)request_enter
(a1)vehicle_enter
request_entervehicle_exit
ticket_issue
vehicle_enter
vehicle_exit(b1)
request_enter
(a2)
vehicle_enter
vehicle_exitticket_issuerequest_enter
vehicle_enter
vehicle_exit
vehicle_enter
(b2)request_enter
vehicle_exit
vehicle_enter
request_enter
Figure 12 Modal Interface for Rs3
0
entry_gate_close
1
exit_ticket_insert
7
vehicle_entervehicle_exit
44
request_enter
entry_gate_closeexit_ticket_insert
2
exit_gate_open
vehicle_entervehicle_exit
43
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
3
request_enter
vehicle_enter
75
vehicle_exit
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
4
ticket_issue
vehicle_enter
72
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
vehicle_enter
5
vehicle_exit
11
entry_gate_open
exit_gate_openexit_ticket_insertexit_gate_closeentry_gate_closevehicle_enterentry_gate_openvehicle_exitrequest_enter
ticket_issue
vehicle_entervehicle_exit
exit_ticket_insertrequest_enter
6
exit_gate_open
8
exit_gate_close
59
entry_gate_open
vehicle_enter
vehicle_exit exit_ticket_insertrequest_enter
exit_gate_open
exit_gate_close
58
entry_gate_open
vehicle_entervehicle_exit
request_enter
9
exit_ticket_insert
45
entry_gate_open
exit_gate_open
vehicle_entervehicle_exitexit_ticket_insert
request_enter
10
entry_gate_open
vehicle_exit
entry_gate_openexit_ticket_insertrequest_enter
exit_gate_open
entry_gate_close
47
ticket_issue
68
vehicle_enter
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insertrequest_enter
12
ticket_issue
69
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
49
vehicle_enter
13
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
19
request_enter
77
entry_gate_open
50
vehicle_exit
vehicle_enter
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
20
entry_gate_open
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
21
ticket_issue
34
vehicle_enter
71
entry_gate_close
vehicle_exit
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
22
vehicle_enter
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
23request_enter
84
entry_gate_open
127
vehicle_exit
vehicle_enter
exit_ticket_insertrequest_enter
exit_gate_open
24
vehicle_exit
33
entry_gate_open
vehicle_entervehicle_exit
exit_ticket_insertrequest_enter
16
exit_gate_open
17
exit_gate_close
25
entry_gate_open
vehicle_enter
vehicle_exit
exit_gate_openexit_ticket_insertrequest_enter
exit_gate_close
26
entry_gate_open
vehicle_entervehicle_exit
request_enter
18
exit_ticket_insert
114
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
80
entry_gate_open
vehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
81ticket_issue
79
entry_gate_close
99
vehicle_enter
vehicle_exit
exit_gate_open
entry_gate_open
exit_ticket_insertrequest_enter
82vehicle_enter
vehicle_entervehicle_exitexit_gate_open
exit_ticket_insert
31
request_enter
83
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insertrequest_enter
32
entry_gate_open
vehicle_exitexit_ticket_insertrequest_enter
entry_gate_open
exit_gate_open
vehicle_enter
91
entry_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
vehicle_enter
92
entry_gate_close
vehicle_exit
vehicle_enter
exit_ticket_insertexit_gate_open
35
request_enter
101
entry_gate_close
entry_gate_open
60
vehicle_exit
vehicle_enter
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
36
vehicle_exit
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
37
exit_gate_open
125
exit_gate_close
93
entry_gate_close
entry_gate_open
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
exit_gate_open
38
vehicle_exit
exit_gate_close
94
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
39
exit_gate_open
40
exit_gate_close
entry_gate_close
entry_gate_open
vehicle_enter
ticket_issue
vehicle_exitexit_ticket_insertrequest_enter
exit_gate_open
exit_gate_close
entry_gate_open
73entry_gate_close
vehicle_entervehicle_exit
ticket_issue
request_enter
41
exit_ticket_insert
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
ticket_issue
entry_gate_open
exit_ticket_insertrequest_enter
42
exit_gate_open
entry_gate_close
entry_gate_close
ticket_issue
vehicle_enter
entry_gate_open
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
exit_gate_open vehicle_entervehicle_exit
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
exit_ticket_insert
entry_gate_close
request_enterentry_gate_open
46
ticket_issue
124
vehicle_enter
vehicle_exit
entry_gate_open
request_enter
exit_ticket_insert
126
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
48
vehicle_enter
vehicle_entervehicle_exit
exit_gate_open
request_enterexit_ticket_insert
113
entry_gate_open
vehicle_exit
request_enter
exit_ticket_insertentry_gate_open
exit_gate_open
105
entry_gate_close
vehicle_enter
request_enter
vehicle_enter
exit_ticket_insert
entry_gate_openexit_gate_open
56
vehicle_exit
74entry_gate_close
vehicle_exit
exit_ticket_insertentry_gate_open
57
exit_gate_open
entry_gate_close
123
exit_gate_close
vehicle_enter
request_enter
vehicle_exit
exit_ticket_insert
entry_gate_openexit_gate_open
request_enter
76
entry_gate_close
exit_gate_close
61
vehicle_enter
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
14
ticket_issue
entry_gate_close
vehicle_enter
vehicle_exit
exit_gate_closeentry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
15
vehicle_enter
vehicle_exit
vehicle_enter
request_enter
exit_gate_openexit_ticket_insert
vehicle_exit
86
entry_gate_open
exit_gate_close
vehicle_entervehicle_exit
request_enter
entry_gate_openexit_ticket_insert
51
exit_gate_open
52
exit_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit
exit_ticket_insertexit_gate_open exit_gate_close
vehicle_entervehicle_exit
request_enter
53
exit_ticket_insert
entry_gate_open
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
54
exit_gate_open
67entry_gate_open
request_enter
vehicle_enter
vehicle_exit
exit_ticket_insertexit_gate_open
55
entry_gate_open
entry_gate_close
request_enter
vehicle_exit
exit_ticket_insert
entry_gate_openexit_gate_open
vehicle_enter
vehicle_enter
entry_gate_open
exit_ticket_insertexit_gate_open
70
request_enter
62
vehicle_exit
entry_gate_close
vehicle_enter
ticket_issue
entry_gate_open
vehicle_exit
exit_ticket_insertrequest_enter
exit_gate_open
entry_gate_close
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_exit
vehicle_entervehicle_exit
ticket_issue
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_close
exit_gate_open
vehicle_enter
ticket_issue
exit_gate_close
vehicle_exit exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
entry_gate_open
exit_ticket_insert
63
exit_gate_open
64exit_gate_close
entry_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit exit_ticket_insertexit_gate_open
exit_gate_close
entry_gate_close
entry_gate_close
vehicle_entervehicle_exit
request_enter
65
exit_ticket_insert
entry_gate_open
entry_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
66exit_gate_open
entry_gate_open
entry_gate_close
vehicle_enter
request_enter
entry_gate_open
vehicle_exit
exit_ticket_insertexit_gate_open
entry_gate_close
vehicle_exit
request_enter
exit_gate_open
exit_ticket_insertentry_gate_open
vehicle_enter
vehicle_entervehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insert
78
request_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
ticket_issue
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
vehicle_enter
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
vehicle_exit
exit_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
exit_gate_close
vehicle_enter
request_enter
vehicle_exit
entry_gate_closeexit_gate_openexit_ticket_insert
entry_gate_close
vehicle_exit
request_enter
exit_ticket_insert
entry_gate_open
vehicle_enter
vehicle_entervehicle_exit
exit_ticket_insert
request_enter
104entry_gate_close
112entry_gate_open
vehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enter
95entry_gate_close
entry_gate_openvehicle_entervehicle_exit
ticket_issue
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
exit_ticket_insert
entry_gate_close
request_enterentry_gate_open
115
ticket_issue
98
vehicle_enter
vehicle_exit
exit_ticket_insert
entry_gate_open
request_enter
116
vehicle_enter
vehicle_entervehicle_exit
exit_ticket_insert
30
request_enter
107
entry_gate_open
vehicle_entervehicle_exit
exit_ticket_insert
request_enter97
entry_gate_open
vehicle_exit
exit_ticket_insert
request_enterentry_gate_open
vehicle_enter
96entry_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
89
request_enter
106
entry_gate_closeentry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_ticket_insert
90
request_enter
100
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
entry_gate_open
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
entry_gate_closeexit_ticket_insertrequest_enter
exit_gate_open
vehicle_enter
entry_gate_closeexit_gate_openexit_ticket_insertrequest_enter
vehicle_exit
vehicle_entervehicle_exit
ticket_issue
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_close
exit_gate_open
vehicle_enter
ticket_issue
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
exit_gate_open
vehicle_enter
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
102
vehicle_exit
vehicle_entervehicle_exit
request_enter
exit_ticket_insertentry_gate_close
103
exit_gate_open
exit_gate_close
vehicle_enter
vehicle_exit
request_enterexit_ticket_insert
entry_gate_closeexit_gate_open
exit_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enterentry_gate_close
vehicle_exit
request_entervehicle_enter
entry_gate_closeexit_ticket_insertentry_gate_open
exit_gate_open
request_enter
vehicle_enter
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insert
85
vehicle_exit
vehicle_exit
entry_gate_close
entry_gate_openexit_ticket_insert
exit_gate_open
request_enter
117
vehicle_enter
exit_gate_close
vehicle_exit
entry_gate_close
entry_gate_openexit_gate_openexit_ticket_insert
request_enter
87
vehicle_enter
exit_gate_close
exit_gate_close
entry_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
27
ticket_issue
vehicle_enter
vehicle_exit
exit_gate_close
entry_gate_open
exit_ticket_insertrequest_enter
exit_gate_open
28
vehicle_enter
vehicle_exit
vehicle_enter
exit_gate_close
exit_ticket_insertexit_gate_open
29request_enter
111
entry_gate_open
vehicle_exit
vehicle_enter
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
exit_gate_open
109
entry_gate_open
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_openexit_gate_open
vehicle_enter
108
entry_gate_close
vehicle_exit
vehicle_enter
exit_gate_close
exit_gate_openexit_ticket_insert
88
request_enter
vehicle_exit
110
entry_gate_close
entry_gate_open
vehicle_enter
vehicle_exit
entry_gate_open
exit_gate_openexit_ticket_insertrequest_enter
exit_gate_close
entry_gate_close
vehicle_entervehicle_exit
entry_gate_open
exit_ticket_insert
request_enter
entry_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enterentry_gate_close
vehicle_enter
vehicle_exit
exit_gate_close
exit_ticket_insertrequest_enter
entry_gate_closeexit_gate_open
vehicle_entervehicle_exit
request_enter
exit_gate_close
entry_gate_close
entry_gate_open
exit_ticket_insert
exit_gate_open
vehicle_enter
request_enter
vehicle_exit
exit_gate_close
entry_gate_close
entry_gate_open
exit_ticket_insertexit_gate_open
vehicle_enter
vehicle_exit
request_enter
exit_ticket_insert
entry_gate_closeexit_gate_open
exit_gate_close
vehicle_entervehicle_exit
exit_ticket_insert
request_enter
entry_gate_close
vehicle_exit
request_enter
vehicle_enterentry_gate_close
exit_ticket_insert
entry_gate_openexit_gate_open
exit_gate_close
vehicle_exit
request_enter
vehicle_enter
exit_ticket_insert
entry_gate_close
entry_gate_open
vehicle_exit
exit_gate_close
entry_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
128ticket_issue
vehicle_enter
vehicle_exit
exit_gate_close
exit_gate_open
entry_gate_open
exit_ticket_insertrequest_enter
129vehicle_enter
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insert
130
request_enter
122entry_gate_open
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
120
entry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insertrequest_enter
entry_gate_open
vehicle_enter
119entry_gate_close
vehicle_entervehicle_exit
exit_gate_close
exit_gate_open
exit_ticket_insert
118
request_enter
121
entry_gate_close
entry_gate_open
vehicle_entervehicle_exit
exit_gate_open
exit_gate_close
entry_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
exit_gate_closeexit_gate_open
exit_ticket_insertrequest_enter
entry_gate_close
vehicle_entervehicle_exit
exit_gate_open
exit_gate_close
request_enter
exit_ticket_insertentry_gate_close
vehicle_exit
exit_gate_open
exit_gate_close
request_enter
vehicle_enter
entry_gate_close
exit_ticket_insertentry_gate_open
vehicle_entervehicle_exit
request_enter
exit_gate_open
entry_gate_open
exit_ticket_insert
exit_gate_close
vehicle_entervehicle_exit
request_enter
exit_ticket_insert
entry_gate_open
vehicle_exit
exit_ticket_insert
request_enter
vehicle_enter
entry_gate_closeentry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
vehicle_enter
exit_ticket_insertrequest_enter
entry_gate_open
vehicle_exit
exit_gate_close
exit_gate_open
entry_gate_close
vehicle_enter
ticket_issue
exit_ticket_insertrequest_enter
entry_gate_open
Figure 13 Chapter supervisor of the top-level requirements documenttranslated into a Modal Interface Csupervisor for a capacity of two for theparking garage
shared input ldquovehicle exitrdquo as their only interaction But thisshared input is involved in requirement Rs3 which forbidsthe entry if the parking is full
In Figure 15 we show the result of applying to the ar-chitecture of Figure 14 the Algorithm 1 developed in Sec-tion VIII-E which yields by construction a refinement of thetop-level contract C by a decomposition into local contracts
C C(ΣEntryGate)otimes C(ΣExitGate)otimes C(ΣPaymentMachine)
(55)
Local contract C(ΣEntryGate) is the more complex one becauseit involves countingmdashwe have assumed a capacity of two tokeep it simple Remarkably enough the decomposition (55)involves small sub-systems compared to Csupervisor (Fig 13)and the global contract C the restriction operation is to beacknowledged for this strong reduction in size
E The four ldquoCrdquo
Requirements capture and management are important mat-ters for discussion with certification bodies These bodieswould typically assess a number of quality criteria from egthe following list elaborated by INCOSE [114] AccuracyAffordability Boundedness Class Complexity Completeness
request enter
ticket issue
entry gate open
entry gate closeEntryGate
vehicle enter
vehicle exit
exit ticket insert ExitGateexit gate open
exit gate close
ticket insert payment
coin insert paymentPaymentMachine exit ticket issue
Figure 14 System architecture as specified by the designer
0
vehicle_exit
1
request_enter
3
vehicle_enter
request_entervehicle_exit
2ticket_issue
vehicle_enter
request_entervehicle_exit
vehicle_enter
4
entry_gate_open
entry_gate_closeentry_gate_open
ticket_issuevehicle_enterrequest_entervehicle_exit
entry_gate_close
request_entervehicle_exit
5vehicle_enter
vehicle_enter
6
request_enter
15
entry_gate_close
16
vehicle_exit vehicle_enter
request_enter
7
vehicle_exit
8
entry_gate_close
entry_gate_closevehicle_enter
request_entervehicle_exit
vehicle_exit
vehicle_enter
request_enter
9ticket_issue
vehicle_exit
vehicle_enter
request_enter
10
entry_gate_open
vehicle_exit
entry_gate_closerequest_enter
11
vehicle_enter
vehicle_enter
vehicle_exit12
request_enter
14entry_gate_close
vehicle_enter
vehicle_exit
request_enter
13entry_gate_close
vehicle_enter
vehicle_exit request_enter
vehicle_enter
request_enter
vehicle_exit
vehicle_exit
vehicle_enter
request_enter
entry_gate_close
vehicle_enter
request_entervehicle_exit
0 1exit_ticket_insert
4
vehicle_exit
exit_ticket_insert
2
exit_gate_open
vehicle_exit
exit_ticket_insert
3vehicle_exitexit_gate_close
exit_ticket_insertvehicle_exit
exit_ticket_insertexit_gate_close
vehicle_exitexit_gate_open
0 1ticket_insert_payment 2
coin_insert_paymentticket_insert_payment
3
coin_insert_payment
ticket_insert_paymentcoin_insert_paymentexit_ticket_issue
exit_ticket_issueticket_insert_paymentcoin_insert_payment
Figure 15 The three restrictions of the global contract C for the three sub-systems EntryGate (top) ExitGate (mid) and PaymentMachine (bottom)
Conciseness Conformance Consistency Correctness Criti-cality Level Orthogonality Priority Risk Unambiguousnessand Verifiability In this section we focus on four quality crite-ria that are considered central by certification authorities andare relevant to contracts namely Completeness CorrectnessConsistency and Compatibility
1) Consistency amp Compatibility Consistency and compat-ibility have been formally defined in the meta-theory seeSection V and Table IV therein In particular those formaldefinitions can be formally checked Thus the question ariseswhether these formal definitions suitably reflect the commonsense meaning of these terms
According to the common meaning a set of requirementsis consistent if it is not self-contradicting The intent is thatthere is no point in trying to implement an inconsistent set ofrequirements as no such implementation is going to exist
RR ndeg 8147
Contracts for System Design 50
It turns out that the existence of implementations is theformal definition of consistency according to the meta-theoryClearly the formal definition of consistency meets its commonsense interpretation We illustrate consistency on the top-levelspecification of Table IX Referring to this table we havestrengthened Rs6 and Rs7 in some way Lack of consistencyis revealed by checking the mutual consistency of these tworequirements with the requirement Rg3 applied to the exitgate After the following scenario
exit_ticket_insertexit_gate_openexit_ticket_insert
event exit_gate_open has modality must in left-hand interfaceand modality cannot in right-hand interface
According to the common meaning an architecture of sub-systems as characterized by their respective specifications iscompatible if these sub-systems ldquomatch togetherrdquo in that theycan be composed and the resulting system can interact withthe environment as expectedmdashuse cases can be operated aswished As explained in Table IV of Section V this is theformal definition of compatibility in the meta-theory Againthe formal definition of compatibility meets its common senseinterpretation
2) Correctness Correctness can only be defined withreference to another specification We propose to translateldquocorrectnessrdquo by one of the following properties dependingon the case (see Table IV for the notations)bull ldquois a correct implementation ofrdquo written |=Mbull ldquois a correct environment ofrdquo written |=Ebull ldquorefinesrdquo written
3) Completeness Completeness raises a difficulty Al-though the term ldquocompletenessrdquo speaks for itself it cannotbe formally defined what it means to be complete for a top-level specification in the form of a set of requirements Thereason is that we lack a reference against which completenesscould be checked Hence the only way to inspect a top-level specification for completeness is to explore it manuallyThe best help for doing this is to execute the specificationThus specifications must be executable Fortunately ModalInterfaces are executable and this way undesirable behaviorscan be revealed We illustrate this on the top-level specificationof Table IX where Rs6 is changed into ldquoexit gate must openafter an exit ticket is insertedrdquo (by omitting ldquoand only thenrdquo)Lack of completeness is revealed by simulation The followingscenario can occur
exit_ticket_insertexit_gate_openvehicle_exitexit_gate_closeexit_gate_open
which allows vehicles to exit without having inserted an exitticket an unwanted behavior This reveals that the specificationwas not tight enough ie incomplete So far for completenessof the top-level specification
In contrast completeness can be formally defined whena reference C is available We propose to say that Cprime isincomplete with reference to C if
1) Cprime does not refine C but2) there exists Cprimeprime Cprime such that Cprimeprime is consistent and
compatible and refines CThe rationale for this definition is that Cprime is not precise enoughbut can be made so by adding some more requirementsNote that Cprime is incomplete with reference to C if and onlyif Cprime and C is consistent and compatible This criterion is ofparticular relevance when Cprime =
otimesiisinI Ci is an architecture of
sub-contracts where Ci is to be submitted to supplier i forindependent development
F Discussion
Requirements engineering is considered very difficult Re-quirements are typically numerous and very difficult to struc-ture Requirements concern all aspects of the system func-tion performance energy reliabilitysafety Hence systemsengineers generally use several frameworks when expressingrequirements The framework of contracts expressed as ModalInterfaces that we have proposed here improves the situationin a number of aspectsbull It encompasses a large part of the requirements52
bull It can accommodate different concrete formalisms Inour example we have blend textual requirements withrequirements specified as state machines Richer for-malisms such as Stateflow diagrams can be accom-modated in combination with abstract interpretationtechniquesmdashthis is not developed here
bull We have shown how to offer formal support to importantproperties such as the four Crsquos during the process ofcertification
bull We have proposed a correct-by-construction approach tothe difficult step of moving from the top-level specifi-cation in the form of a requirements document to anarchitecture of sub-contracts for the suppliers53
XII CONTRACTS IN THE CONTEXT OF AUTOSAR
In this section we use AUTOSAR as an industrial exampleof how to leverage contracts within an existing standard toextend it
A The AUTOSAR context
AUTOSAR54 is a world-wide development partnership in-cluding almost all players in the automotive domain electronics
52 According to figures that were given to us by industrials 70-80 of therequirements can be expressed using the style we have developed here Otherrequirements typically involve physical characteristics of the system or definethe range for some parameters
53 The framework of AssumeGuarantee contracts that is used in Section XIIdoes not offer this for two reasons First it lacks the quotient and secondlocal alphabets are not properly handled In contrast AssumeGuarantee con-tracts are very permissive in how they can be expressed In particular dataflowdiagrams (Simulink) can be used to express assumptions and guarantees
54httpwwwautosarorg
RR ndeg 8147
Contracts for System Design 51
supply chain It has been created with the purpose of de-veloping an open industry standard for automotive softwarearchitectures To achieve the technical goals of modularityscalability transferability and reusability of functions AU-TOSAR provides a common software infrastructure based onstandardized interfaces for the different layers The AUTOSARproject has focused on the objectives of location indepen-dence standardization of interfaces and portability of codeWhile these goals are undoubtedly of paramount importancetheir achievement may not be sufficient for improving thequality of software systems As for most other embeddedsystem car electronics is characterized by functional as well asnon functional properties assumptions and constraints [111]Therefore an AUTOSAR based development process benefitsfrom adding contracts as the this section will demonstrate
B The contract framework
Extensive use of SimulinkStateflow modeling is performedfor system design in the automobile sector It is thus naturalto try reusing this modeling style for defining contractsSince AG contracts of Section VII simply rely on specify-ing assertions regardless of how they are actually describedwe use AG contracts for this AUTOSAR case study SinceSimulinkStateflow diagrams are very flexible contracts canbe expressed for all viewpoints (function timing safety) Inturn reasoning on such contracts is beyond the capability ofautomatic tools Consequently checking for implementationand refinement relations will be performed manually on smallmodels In contrast the powerful contract algebra developedin the meta-theory is fully generic and does not depend onthe nature and complexity of the considered models Themodularity it offers will thus be the main help offered bycontract based design in this case study As another featureof this this study the distinction between ldquohorizontalrdquo andldquoverticalrdquo contracts is used see Section IV-D4 Finally thefollowing variation of AG contracts is used
Assertions consist of a timed extension of the weaklysynchronous model (18) namely
P sube ((Σ 7rarr D) cup R+)lowast cup ((Σ 7rarr D) cup R+)
ω (56)
meaning that the assertion proceeds by a succession of stepsconsisting of either assignment of values to variables (includ-ing the special status absent for multiple-clocked assertions)or time progress Composition is by intersection P1timesP2 =def
P1 and P2 with alphabet equalization by inverse projection asin see Section VII-C Following Section VII-B componentsare tuples M = (ΣinΣout P ) where Σ = Σin cup Σout is thedecomposition of alphabet Σ into its inputs and outputs andP is an assertion following (56) Components must be free ofexception in the sense of Definition 4
A contract is a tuple C = (ΣinΣoutAs AwG) whereΣ = Σin cup Σout is the decomposition of alphabet Σ intoits inputs and outputs As and Aw the strong and weakassumptions and G the guarantees are assertions over ΣThe set EC of the legal environments for C collects all com-ponents E such that E sube A The set MC of all components
implementing C is defined by (As andAw)timesM sube G meaningthat implementations guarantee G under the condition that theenvironment satisfies the stronger condition AsandAw In otherwords in this framework legal environments are constrainedby strong assumptions only whereas the conjunction of strongand weak assumptions is required to guarantee G Weakassumptions are useful for design iterations in case strictobligations for the context of use may not be realizable
To conclude on this framework its difference is onlymethodological since any contract with strong and weakassumptions C = (ΣinΣoutAs AwG) is equivalent to anordinary AG contract (ΣinΣoutAsG or notAw) Thus thereader is referred to Section VII Adding time to the paradigmdoes not change anything to the relations or operators definedin that section
However adding time results in decidability and complexityissues The latter problem can be fixed in part by usingobservers see Sections V-G and VII Other proofs can be car-ried on manuallymdashthis is feasible for undecidable propertieswhen the needed reasoning only involves a small part of theanalyzed system involving few locally interacting componentsThe added value of our contract framework is to supportthe combination of proofs into a validation for the overallsystem taking into account detailed design decisions capturedin system and ECU configurations
C Exterior Light Management System
To illustrate the benefits of contract-based systems engineer-ing in AUTOSAR we consider as an example an excerpt of anExterior Light Management for an automobile55 We focus onthe parts responsible for sensing driver inputs and actuatingthe rear direction indicator lights and brake lights With thisexample we show how requirements can be refined to contractsand discuss the added value of contracts for negotiationsbetween OEM and suppliers We will also illustrate the useof vertical contracts eg to specify the expected latency ofthe communication solution and computations from the timingviewpoint and a failure hypothesis in terms of reliability
1) Function and timing We begin our study by showinghow AUTOSAR models can be enhanced with contracts
System
ext_pedal
ext_lamp
ext_tssext_wls
ext_rlaext_rra
Figure 16 Virtual Functional Bus model
The Virtual Functional Bus model Figure 16 shows the Vir-tual Functional Bus (VFB) model encompassing the exteriorlights management This software composition specifies the
55A case-study from the German SPES2020 project
RR ndeg 8147
Contracts for System Design 52
interfaces exposed by the component to the sensors deliveringdriver inputs (brake pedal warn light button turn signallever) and to the actuators controlling the lights Ports witharrowheads denote an asynchronous data flow interface whichis a SenderReceiverInterface Here it is a special kind calledServiceInterface which means the data is provided by somelocal service located in the BasicSoftware stack of an ECU(Electronic Computing Unit) The requirements document ofthe system contains one timing-related requirementbull R1 If the driver presses the brake pedal the brake lights
must light not later than 25msWe formalize in Table X this requirement as a contract by
using a pattern-based contract specification language (terms inbold-face are keywords)
CR1
As whenever ext_pedal occursext_pedal does not occur during[ext_pedalext_lamp]ext_pedal occurs sporadicwith minperiod 25ms
Aw trueG delay between ext_pedal and
ext_lamp within [0ms25ms]
Table XHORIZONTAL CONTRACT OF VFB MODEL
Indicator
BrakePedalSensor PedalToLamp
TurnSwitchSensor
WarnLightsSensor
SwitchLightActuator
RearLeftActuator
RearRightActuator
BrakeLampActuator
ext_pedal
pos_pedal_out lamp_intensity ext_lamp
ext_tss
ext_wls
tss
wls
ext_rla
ext_rra
rla_signalrra_signal
emcyBrake
pos_pedal_in
Figure 17 Decomposed Virtual Functional Bus model
Decomposed VFB Software composition Figure 17 showsthe decomposed VFB model AssemblySwConnectors link theports of parts of the composition and are subject to commu-nication refinement The components used in the compositionand their functions are as followsbull BrakePedalSensor receives the position of the brake pedal
(ext_pedal) and distributes it to other components
bull PedalToLamp reads the brake pedal position (pos_pedal)and calculates requested brightness of the brake indicatorlights (lamp_intensity)
bull BrakeLampActuator reads the requested brightness of thebrake indicator lights (lamp_intensity) and actuates thebrake lamps accordingly (ext_lamp)
bull TurnSwitchSensor reads the position of the lever and for-wards it (tss)
bull WarnLightsSensor reads status of the warn blink button andforwards it (wls)
bull Indicator reads the status of the warn blink button the leverposition and cyclically toggles the left and right signals(rla_signal rra_signal)
bull Rear(Left|Right)Actuator reads its input signal ((rla|rra)_signal)and actuates the bulb (ext_(rla|rra))
bull SwitchLightActuator reads left and right signals((rla|rra)_signal) and provides feedback on the dashboard
Horizontal (functional) contracts associated to the VFBmodel For the decomposed VFB model we derive horizontalcontracts specifying the desired IO behavior of the parts Asan example for the component BrakePedalSensor we state thecontracts shown in Table XI Contract CfIOBPS
specifies that
CfIOBPS
Afs whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Afw true
Gf whenever ext_pedal occurspos_pedal_out occurs
CfSIGNALBPS
Afs whenever pos_pedal_out occurs
pos_pedal_out does not occur during[pos_pedal_outpos_pedal_in]
Afw true
Gf whenever pos_pedal_out occurspos_pedal_in occurs
Table XIA SAMPLE OF THE HORIZONTAL CONTRACTS OF THE DECOMPOSED VFB
MODEL SUPERSCRIPT f REFERS TO ldquoFUNCTIONrdquo
provided that the pedal is not ldquomultiply pressedrdquo then thepos_pedal message traverses the BrakePedalSensor and then thewire following it with some unspecified delay In particular nomessage is lost due to a miss by this block Similar contractsare stated for all blocks of the VFB model thus resultingin a set Cf
IO of contracts For all AssemblySwConnectors ofthe composition horizontal contracts are specified that aresimilar to that of CfSIGNALBPS
resulting in a set CfSIGNAL
of contracts This contract scheme guarantees a reliable datatransport by each wire of the VFB model no matter how thecommunication is refined
So far we have stated contracts for each block and eachwire of the VFB model Compose the above contracts usingcontract composition (14) ie compute
CfVFB =otimes(otimes
C | C isin CfIO)
otimes(otimesC | C isin Cf
SIGNAL) (57)
RR ndeg 8147
Contracts for System Design 53
The guarantee offered by overall contract CfVFB is the con-junction of the guarantees of the constitutive contracts Hencecontract CfVFB guarantees that messages reliably traverse theVFB model with however an unspecified delay On the otherhand contract composition (14) assumes the conjunction ofall assumptions stated for each blockmdashthe guarantee offeredby CfVFB and the strong assumption of CR1
discharge all ofthese assumptions
At this point we observe that contract CfVFB involves notiming characteristics and thus functional contract CfVFB doesnot refine the initial contract CR1 To overcome this timingcontracts are added in the next step that will complement thisfunctional contract with timing viewpoint based on expectedperformance characteristics of the computing platform
Budgeting time using contracts We now state additionalcontracts such as the ones shown in Table XII Observethat for those contracts weak assumptions are used see Sec-tion XII-B regarding the motivations for doing this Observealso that we repeated the functional strong assumption56
Again stating similar contracts for each block and wire of the
CtIOBPS
Ats whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Atw ext_pedal occurs sporadic
with minperiod 15msGt delay between ext_pedal and
pos_pedal_out within [0ms15ms]
CtSIGNALBPS
Ats whenever pos_pedal_out occurs
pos_pedal_out does not occur during[pos_pedal_outpos_pedal_in]
Atw pos_pedal_out occurs sporadic
with minperiod 2msGt delay between pos_pedal_out and
pos_pedal_in within [0ms2ms]
Table XIITIMING CONTRACT OF DECOMPOSED VFB MODEL SUPERSCRIPT t
INDICATES THAT THESE CONTRACTS DEAL WITH TIMING
VFB model yields two sets CtIO and Ct
SIGNAL of contractsand we consider
CtVFB =otimes
(otimesC | C isin Ct
IO)otimes(otimesC | C isin Ct
SIGNAL)(58)
The next step is to combine for each component (blockor wire) of the VFB model the two functional and timingviewpoints using conjunction ie to compute
CVFB =otimes(otimes[
Cf and Ct]| (Cf Ct) isin CIO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin CSIGNAL
) (59)
where CIO collects for each block the pair of functional andtiming contracts associated with it and similarly for CSIGNAL
56 If we do not do this then when taking the conjunction of functionaland timing contracts the functional strong assumption gets absorbed by thestrong assumption of the timing contract since the latter is equal to T Seethe discussion regarding AssumeGuarantee contracts with variable alphabetsat the end of Section VII-C
At this point we observe that the architecture of the VFBmodel is a directed acyclic graph
Consider the conjunction C = Cf and Ct = (AG) for eachblock or wire As an example focus on block IOBPS whichis the first block of VFB seen as a directed acyclic graphRegarding the combination of strong and weak assumptionswe have A = Afs and Atw which is weaker than As theassumption of CR1
in Table X Regarding guarantees we haveG = Gf and Gt which ensures that messages traverse thecomponent without duplication or loss and with a delay lessthan the ldquominperiodrdquo of the input signal (15ms) Also guar-antee G offered by this block is strong enough to dischargethe assumption of the next wire when performing contractcomposition Reproducing the same reasoning inductivelyalong all blocks and wires of the VFB model seen as an acyclicgraph shows that
CVFB CR1(60)
Consequently submitting the pairs of contracts (Cf Ct) asso-ciated to each component for separate development possiblyby different suppliers will ensure correct integration (providedimplementations by the suppliers are correct with respect totheir contracts) In particular the component BrakePedalSensorbelongs to the chassis domain and is implemented by adifferent supplier than the other components
Discussion The above step of our contract based designmethodology leads to the following important notices
1) So far our proof steps were all manual Our contractbased reasoning however was instrumental in ensuring thatelementary proof steps were combined correctly Reasoningbased on intuition when component composition and view-point combination both occur is very likely to lead to wrongconclusions There is a strong added value in contract basedreasoning even if elementary proof steps are manual
2) Manual reasoning can be complemented by the use ofobservers Again it is important that the use of observerswhen component composition and viewpoint combination bothoccur is performed correctly Our development in Section V-Gprovides the formal support for this For the pattern basedlanguage used here a framework for checking refinement ofcontracts using an observer based strategy is described in [94]
3) The responsibility of establishing the sub-contracts sub-mitted to the different suppliers is assigned to the OEM inaccordance with his role as integrator Components belongingto different domains of a car (engine chassis etc) are likely tooriginate from different vendorssuppliers By using our abovereasoning the OEM can decompose its contract specificationspassing them to supplier(s) For example the componentBrakePedalSensor is the only one in the VFB model that belongsto the chassis domain and other components are developed byone or more different suppliers Thus in decomposition (59)the two sets of contracts CIO and CSIGNAL are partitioned
RR ndeg 8147
Contracts for System Design 54
eg for subcontracting to two different suppliers
Csupplier1VFB =
otimes(otimes[Cf and Ct
]| (Cf Ct) isin C1
IO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin C1
SIGNAL
)Csupplier2VFB =
otimes(otimes[Cf and Ct
]| (Cf Ct) isin C2
IO
)otimes(otimes[Cf and Ct
]| (Cf Ct) isin C2
SIGNAL
)Each supplier can then safely develop its own sub-systemindependently We develop this in the next sub-section
Implementation of software components and vertical as-sumptions Each of the software components being part ofthe software system composition (cf Figure 17) is a Compo-sitionSoftwareComponents as this allows the supplier to reusealready designed components We thus consider one suchcomponent with its contract C = Cf and Ct consisting of thefunctional contract Cf in conjunction with the timing contractCt The supplier can then follow two different approaches fordeveloping this component
In a first approach the supplier reuses a composition
C =otimes
iisinI Ci (61)
of off-the-shelf components available from a library Twosituations can then occurbull The easy case is when refinement holds C C This
means that for C = (As Aw G) guarantees are strongenough and assumptions are weak enough to implyrefinement with respect to the contract C specified bythe OEM
bull A more realistic (but also more delicate) case is when thefollowing weaker relations are satisfied
C Cf (62)G sube G (63)
As and Aw supe Afs andAfw (64)
but the conditions requested on timing assumptions forrefinement C C to hold are not satisfied
As and Aw 6supe Ats andAtw (65)
Under (65) composition from library C cannot be usedas such It can however still be used as a valid imple-mentation provided that some additional missing verticalassumption regarding timing is stated such that
As and Aw supe Ats andAtw and Atw︸ ︷︷ ︸for negotiation
(66)
(66) requires a negotiation in which additional verticalassumption Atw is returned back to the OEM as an ad-ditional performance requirement for the ECU platformIf this is accepted by the OEM then development by thesupplier using off-the-shelf components from the library(61) can proceed
The alternative approach is to implement the componentEventually this results in a composition of AtomicSoftwareCom-ponents This component type has an internal behavior specifi-cation comprising so called Runnables which are the smallest
executable entities known to AUTOSAR For each runnableactivation conditions are defined by means of RTEEvents con-trolled by the RuntimeEnvironment on the corresponding ECUand data accesses referring ports of the owning component AnRTEEvent can be configured to occur either cyclically (time-triggered) or by the data arrival on some input port of theowning component (event-triggered)
Figure 18 depicts the internal behavior of componentBrakePedalSensor This component consists of a single
BrakePedalSensor
BPSRunnable
pos_pedal_out
P=10ms
ext_pedal
Figure 18 Internal behavior of BrakePedalSensor-component
CfIBBPS
Afs whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Afw true
Gf whenever ext_pedal occurspos_pedal_out occurs
CtIBBPS
Ats whenever ext_pedal occurs
ext_pedal does not occur during[ext_pedalpos_pedal_out]
Atw ext_pedal occurs sporadic
with minperiod 10msBPSRunnableact occurs each 10msdelay between BPSRunnableact andpos_pedal_out within [0ms10ms]
Gt delay between ext_pedal andpos_pedal_out within [0ms10ms + 10ms]
CprimetIBBPS
Aprimets whenever ext_pedal occursext_pedal does not occur during[ext_pedalpos_pedal_out]
Aprimetw ext_pedal occurs sporadicwith minperiod 10msBPSRunnableact occurs each 10msdelay between BPSRunnableact andpos_pedal_out within [0ms5ms]
Gprimet delay between ext_pedal andpos_pedal_out within [0ms10ms + 5ms]
Table XIIICONTRACTS FOR INTERNAL BEHAVIOR OF
BRAKEPEDALSENSOR-COMPONENT
runnable BPSRunnable which is activated cyclically with aperiod of 10ms Upon its activation it reads the sensorvalues from the ECU abstraction component and writes the
RR ndeg 8147
Contracts for System Design 55
position of the brake pedal on its provided SenderReceiverport The timing behavior of the component owning a time-triggered runnable can be characterized by the contract shownin Table XIII top
We now focus on the second situation in which the supplierwants to reuse components from a library to implementcontract C = CfIOBPS
and CtIOBPS We consider the case where
a component BrakePedalSensor has already been implementedand characterized by C = CfIBBPS
and CtIBBPSNow observe that
relation (62) holds However G 6sube G Taking a closer lookat Atw we see it assumes a worst case response time forBPSRunnable Thus the guarantee Gt can be strengthened ifweak assumption Atw is replaced by Aprimetw ensuring a shorterresponse time The supplier would then consider the con-tract Cprime = CfIBBPS
and CprimetIBBPS where the re-adjusted contract
CprimetIBBPScorresponds to assuming Aprimetw and guaranteeing Gprimet
For that modified contract relations (62ndash65) hold Howeverstrengthening an assumption is not a refinement Thereforeapplying this modification cannot be performed by the supplieron its own but rather requires negotiation with the OEM Ifthe OEM is willing to accept the stronger assumption Aprimetwthe component from the libary can be used and the modifiedcontract of the supplier is refined Cprime Cprimesupplier1
VFB The next process steps in the AUTOSAR methodology called
System configuration and ECU configuration define the targetarchitecture (ECUs and communication network) as well asthe deployment of the application software components onthat distributed architecture Thus satisfaction of the contractsspecified for the application needs to be verified for the givenarchitecture and deployment (cf IV-D4) We develop this inthe next two sub-sections
ECU configuration and vertical contracts During thefollowing discussion we assume that for each componentimplementation a contract similar to Cprime has been specifiedand possibly an associated Aprimetw has been negotiated Observethat Aprimetw may invalidate refinement of system requirements bythe VFB contract Consider the example above Aprimetw assumesan activation of BPSRunnable each 10ms and a worst caseresponse time less than 5ms This additional weak assumptionis now part of Cprimesupplier1
VFB However it is neither dischargedby any guarantee of CprimeVFB nor by the strong assumption ofCR1 Thus we need to verify that 1 all vertical assumptionscollected during previous steps are discharged during system-and ECU configuration and 2 all guarantees are met bysoftware components and connectors For both tasks state-of-the-art verification techniques can be used
As an example focus on the vertical assumption Aprimetw ofthe BrakePedalSensor-component and consider the ECU con-figuration depicted in Figure 19 The ECU hosts the twocomponents BrakePedalSensor and PedalToLamp of the VFBmodel57 These components are integrated with a layered basicsoftware stack on an ECU That stack consists of multipleBasicSoftwareModules (BSWM) Each of these modules has aset of standardized interfaces and is implemented by a set
57To simplify we omit port emcyBrake
RTE
BrakePedal
SensorPedalToLamp
BSW
COMOSt1 t2
Complex
Device
Driver
ext_pedal
pos_pedal_out
pos_pedal_in
lamp_intensity
isr
Figure 19 Extracting platform contracts from ECU configuration
of BswModuleEntities These are analogous to the Runnables ofapplication software components and are either executed by adedicated OS task or interrupt service routine Therefore weexpect BasicSoftwareModules to be characterized by contractsin a way similar to the internal behavior of applicationcomponents (cf contracts in Table XIII) In case a BSWM hasa BswModuleEntity that is not mapped to some task or interruptservice routine that entity is an ldquoordinaryrdquo function calledwithin the context of another BswModuleEntity or Runnable Inthe example ECU configuration two BSWMs are shown
bull A ComplexDeviceDriver which has direct access to thesensor of the ECU that detects position of the brake pedal
bull An AUTOSAR COM module and a CAN interface (notshown here)
The components and BSWMs own a single runnable eachbsw entity respectively The ECU configuration maps BP-SRunnable to task t1 of the operating system (OS) and PTL-Runnable to task t2 The BswModuleEntity of the ComplexDe-viceDriver is mapped to an interrupt service routine while theentity of the COM module is simply a function for sendinga signal That function is used by the AUTOSAR runtimeenvironment (RTE) to realize the communication specified onVFB-level by means of the connectors For each task of theOS the ECU configuration specifies at least its priority andwether it is preemptable The activation of a task is specifiedby linking an alarm of the OS to that task Those alarmscan also be configured to occur cyclically For each cyclicalarm we generate a contract PALARMi
with trivial strongand weak assumptions and as guarantee the cycle time ofthe alarm The example ECU configuration contains a singlealarm whose contract is listed in Table XIV top Furthermore
PALARM1
As trueAw trueG Alarmi occurs each 10ms
PBPSRunnable
As trueAw trueG delay between BPSRunnableact and
pos_pedal_out within [1ms4ms]
Table XIVPLATFORM CONTRACTS OBAINED BY ANALYSIS OF ECU CONFIGURATION
RR ndeg 8147
Contracts for System Design 56
we can extract from the AUTOSAR model of the componentimplementation a set of execution time specifications for eachRunnable owned by the component Again the same appliesto BswModuleEntities With this information we can create atask network and obtain response times for each Runnableand BswModuleEntity (if executed by some task or interruptservice routine) using tools like SymTAS58 or chronVAL59Afterwards we generate for each Runnable and BswModuleEntity(if executed by task or ISR) a contract PRunnablei
with stongand weak assumption T and as guarantee the reponse timeinterval determined by analysis For the ECU configurationsketched in Figure 19 BPSRunnable has a response time thatlies in the interval [1ms 4ms] resulting in the contract shownin Table XIV bottom Similar contracts are stated for all tasksand alarms extracted from the ECU configurations We thencompose these contracts and the contracts of the BSWMswhich yields the contract P characterizing the executionplatform Following the approach outlined in Section IV-D4we compose the VFB contract with the platform contract andcheck for refinement ie
CprimeVFB otimes P CprimeVFB (67)
The vertical assumption Aprimetw is discharged in the compositionof the VFB and platform contracts and refinement holdsFurthermore with Aprimetw being discharged refinement of thesystem requirement holds again
CprimeVFB otimes P CR1(68)
The approach outlined here to analyze the mapping of applica-tion software components and their associated contracts on anECU network by creating contracts from ECU configurationsand results of response time analysis has been implemented ina framework That framework includes a meta-model support-ing contract-based design and enables to 1 specify contractsfor components in foreign models and 2 check for refinementbetween contracts belonging to different models [24]
Inter-ECU communication During system configurationthe leaves of the hierarchical software composition calledAtomicSoftwareComponents are mapped to ECUs of the targetarchitecture Thus we know for each connector of the VFBmodel whether it must be implemented by the communicationnetwork interconnecting the ECUs
For both intra- and inter-ECU communication the designmust be verified against the corresponding contracts of theVFB model ie the set of contracts[
Cf and Ct] ∣∣ (Cf Ct) isin CSIGNAL
(69)
Again available analysis techniques can be used Suppose asignal from the VFB model is mapped to a frame transmittedon a CAN bus The OEM can then for each such contractuse the combination of strong and weak assumptions A =Afs and Atw as specification of the minimal inter-arrival timesof subsequent occurrences of the signal Taking into account
58httpwwwsymtavisioncomsymtashtml59httpwwwinchroncomchronvalhtml
the priority of each CAN frame given by its identifier theresponse time of each signal can be computed and comparedagainst the guarantee G = Gf andGt
If the communication network whose configuration is partof the AUTOSAR system configuration is successfully verifiedagainst the contracts defined in (69) deployment of the VFBmodel on the target architecture is correct with regard tothe VFB contract and the design fulfills the initial systemrequirement CR1
Discussion The above development highlights themethodological value of contracts for system design in AU-TOSAR context at later design stages First both contractconjunction and composition are used Then modificationsthat are not refinements are pinpointed which forces thesupplier to engage on a negotiation with the OEM regardingsystem specifications Without the solid support of contractsand its rules such kind of reasoning would be error prone
2) Safety The virtual function bus (VFB) concept wasintended to enable a distributed development of software com-ponents independently from the underlying hardware architec-ture The specification of the interfaces in the 3x releases didnot support the kind of non functional property necessary todevelop safety aspects of critical systems This fact lead to thedevelopment of the previously mentioned Timing Extensionand Safety Extension to Methodology and Templates Thesafety extension directly addresses the use of contracts forthe specification of safety relevant properties driven by theneed for compliance to the upcoming ISO26262 standardThe ISO26262 not only requires comprehensive checking ofrequirements but also states explicitly the need for usingassumptions on the environment to develop a safety relevantelement on the supplier side (ldquosafety element out of contextrdquo)In particular the standard distinguishes betweenbull A functional safety concept comprising the functional
safety requirements their allocation to architectural el-ements and their interaction necessary to achieve thesafety goals This is used to demonstrate that the risksrelated to an item of a vehicle are addressed by anadequate functional architecture
bull A technical safety concept used to demonstrate that thefunctional safety concept is addressed by an adequatetechnical solution
As a simple example for this approach we take the functionalarchitecture of Figure 20 showing the decomposition of theSafeBrakeIndication function into the ldquonormalrdquo BrakeIndicationfunction and the SignalingFailureDetection safety function in casethe BrakeIndication fails The corresponding safety goal requiresthat a loss of the braking indication function shall be detectedThis is formalized as contract CS0 shown in Table XV Thiscontract states that under a given failure hypothesis (ldquonodouble failurerdquo) either the brake lamp is activated or the driveris warned by the SignalingFailureDetection function This contractis attached to the function SafeBrakeIndication
For the subfunction BrakeIndication we show in Table XVIa contract CS1 stating the correct behavior in the absence
RR ndeg 8147
Contracts for System Design 57
CS0
As trueAw Only one of Fail(BrakeIndication)
and Fail(SignalFailureDetection) occursG Whenever BreakRequest occurs then
BreakIndication or SignalFailureDetection is performed
Table XVHORIZONTAL CONTRACT REPRESENTING FUNCTIONAL SAFETY
REQUIREMENT
ltltFunctiongtgt SafeBrakeIndication
ltltFunctiongtgt BrakeIndication
ltltSafetyFunctiongtgt SignalingFailureDetection
ltltFunctionalExchangegtgt BrakeRequest
ltltFunctionalExchangegtgt Detect(BrakeIndicationFail)
Figure 20 Functional architecture including safety function
of a failure of this function For the SignalingFailureDetection
CS1
As trueAw Absence of Fail(BrakeIndication)G Whenever BrakeRequest occurs then
BrakeIndication is performed
Table XVIHORIZONTAL CONTRACT FOR FUNCTION OF BRAKING LAMP
the associated contract states that a detected failure of thesub-function BrakeIndication is correctly indicated under theassumption that the provided function itself is not impacted bya failure see Table XVII An easy manual inspection shows
CS2
As trueAw Absence of fail(SignalingFailureDetection)G Whenever detect(fail(BrakeIndication))
SignalingFailureDetection is performed
Table XVIIHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
that the composition of CS1 otimes CS2 refines CS0 ie we haveformally validated the functional safety concept
The next step consists in allocating these functions tosoftware components on the VFB and developing a simpletechnical safety concept The corresponding technical architec-ture is shown in Figure 21 For the sake of simplicity we onlyconsider corrupted data while transmitting under failure modeThe affected communication links are marked in blue in Fig-ure 21 Thus fail(BrakeIndication) is mapped to fail(pos_pedal) andfail(lamp_intensity) In the same way fail(SignalingFailureDetection)is mapped to fail(mal_indication) This mapping is not furtherelaborated in this paper
For defining the technical safety concept so-called prop-agation contracts are used Propagation contracts expresshow failures (from the environment of the component) are
BrakePedal Sensor
PedalTo Lamp
BrakeLamp Actuator
MalfunctionIndication
lamp_intensity pos_pedal
ext_pedal mal_indication
ext_lamp
ext_indication
Figure 21 Extract of Indicator System
processed by the component According to the ISO 26262 (seeFigure 22) Faults Errors and Failures are distinguished by thepatterns used for the contracts
Figure 22 The role of Faults Errors and failures
For instance the contract CS4 of Table XVIII states that theerror state of the PedalToLamp component is caused by a failurein the communication
CS4
As trueAw trueG Mode PedalToLampError is caused by
fail(pos_pedal)
Table XVIIIHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
The nominal behavior is again given by the contract with anassumption about the absence of the communication failuresee Table XIX
Similarly the error state of the BreakLampActuator iscaused by a failure on the second communication link(fail(lamp_intensity)) or by a failure propagated from the PedalTo-Lamp component see Table XX The nominal behavior of the
RR ndeg 8147
Contracts for System Design 58
CS5
As trueAw Absence of fail(pos_pedal)G Whenever pos_pedal occurs then
lamp_intensity occurs
Table XIXEXEMPLARY CONTRACT FOR NOMINAL BEHAVIOR SPECIFICATION
BrakePedalSensor and the MalfunctionIndicator is formed similarlyto CS5
CS6
As trueAw trueG Mode BreakLampActuatorError is caused by
fail(lamp_intensity) or mode PedalToLampError
Table XXHORIZONTAL CONTRACT FOR SAFETY FUNCTION FOR BRAKING LAMP
The composition of contracts CS4 CS7
together with thenot stated simple nominal contracts entails the contract CS8
shown on Table XXI stating the functional safety requirement
CS8
As trueAw only one of faila failb failcG Whenever ext_pedal occurs then
ext_lamp or ext_indication occurs
Table XXICONTRACT STATING THE TECHNICAL SAFETY REQUIREMENT
Contract CS8is directly related to the functional safety goal
and includes the allocation to a technical safety concept Thisway a consistency between the functional and the technicalsafety concept has been established Furthermore thanks tothe formal pattern-based specification language the refinementrelations ensure that the concepts themselves are correct
To conclude let us mention other safety related use-caseswhich benefit from contract based specification such as theautomatic generation of fault-trees or FMEA tables as well asthe safe-state management
D Integrating Contracts in AUTOSAR
An important challenge is to smoothly integrate the use ofcontracts as part of AUTOSAR methodology We advocate amigration in two steps
TodaymdashOffering a Smooth Integration of Contract-BasedSystem Engineering with AUTOSAR The metamodel under-lying the CESAR reference technology platform has beencarefully designed to support a seamless design flow fromthe derivation of high-level requirements of new automotivefunctions to the level of detailed application design defined asthe entry point in the AUTOSAR design methodology The keyfor this smooth integration has been laid by AUTOSAR itselfby enforcing a clean separation between application develop-ment on the one side and deployment to distributed target
architectures on the other side Regarding layered design thejoint scope of CESAR and AUTOSAR ranges from systems-of-systems levels for Car2X applications to the introductionof new automotive functions and down to the detailed designlevel As illustrated in the previous section such phases wouldbuild on established design processes and currently used de-sign tools where contracts and viewpoints are conservativelyadded as additional flavor to existing design methodologiesFull hand-over to AUTOSAR takes place at the detailed designstage where component contracts get implemented using theAUTOSAR component model thus providing the entry pointfor the AUTOSAR design methodology
Following the AUTOSAR flow system configurations andECU configurations describe the detailed target hardware Wecan then automatically extract from system and ECU con-figurations all information for performing real-time analysisVertical assumptions on the component level can be derivedby back-annotation from the underlying target hardware Alter-natively vertical assumptions can be seen as constraining thetarget architecture (regarding its timing characteristics) and canthus be used to constrain the design space for possible targetarchitectures Finally when deploying components to ECUscommunications of the virtual functional bus are mapped to theinter-component communications on the physical architecture
The FuturemdashIntegrating Contracts in AUTOSAR The cur-rent AUTOSAR release is expressive enough to represent real-time contracts Using the concept of timing chains both end-to-end deadlines as well as assumed response times for compo-nent execution and communication can be expressed Howeverthe current release was not designed for extensibility thereis no established notion of viewpoints and hence no anchorto easily migrate from the current setting to one supportingmultiple viewpoints As pointed out before the decision asto which viewpoints should or should not be anchored is abusiness decision However given that ISO 26262 has becomebinding we see the need for a systematic integration of thesafety viewpoint
In fact a safety extension has already been proposed forinclusion in AUTOSAR It allows to use contracts for theencapsulation of Basic SoftWare (BSW) modules applicationsoftware components entities of the hardware architecture(like ECUs and buses) and the characterization of commu-nication services Such encapsulation would for instancedistinguish between BSW modules that (1) contribute to safety(safety mechanisms) and (2) those that could potentiallyimpact systemrsquos safety (by providing their failure propagationbehavior) A typical example for (1) would be the func-tion inhibition manager that maintains function inhibitionswhenever for instance implausible outputs are generated Atypical example for (2) would be an error that occurs inthe communication services or an error that is generated incommunication HW that impacts communication services
The objective of the extension is to provide an ISO 26262compliant traceability This allows for instance to deal withcompliance between functional safety (where functions haz-ards and safety functions are collected in the functional
RR ndeg 8147
Contracts for System Design 59
model) and technical safety of the AUTOSAR architectureinstance (guaranteeing that the AUTOSAR implementationmdashusing given safety functions of the AUTOSAR architecturemdashindeed implements the identified functional safety concept)
Since timing and safety viewpoints will be supported inAUTOSAR it is at least worthwhile to consider introducingthe concepts of viewpoints systematically Doing so will easetheir activation at times when other market factors such aspower-management mandate their introduction
E Summary and discussion
We have proposed a smooth path for integrating contractsin the context of AUTOSAR at the level of detailed designWe believe that the main aspects for consideration whileintroducing contracts are the handling of time budgets andthe specification of failure modes and failure propagation incombination with the functional aspect itself Vertical contractswere instrumental in handling time budgets Such contractsrelate two different layers of the AUTOSAR framework
XIII CONCLUSION
This paper presented past and recent results as well asnovel advances in the area of contracts and their theory Byencompassing (functional and non-functional) behaviors thenotion of contract we considered here represents a significantstep beyond the one originally developed in the softwareengineering community
A What contracts can do for the designer
This paper demonstrates that contracts offer a number ofadvantages
Contracts offer a technical support to legal customer-supplier documents Concurrent developmentmdashboth withinand across companiesmdashcalls for smooth coordination andintegration of the different design activities Properly definingand specifying the different concurrent design tasks is andremains a central difficulty Obligations must therefore beagreed upon together with suspensive conditions seen aslegal documents By clearly establishing responsibilities ourformalization of contracts constitutes the technical counterpartof such legal documents Contracts are an enabling technologyfor concurrent development
Contracts offer support to certification By providing for-mal arguments that can assess and guarantee the qualityof a design throughout all design phases (including earlyrequirements capture) contracts offer support for certificationBy providing sophisticated tools in support of modularityreuse in certification is made easier
Contracts comply with formal and semi-formal approachesThe need for being ldquocompletely formalrdquo has hampered for along time formal verification in many industrial sectors inwhich flexibility and intuitive expression in documentationsimulation and testing were and remain preferred As theAUTOSAR use case of Section XII demonstrated using con-tracts makes semi-formal design safer Small analysis stepsare within the reach of human reasoning A valid system
wide analysis for both component-based and refinement-baseddesigns is typically beyond the reach of human reasoningContract based design enables it
Contracts improve requirement engineering As illustratedin the Parking Garage example of Section XI contracts areinstrumental in decoupling top-level system architecture fromthe architecture used for sub-contracting to suppliers Formalsupport is critical in choosing alternative solutions and migrat-ing between different architectures with relatively small effortOf course contracts are not the only important technologyfor requirements engineeringmdashtraceability is essential anddeveloping domain specific ontologies is also important
Contracts can be used in any design process Contractsoffer a orthogonal support for all methodologies and can beused in any flow as a supporting technology in composing andrefining designs
B Status of research
The area of contracts benefits from many advances inresearch that were not targeted to it Interface theories weredeveloped by the community of game theorymdashcomponent andenvironment are seen as two players in a game Modalitiesaimed to offer more expressive logics were born at theboundary between logics and formal verification Contractsas a philosophy originated both from software engineeringand formal verification communities with the paradigms ofPre-conditionPost-condition or AssumeGuarantee It is notuntil the 2000rsquos that the concept of contracts presented hereas a tool to support system design emerged In this evolutionvarious formalisms and theories were borrowed to developa rigorous framework This paper was intended to show thepower of a unified theoretical background for contracts the useof contracts in present methodologies and the challenges for itseffective applications in future applications The mathematicalelegance of the concepts underpinning this area providesconfidence in a sustained continuation of the research effort
C Status of practice
The use of contract-based techniques in system design isin its infancy in industry Further maturation is needed forits paradigm and concepts to become on one side clearand simple to be widely accepted by engineers in their day-to-day work and on the other side developed enough toallow for the development of tools for automatic verificationand synthesis While powerful contract-based proof-of-concepttools are being experimentedmdashsome of them were presentedin this papermdashthe robustness of the tools and the underlyingtechniques is still weak and contract-based design flows andmethodologies are not yet fully developed nor mature
D The way forward
The ability of contracts to accommodate semi-formal andformal methodologies should enable a smooth and rapid mi-gration from theory and proof-of-concepts to robust flows andmethodologies The need for jointly developing new systemswhile considering issues of intellectual property will make
RR ndeg 8147
Contracts for System Design 60
it attractive to rely on contracts in supplier chains In ouropinion contracts are primarily helpful for early stages ofsystem design and particularly requirement engineering whereformal methods are desperately needed to support distributedand concurrent development by independent actors
We have illustrated in this paper how suppliers can be givensub-contracts that are correct by construction and can be auto-matically generated from top-level specification We believehowever that the semi-assistedsemi-manual use of contractssuch as exemplified by our AUTOSAR case study is alreadya significant help useful for requirements engineering tooAltogether a contract engine (such as the MICA tool presentedin Section XI) can be used in combination with both manualreasoning and dedicated formal verification engines (eg fortargeting the timing viewpoint or the safety viewpoint) as thebasis for future development that will make contracts mainstream
REFERENCES
[1] Martiacuten Abadi and Leslie Lamport Conjoining specifications ACMTrans Program Lang Syst 17(3)507ndash534 1995
[2] Yael Abarbanel Ilan Beer Leonid Gluhovsky Sharon Keidar andYaron Wolfsthal FoCs - Automatic Generation of Simulation Checkersfrom Formal Specifications In E Emerson and A Sistla editors Com-puter Aided Verification volume 1855 of Lecture Notes in ComputerScience pages 538ndash542 Springer Berlin Heidelberg 2000
[3] B Thomas Adler Luca de Alfaro Leandro Dias da Silva MarcoFaella Axel Legay Vishwanath Raman and Pritam Roy Ticc A Toolfor Interface Compatibility and Composition In Proc of the 18thInternational Conference on Computer Aided Verification (CAVrsquo06)volume 4144 of Lecture Notes in Computer Science pages 59ndash62Springer 2006
[4] Albert Benveniste and Benoicirct Caillaud and Jean-Baptiste RacletApplication of Interface Theories to the Separate Compilation ofSynchronous Programs In IEEE Conf on Decision and Control dec2012
[5] Luca De Alfaro and Thomas A Henzinger Interface-based design InIn Engineering Theories of Software Intensive Systems proceedings ofthe Marktoberdorf Summer School Kluwer 2004
[6] Rajeev Alur and David L Dill A theory of timed automata TheoreticalComputer Science 126(2)183ndash235 1994
[7] Rajeev Alur Limor Fix and Thomas A Henzinger A determinizableclass of timed automata In David L Dill editor CAV volume 818 ofLecture Notes in Computer Science pages 1ndash13 Springer 1994
[8] Rajeev Alur Limor Fix and Thomas A Henzinger Event-clockautomata A determinizable class of timed automata Theor ComputSci 211(1-2)253ndash273 1999
[9] Rajeev Alur Thomas A Henzinger and Orna Kupferman Alternating-time temporal logic J ACM 49(5)672ndash713 2002
[10] Rajeev Alur Thomas A Henzinger Orna Kupferman and Moshe YVardi Alternating refinement relations In Proc of the 9th InternationalConference on Concurrency Theory (CONCURrsquo98) volume 1466 ofLecture Notes in Computer Science pages 163ndash178 Springer 1998
[11] Adam Antonik Michael Huth Kim G Larsen Ulrik Nyman andAndrzej Wasowski 20 Years of Modal and Mixed SpecificationsBulletin of European Association of Theoretical Computer Science1(94) 2008
[12] Adam Antonik Michael Huth Kim Guldstrand Larsen Ulrik Nymanand Andrzej Wasowski Complexity of Decision Problems for Mixedand Modal Specifications In FoSSaCS pages 112ndash126 2008
[13] Road vehicles ndash functional safety Standard ISO 26262[14] Christel Baier and Joost-Pieter Katoen Principles of Model Checking
MIT Press Cambridge 2008[15] Felice Balarin Jerry R Burch Luciano Lavagno Yosinori Watanabe
Roberto Passerone and Alberto L Sangiovanni-Vincentelli Con-straints specification at higher levels of abstraction In Proceedingsof the Sixth IEEE International High-Level Design Validation and Test
Workshop (HLDVT01) pages 129ndash133 Monterey CA November 7ndash92001 IEEE Computer Society Los Alamitos CA USA
[16] Felice Balarin Abhijit Davare Massimiliano DrsquoAngelo Douglas Dens-more Trevor Meyerowitz Roberto Passerone Alessandro Pinto Al-berto Sangiovanni-Vincentelli Alena Simalatsar Yoshinori WatanabeGuang Yang and Qi Zhu Platform-based design and frameworksMETROPOLIS and METRO II In Gabriela Nicolescu and Pieter JMosterman editors Model-Based Design for Embedded Systems chap-ter 10 page 259 CRC Press Taylor and Francis Group Boca RatonLondon New York November 2009
[17] Felice Balarin and Roberto Passerone Functional verification method-ology based on formal interface specification and transactor generationIn Proceedings of the Conference on Design Automation and Test inEurope (DATE06) pages 1013ndash1018 Munich Germany March 6ndash102006 European Design and Automation Association 3001 LeuvenBelgium
[18] Felice Balarin and Roberto Passerone Specification synthesis andsimulation of transactor processes IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 26(10)1749ndash1762October 2007
[19] Felice Balarin Roberto Passerone Alessandro Pinto and Alberto LSangiovanni-Vincentelli A formal approach to system level designMetamodels and unified design environments In Proceedings of theThird ACM and IEEE International Conference on Formal Methodsand Models for Co-Design (MEMOCODE05) pages 155ndash163 VeronaItaly July 11ndash14 2005 IEEE Computer Society Los Alamitos CAUSA
[20] Felice Balarin Yosinori Watanabe Harry Hsieh Luciano LavagnoClaudio Passerone and Alberto L Sangiovanni-Vincentelli Metropo-lis An Integrated Electronic System Design Environment IEEEComputer 36(4)45ndash52 2003
[21] Krishnakumar Balasubramanian Aniruddha Gokhale Gabor KarsaiJanos Sztipanovits and Sandeep Neema Developing applicationsusing model-driven design environments IEEE Computer 39(2)33ndash40 2006
[22] Sebastian S Bauer Alexandre David Rolf Hennicker Kim GuldstrandLarsen Axel Legay Ulrik Nyman and Andrzej Wasowski Movingfrom specifications to contracts in component-based design In Juande Lara and Andrea Zisman editors FASE volume 7212 of LectureNotes in Computer Science pages 43ndash58 Springer 2012
[23] Sebastian S Bauer Philip Mayer Andreas Schroeder and Rolf Hen-nicker On Weak Modal Compatibility Refinement and the MIOWorkbench In Proc of 16th International Conference on Tools andAlgorithms for the Construction and Analysis of Systems (TACASrsquo10)volume 6015 of Lecture Notes in Computer Science pages 175ndash189Springer 2010
[24] Andreas Baumgart Eckard Boumlde Matthias Buumlker Werner Damm Guumln-ter Ehmen Tayfun Gezgin Stefan Henkler Hardi Hungar BernhardJosko Markus Oertel Thomas Peikenkamp Philipp Reinkemeier IngoStierand and Raphael Weber Architecture Modeling Technical reportOFFIS March 2011
[25] Nikola Benes Jan Kretiacutenskyacute Kim Guldstrand Larsen and Jiriacute SrbaChecking Thorough Refinement on Modal Transition Systems IsEXPTIME-Complete In Martin Leucker and Carroll Morgan editorsICTAC volume 5684 of Lecture Notes in Computer Science pages112ndash126 Springer 2009
[26] Nikola Benes Jan Kretiacutenskyacute Kim Guldstrand Larsen and Jiriacute SrbaOn determinism in modal transition systems Theoretical ComputerScience 410(41)4026ndash4043 2009
[27] Benoicirct Caillaud and Jean-Baptiste Raclet Ensuring Reachability byDesign In Int Colloquium on Theoretical Aspects of Computing sept2012
[28] Albert Benveniste and Geacuterard Berry The synchronous approach toreactive and real-time systems Proceedings of the IEEE 79(9)1270ndash1282 1991
[29] Albert Benveniste Benoicirct Caillaud Alberto Ferrari LeonardoMangeruca Roberto Passerone and Christos Sofronis Multiple view-point contract-based specification and design In Proceedings of theSoftware Technology Concertation on Formal Methods for Componentsand Objects FMCOrsquo07 volume 5382 of Lecture Notes in ComputerScience pages 200ndash225 Springer October 2008
[30] Albert Benveniste Paul Caspi Stephen A Edwards Nicolas Halb-wachs Paul Le Guernic and Robert de Simone The SynchronousLanguages 12 years later Proceedings of the IEEE 91(1)64ndash83 2003
RR ndeg 8147
Contracts for System Design 61
[31] Luca Benvenuti Alberto Ferrari Leonardo Mangeruca EmanueleMazzi Roberto Passerone and Christos Sofronis A contract-basedformalism for the specification of heterogeneous systems In Proceed-ings of the Forum on Specification Verification and Design Languages(FDL08) pages 142ndash147 Stuttgart Germany September 23ndash25 2008
[32] Gerard Berry The effectiveness of synchronous languages for thedevelopment of safety-critical systems White paper Esterel Technolo-gies 2003
[33] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet A compositional approach on modal specifications for timedsystems In Proc of the 11th International Conference on FormalEngineering Methods (ICFEMrsquo09) volume 5885 of Lecture Notes inComputer Science pages 679ndash697 Springer 2009
[34] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet Modal event-clock specifications for timed component-baseddesign Science of Computer Programming 2011 To appear
[35] Nathalie Bertrand Axel Legay Sophie Pinchinat and Jean-BaptisteRaclet Modal event-clock specifications for timed component-baseddesign Science of Computer Programming 2012 to appear
[36] Nathalie Bertrand Sophie Pinchinat and Jean-Baptiste Raclet Refine-ment and consistency of timed modal specifications In Proc of the3rd International Conference on Language and Automata Theory andApplications (LATArsquo09) volume 5457 of Lecture Notes in ComputerScience pages 152ndash163 Springer 2009
[37] Antoine Beugnard Jean-Marc Jeacutezeacutequel and Noeumll Plouzeau Makingcomponents contract aware IEEE Computer 32(7)38ndash45 1999
[38] Dirk Beyer Arindam Chakrabarti and Thomas A Henzinger Webservice interfaces In Allan Ellis and Tatsuya Hagino editors WWWpages 148ndash159 ACM 2005
[39] Purandar Bhaduri and S Ramesh Interface synthesis and protocolconversion Formal Aspects of Computing 20(2)205ndash224 2008
[40] Purandar Bhaduri and Ingo Stierand A proposal for real-time interfacesin speeds In Design Automation and Test in Europe (DATErsquo10) pages441ndash446 IEEE 2010
[41] Simon Bliudze and Joseph Sifakis The Algebra of Connectors -Structuring Interaction in BIP IEEE Trans Computers 57(10)1315ndash1330 2008
[42] R Bloem and B Jobstmann Manual for property-based synthesis toolTechnical Report Prosyd D223 2006
[43] Roderick Bloem Alessandro Cimatti Karin Greimel Georg HofferekRobert Koumlnighofer Marco Roveri Viktor Schuppan and RichardSeeber RATSY - A New Requirements Analysis Tool with SynthesisIn Tayssir Touili Byron Cook and Paul Jackson editors CAV volume6174 of Lecture Notes in Computer Science pages 425ndash429 Springer2010
[44] Grady Booch James Rumbaugh and Ivar Jacobson Unified ModelingLanguage User Guide The (2nd Edition) (Addison-Wesley ObjectTechnology Series) Addison-Wesley Professional 2005
[45] Amar Bouali XEVE an Esterel Verification Environment In Alan JHu and Moshe Y Vardi editors CAV volume 1427 of Lecture Notesin Computer Science pages 500ndash504 Springer 1998
[46] Geacuterard Boudol and Kim Guldstrand Larsen Graphical versus logicalspecifications Theor Comput Sci 106(1)3ndash20 1992
[47] Jerry R Burch Trace Algebra for Automatic Verification of Real-Time Concurrent Systems PhD thesis School of Computer ScienceCarnegie Mellon University August 1992
[48] Jerry R Burch Roberto Passerone and Alberto L Sangiovanni-Vincentelli Overcoming heterophobia Modeling concurrency in het-erogeneous systems In Proceedings of the 2nd International Confer-ence on Application of Concurrency to System Design (ACSD01) pages13ndash32 Newcastle upon Tyne UK June 25ndash29 2001 IEEE ComputerSociety Los Alamitos CA USA
[49] Benoicirct Caillaud Mica A Modal Interface Compositional AnalysisLibrary October 2011 httpwwwirisafrs4toolsmica
[50] Benoicirct Caillaud Benoicirct Delahaye Kim G Larsen Axel LegayMikkel Larsen Pedersen and Andrzej Wasowski Compositional designmethodology with constraint Markov chains In Proceedings of the7th International Conference on Quantitative Evaluation of SysTems(QEST) 2010 IEEE Computer Society 2010
[51] Daniela Cancila Roberto Passerone Tullio Vardanega and MarcoPanunzio Toward correctness in the specification and handling ofnon-functional attributes of high-integrity real-time embedded systemsIEEE Transactions on Industrial Informatics 6(2)181ndash194 May 2010
[52] Karlis Cerans Jens Chr Godskesen and Kim Guldstrand LarsenTimed Modal Specification - Theory and Tools In Costas Courcou-betis editor CAV volume 697 of Lecture Notes in Computer Sciencepages 253ndash267 Springer 1993
[53] Pavol Cernyacute Martin Chmelik Thomas A Henzinger and ArjunRadhakrishna Interface simulation distances In Marco Faella andAniello Murano editors GandALF volume 96 of EPTCS pages 29ndash42 2012
[54] Arindam Chakrabarti A Framework for Compositional Design andAnalysis of Systems PhD thesis EECS Department University ofCalifornia Berkeley Dec 2007
[55] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger MarcinJurdzinski and Freddy Y C Mang Interface compatibility checkingfor software modules In Ed Brinksma and Kim Guldstrand Larseneditors CAV volume 2404 of Lecture Notes in Computer Sciencepages 428ndash441 Springer 2002
[56] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger andFreddy Y C Mang Synchronous and Bidirectional Component Inter-faces In Proc of the 14th International Conference on Computer AidedVerification (CAVrsquo02) volume 2404 of Lecture Notes in ComputerScience pages 414ndash427 Springer 2002
[57] Arindam Chakrabarti Luca de Alfaro Thomas A Henzinger andMarieumllle Stoelinga Resource Interfaces In Rajeev Alur and InsupLee editors EMSOFT volume 2855 of Lecture Notes in ComputerScience pages 117ndash133 Springer 2003
[58] Edward Y Chang Zohar Manna and Amir Pnueli Characterizationof temporal property classes In Werner Kuich editor ICALP volume623 of Lecture Notes in Computer Science pages 474ndash486 Springer1992
[59] Taolue Chen Chris Chilton Bengt Jonsson and Marta ZKwiatkowska A compositional specification theory for componentbehaviours In Helmut Seidl editor ESOP volume 7211 of LectureNotes in Computer Science pages 148ndash168 Springer 2012
[60] Chris Chilton Marta Z Kwiatkowska and Xu Wang Revisiting timedspecification theories A linear-time perspective In Marcin Jurdzinskiand Dejan Nickovic editors FORMATS volume 7595 of Lecture Notesin Computer Science pages 75ndash90 Springer 2012
[61] E Clarke O Grumberg and D Peled Model Checking MIT Press1999
[62] Edmund M Clarke David E Long and Kenneth L McMillanCompositional model checking In LICS pages 353ndash362 1989
[63] W Damm E Thaden I Stierand T Peikenkamp and H HungarUsing Contract-Based Component Specifications for Virtual Integra-tion and Architecture Design In Proceedings of the 2011 DesignAutomation and Test in Europe (DATErsquo11) March 2011 To appear
[64] Werner Damm and David Harel LSCs Breathing life into messagesequence charts Formal Methods in System Design 19(1)45ndash80 2001
[65] Werner Damm Angelika Votintseva Alexander Metzner BernhardJosko Thomas Peikenkamp and Eckard Boumlde Boosting reuse ofembedded automotive applications through rich components In Pro-ceedings of FIT 2005 - Foundations of Interface Technologies 2005
[66] Werner Damm and Bernd Westphal Live and let die LSC basedverification of UML models Sci Comput Program 55(1-3)117ndash1592005
[67] Abhijit Davare Douglas Densmore Trevor Meyerowitz AlessandroPinto Alberto Sangiovanni-Vincentelli Guang Yang and Qi Zhu Anext-generation design framework for platform-based design In DesignVerification Conference (DVCon) San Josersquo California 2007
[68] Alexandre David Kim G Larsen Axel Legay Ulrik Nyman andAndrzej Wasowski Timed IO automata A complete specificationtheory for real-time systems In Proc of the 13th ACM InternationalConference on Hybrid Systems Computation and Control (HSCCrsquo10)pages 91ndash100 ACM 2010
[69] Alexandre David Kim Guldstrand Larsen Axel Legay Ulrik Nymanand Andrzej Wasowski ECDAR An Environment for CompositionalDesign and Analysis of Real Time Systems In Proc of the 8thInternational Symposium on Automated Technology for Verificationand Analysis (ATVArsquo10) volume 6252 of Lecture Notes in ComputerScience pages 365ndash370 2010
[70] Luca de Alfaro Game Models for Open Systems In VerificationTheory and Practice volume 2772 of Lecture Notes in ComputerScience pages 269ndash289 Springer 2003
[71] Luca de Alfaro Leandro Dias da Silva Marco Faella Axel LegayPritam Roy and Maria Sorea Sociable Interfaces In Proc of
RR ndeg 8147
Contracts for System Design 62
the 5th International Workshop on Frontiers of Combining Systems(FroCosrsquo05) volume 3717 of Lecture Notes in Computer Sciencepages 81ndash105 Springer 2005
[72] Luca de Alfaro and Thomas A Henzinger Interface automata In Procof the 9th ACM SIGSOFT International Symposium on Foundations ofSoftware Engineering (FSErsquo01) pages 109ndash120 ACM Press 2001
[73] Luca de Alfaro and Thomas A Henzinger Interface theories forcomponent-based design In Thomas A Henzinger and Christoph MKirsch editors EMSOFT volume 2211 of Lecture Notes in ComputerScience pages 148ndash165 Springer 2001
[74] Luca de Alfaro Thomas A Henzinger and Marieumllle Stoelinga TimedInterfaces In Proc of the 2nd International Workshop on EmbeddedSoftware (EMSOFTrsquo02) volume 2491 of Lecture Notes in ComputerScience pages 108ndash122 Springer 2002
[75] Benoicirct Delahaye Modular Specification and Compositional Analysisof Stochastic Systems PhD thesis Universiteacute de Rennes 1 2010
[76] Benoicirct Delahaye Benoicirct Caillaud and Axel Legay ProbabilisticContracts A Compositional Reasoning Methodology for the Designof Stochastic Systems In Proc 10th International Conference onApplication of Concurrency to System Design (ACSD) Braga PortugalIEEE 2010
[77] Benoicirct Delahaye Benoicirct Caillaud and Axel Legay Probabilisticcontracts A compositional reasoning methodology for the designof systems with stochastic andor non-deterministic aspects FormalMethods in System Design 2011 To appear
[78] Benoicirct Delahaye Uli Fahrenberg Thomas A Henzinger Axel Legayand Dejan Nickovic Synchronous interface theories and time trig-gered scheduling In Holger Giese and Grigore Rosu editorsFMOODSFORTE volume 7273 of Lecture Notes in Computer Sci-ence pages 203ndash218 Springer 2012
[79] Benoicirct Delahaye Joost-Pieter Katoen Kim G Larsen Axel LegayMikkel L Pedersen Falak Sher and Andrzej Wasowski AbstractProbabilistic Automata In Ranjit Jhala and David A Schmidt editorsVMCAI volume 6538 of Lecture Notes in Computer Science pages324ndash339 Springer 2011
[80] Douglas Densmore Sanjay Rekhi and Alberto L Sangiovanni-Vincentelli Microarchitecture Development via Metropolis SuccessivePlatform Refinement In DATE pages 346ndash351 IEEE ComputerSociety 2004
[81] David L Dill Trace Theory for Automatic Hierarchical Verificationof Speed-Independent Circuits ACM Distinguished Dissertations MITPress 1989
[82] Nicolaacutes DrsquoIppolito Dario Fischbein Marsha Chechik and SebastiaacutenUchitel MTSA The Modal Transition System Analyser In Proc ofthe 23rd IEEEACM International Conference on Automated SoftwareEngineering (ASErsquo08) pages 475ndash476 IEEE 2008
[83] Laurent Doyen Thomas A Henzinger Barbara Jobstmann and TatjanaPetrov Interface theories with component reuse In Proceedings of the8th ACM amp IEEE International conference on Embedded softwareEMSOFTrsquo08 pages 79ndash88 2008
[84] Dumitru Potop-Butucaru and Stephen Edwards and Geacuterard BerryCompiling Esterel Springer V 2007 ISBN 0387706267
[85] Cindy Eisner PSL for Runtime Verification Theory and Practice InOleg Sokolsky and Serdar Tasiran editors RV volume 4839 of LectureNotes in Computer Science pages 1ndash8 Springer 2007
[86] Cindy Eisner Dana Fisman John Havlicek Michael JC GordonAnthony McIsaac and David Van Campenhout Formal Syntax andSemantics of PSL - Appendix B of Accellera LRM January 2003Technical report IBM 2003
[87] Cindy Eisner Dana Fisman John Havlicek Yoad Lustig AnthonyMcIsaac and David Van Campenhout Reasoning with temporal logicon truncated paths In Warren A Hunt Jr and Fabio Somenzi editorsCAV volume 2725 of Lecture Notes in Computer Science pages 27ndash39Springer 2003
[88] Johan Eker Joumlrn W Janneck Edward A Lee Jie Liu Xiaojun LiuJ Ludvig Stephen Neuendorffer S Sachs and Yuhong Xiong Tamingheterogeneity - the ptolemy approach Proc of the IEEE 91(1)127ndash144 2003
[89] G Feuillade Modal specifications are a syntactic fragment of the Mu-calculus Research Report RR-5612 INRIA June 2005
[90] Dario Fischbein and Sebastiaacuten Uchitel On correct and completestrong merging of partial behaviour models In Proc of the 16thACM SIGSOFT International Symposium on Foundations of SoftwareEngineering (SIGSOFT FSErsquo08) pages 297ndash307 ACM 2008
[91] F Fleurey P A Muller and J M Jzquel Weaving executabilityinto object-oriented meta-languages In Proceedgins of the 8th In-ternational Conference on Model Driven Engineering Languages andSystems (MODELS05) October 2005
[92] Freacutedeacuteric Boussinot and Robert de Simone The Esterel languageProceedings of the IEEE 79(9)1293ndash1304 1991
[93] Peter Fritzson Principles of Object-Oriented Modeling and Simulationwith Modelica 21 Wiley 2003
[94] Tayfun Gezgin Raphael Weber and Maurice Girod A RefinementChecking Technique for Contract-Based Architecture Designs InFourth International Workshop on Model Based Architecting andConstruction of Embedded Systems ACES-MBrsquo11 volume 7167 ofLecture Notes in Computer Science Springer October 2011
[95] Jens Chr Godskesen Kim Guldstrand Larsen and Arne Skou Auto-matic verification of real-time systems using Epsilon In Son T Vuongand Samuel T Chanson editors PSTV volume 1 of IFIP ConferenceProceedings pages 323ndash330 Chapman amp Hall 1994
[96] G Goumlssler and J-B Raclet Modal Contracts for Component-basedDesign In Proc of the 7th IEEE International Conference on SoftwareEngineering and Formal Methods (SEFMrsquo09) IEEE Computer SocietyPress November 2009
[97] Susanne Graf and Sophie Quinton Contracts for BIP HierarchicalInteraction Models for Compositional Verification In John Derrick andJuumlri Vain editors FORTE volume 4574 of Lecture Notes in ComputerScience pages 1ndash18 Springer 2007
[98] Orna Grumberg and David E Long Model checking and modularverification ACM Trans Program Lang Syst 16(3)843ndash871 1994
[99] Imene Ben Hafaiedh Susanne Graf and Sophie Quinton Reasoningabout Safety and Progress Using Contracts In Proc of ICFEMrsquo10volume 6447 of LNCS pages 436ndash451 Springer 2010
[100] Nicolas Halbwachs Synchronous programming of reactive systemsKluwer Academic Pub 1993
[101] Nicolas Halbwachs Fabienne Lagnier and Christophe Ratel Program-ming and Verifying Real-Time Systems by Means of the SynchronousData-Flow Language Lustre IEEE Trans Software Eng 18(9)785ndash793 1992
[102] Nicolas Halbwachs Fabienne Lagnier and Pascal Raymond Syn-chronous observers and the verification of reactive systems In MauriceNivat Charles Rattray Teodor Rus and Giuseppe Scollo editorsAMAST Workshops in Computing pages 83ndash96 Springer 1993
[103] Nicolas Halbwachs and Pascal Raymond Validation of synchronousreactive systems From formal verification to automatic testing In P SThiagarajan and Roland H C Yap editors ASIAN volume 1742 ofLecture Notes in Computer Science pages 1ndash12 Springer 1999
[104] David Harel Statecharts A visual formalism for complex systemsSci Comput Program 8(3)231ndash274 1987
[105] David Harel Hillel Kugler Shahar Maoz and Itai Segall Acceleratingsmart play-out In Jan van Leeuwen Anca Muscholl David PelegJaroslav Pokornyacute and Bernhard Rumpe editors SOFSEM volume5901 of Lecture Notes in Computer Science pages 477ndash488 Springer2010
[106] David Harel Robby Lampert Assaf Marron and Gera Weiss Model-checking behavioral programs In Samarjit Chakraborty Ahmed Jer-raya Sanjoy K Baruah and Sebastian Fischmeister editors EMSOFTpages 279ndash288 ACM 2011
[107] David Harel and Rami Marelly Come Letrsquos Play Scenario-BasedProgramming Using LSCs and the Play-Engine Springer-Verlag 2003httpwwwwisdomweizmannacil~harelComeLetsPlaypdf
[108] David Harel Assaf Marron and Gera Weiss Behavioral programmingCommun ACM 55(7)90ndash100 2012
[109] David Harel Assaf Marron Guy Wiener and Gera Weiss Behavioralprogramming decentralized control and multiple time scales InCristina Videira Lopes editor SPLASH Workshops pages 171ndash182ACM 2011
[110] David Harel and Amir Pnueli On the development of reactive systemsIn K R Apt editor Logic and Models for Verification and Specificationof Concurrent Systems volume F13 of NATO ASI Series pages 477ndash498 Springer-Verlag 1985
[111] H Heinecke W Damm B Josko A Metzner H KopetzA Sangiovanni-Vincentelli and M Di Natale Software Componentsfor Reliable Automotive Systems In Design Automation and Test inEurope 2008 DATE rsquo08 pages 549ndash554 march 2008
[112] Thomas A Henzinger and Dejan Nickovic Independent imple-mentability of viewpoints In Radu Calinescu and David Garlan edi-
RR ndeg 8147
Contracts for System Design 63
tors Monterey Workshop volume 7539 of Lecture Notes in ComputerScience pages 380ndash395 Springer 2012
[113] C A R Hoare An axiomatic basis for computer programmingCommun ACM 12(10)576ndash580 1969
[114] INCOSE Incose systems engineering handbook 2010 httpwwwincoseorgProductsPubsproductssehandbookaspx
[115] Cliff B Jones Specification and design of (parallel) programs In IFIPCongress pages 321ndash332 1983
[116] B Jonsson and K G Larsen Specification and refinement ofprobabilistic processes In Logic in Computer Science (LICS) pages266ndash277 IEEE Computer 1991
[117] Gilles Kahn The Semantics of Simple Language for Parallel Program-ming In IFIP Congress pages 471ndash475 1974
[118] S Karris Introduction to Simulink with Engineering ApplicationsOrchard Publications 2006
[119] G Karsai J Sztipanovits A Ledeczi and T Bapty Model-integrated development of embedded software Proceedings of theIEEE 91(1)145ndash164 January 2003
[120] Gabor Karsai Janos Sztipanovitz Akos Ledczi and Ted Bapty Model-integrated development of embedded software Proceedings of theIEEE 91(1) January 2003
[121] Orna Kupferman and Moshe Y Vardi Modular model checking InWillem P de Roever Hans Langmaack and Amir Pnueli editorsCOMPOS volume 1536 of Lecture Notes in Computer Science pages381ndash401 Springer 1997
[122] Leslie Lamport Proving the correctness of multiprocess programsIEEE Trans Software Eng 3(2)125ndash143 1977
[123] C Larman and VR Basili Iterative and incremental developments abrief history Computer 36(6)47ndash56 June 2003
[124] Kim G Larsen and L Xinxin Equation solving using modal transitionsystems In Proceedings of the 5th Annual IEEE Symp on Logic inComputer Science LICSrsquo90 pages 108ndash117 IEEE Computer SocietyPress 1990
[125] Kim Guldstrand Larsen Modal specifications In Automatic Verifica-tion Methods for Finite State Systems volume 407 of Lecture Notes inComputer Science pages 232ndash246 Springer 1989
[126] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski In-terface InputOutput Automata In Jayadev Misra Tobias Nipkowand Emil Sekerinski editors FM volume 4085 of Lecture Notes inComputer Science pages 82ndash97 Springer 2006
[127] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski ModalIO Automata for Interface and Product Line Theories In ProgrammingLanguages and Systems 16th European Symposium on ProgrammingESOPrsquo07 volume 4421 of Lecture Notes in Computer Science pages64ndash79 Springer 2007
[128] Kim Guldstrand Larsen Ulrik Nyman and Andrzej Wasowski OnModal Refinement and Consistency In Proc of the 18th InternationalConference on Concurrency Theory (CONCURrsquo07) pages 105ndash119Springer 2007
[129] Kim Guldstrand Larsen Bernhard Steffen and Carsten Weise A con-straint oriented proof methodology based on modal transition systemsIn Proc of the 1st International Workshop on Tools and Algorithmsfor Construction and Analysis of Systems (TACASrsquo95) volume 1019of Lecture Notes in Computer Science pages 17ndash40 Springer 1995
[130] Kim Guldstrand Larsen and Bent Thomsen A Modal Process LogicIn Proceedings of the Third Annual Symposium on Logic in ComputerScience (LICSrsquo88) pages 203ndash210 IEEE 1988
[131] A Ledeczi A Bakay M Maroti P Volgyesi G Nordstrom J Sprin-kle and G Karsai Composing domain-specific design environmentsIEEE Computer 34(11)44 ndash51 November 2001
[132] Akos Ledeczi Miklos Maroti Arpad Bakay Gabor Karsai JasonGarrett Charles Thomason Greg Nordstrom Jonathan Sprinkle andPeter Volgyesi The generic modeling environment In Proceedingsof the IEEE International Workshop on Intelligent Signal Processing(WISP2001) Budapest Hungary May 24ndash25 2001
[133] Edward A Lee Cyber physical systems Design challenges TechnicalReport UCBEECS-2008-8 EECS Department University of Califor-nia Berkeley Jan 2008
[134] Nancy A Lynch Inputoutput automata Basic timed hybrid proba-bilistic dynamic In Roberto M Amadio and Denis Lugiez editorsCONCUR volume 2761 of Lecture Notes in Computer Science pages187ndash188 Springer 2003
[135] Nancy A Lynch and Eugene W Stark A proof of the kahn principlefor inputoutput automata Inf Comput 82(1)81ndash92 1989
[136] Zohar Manna and Amir Pnueli Temporal verification of reactivesystems Safety Springer 1995
[137] Herveacute Marchand Patricia Bournai Michel Le Borgne and Paul LeGuernic Synthesis of Discrete-Event Controllers Based on the SignalEnvironment Discrete Event Dynamic Systems 10(4)325ndash346 2000
[138] Herveacute Marchand and Mazen Samaan Incremental Design of aPower Transformer Station Controller Using a Controller SynthesisMethodology IEEE Trans Software Eng 26(8)729ndash741 2000
[139] B Meyer Applying ldquodesign by contractrdquo IEEE Computer 25(10)40ndash51 October 1992
[140] Bertrand Meyer Touch of Class Learning to Program Well UsingObject Technology and Design by Contract Springer SoftwareEngineering 2009
[141] MW Maier Architecting Principles for Systems of Systems SystemsEngineering 1(4)267ndash284 1998
[142] Walid A Najjar Edward A Lee and Guang R Gao Advances in thedataflow computational model Parallel Computing 25(13-14)1907ndash1929 1999
[143] Radu Negulescu Process Spaces and the Formal Verification ofAsynchronous Circuits PhD thesis University of Waterloo Canada1998
[144] Nicolas Halbwachs and Paul Caspi and Pascal Raymond and DanielPilaud The synchronous data flow programming language LustreProceedings of the IEEE 79(9)1305ndash1320 1991
[145] P Nuzzo A Sangiovanni-Vincentelli X Sun and A PuggelliMethodology for the design of analog integrated interfaces usingcontracts IEEE Sensors Journal 12(12)3329ndash3345 Dec 2012
[146] Object Management Group (OMG) Model driven architecture (MDA)FAQ [online] httpwwwomgorgmda
[147] Object Management Group (OMG) Unified Modeling Language(UML) specification [online] httpwwwomgorgspecUML
[148] Object Management Group (OMG) A UML profile for MARTE beta1 OMG Adopted Specification ptc07-08-04 OMG August 2007
[149] Object Management Group (OMG) System modeling languagespecification v11 Technical report OMG 2008
[150] Object constraint language version 20 OMG Available Specificationformal06-05-01 Object Management Group May 2006
[151] The Design Automation Standards Committee of the IEEE Com-puter Society editor 1850-2010 - IEEE Standard for PropertySpecification Language (PSL) IEEE Computer Society 2010
[152] J Hudak P Feiler D Gluch The Architecture Analysis and DesignLanguage (AADL) An Introduction Software Engineering Institute(SEI) Technical Note CMUSEI-2006-TN-011 February 2006
[153] Roberto Passerone Semantic Foundations for Heterogeneous SystemsPhD thesis Department of Electrical Engineering and Computer Sci-ences University of California Berkeley Berkeley CA 94720 May2004
[154] Roberto Passerone Jerry R Burch and Alberto L Sangiovanni-Vincentelli Refinement preserving approximations for the design andverification of heterogeneous systems Formal Methods in SystemDesign 31(1)1ndash33 August 2007
[155] Roberto Passerone Luca de Alfaro Thomas A Henzinger and AlbertoSangiovanni-Vincentelli Convertibility verification and converter syn-thesis Two faces of the same coin In Proceedings of InternationalConference on Computer Aided Design San Jose CA 2002
[156] Roberto Passerone Imene Ben Hafaiedh Susanne Graf Albert Ben-veniste Daniela Cancila Arnaud Cuccuru Seacutebastien Geacuterard FrancoisTerrier Werner Damm Alberto Ferrari Leonardo Mangeruca Bern-hard Josko Thomas Peikenkamp and Alberto Sangiovanni-VincentelliMetamodels in Europe Languages tools and applications IEEEDesign and Test of Computers 26(3)38ndash53 MayJune 2009
[157] Paul Le Guernic and Thiserry Gautier and Michel Le Borgne andClaude Le Maire Programming real-time applications with SignalProceedings of the IEEE 79(9)1321ndash1336 1991
[158] I Pill B Jobstmann R Bloem R Frank M Moulin B SterinM Roveri and S Semprini Property simulation Technical ReportProsyd D121 2005
[159] Dumitru Potop-Butucaru Benoicirct Caillaud and Albert BenvenisteConcurrency in synchronous systems Formal Methods in SystemDesign 28(2)111ndash130 2006
[160] Dumitru Potop-Butucaru Robert de Simone and Yves Sorel Neces-sary and sufficient conditions for deterministic desynchronization InChristoph M Kirsch and Reinhard Wilhelm editors EMSOFT pages124ndash133 ACM 2007
RR ndeg 8147
Contracts for System Design 64
[161] Terry Quatrani Visual modeling with Rational Rose 2000 and UML(2nd ed) Addison-Wesley Longman Ltd Essex UK UK 2000
[162] R Sudarsan and SJ Fenves and RD Sriram and F Wang A productinformation modeling framework for product lifecycle managementComputer-Aided Design 371399ndash1411 2005
[163] Jean-Baptiste Raclet Quotient de speacutecifications pour la reacuteutilisationde composants PhD thesis Ecole doctorale Matisse universiteacute deRennes 1 November 2007
[164] Jean-Baptiste Raclet Residual for Component Specifications In Procof the 4th International Workshop on Formal Aspects of ComponentSoftware (FACSrsquo07) 2007
[165] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct CaillaudAxel Legay and Roberto Passerone Modal interfaces Unifyinginterface automata and modal specifications In Proceedings of theNinth International Conference on Embedded Software (EMSOFT09)pages 87ndash96 Grenoble France October 12ndash16 2009
[166] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct CaillaudAxel Legay and Roberto Passerone A modal interface theory forcomponent-based design Fundamenta Informaticae 108(1-2)119ndash149 2011
[167] Jean-Baptiste Raclet Eric Badouel Albert Benveniste Benoicirct Caillaudand Roberto Passerone Why are modalities good for interfacetheories In Proc of the 9th International Conference on Applicationof Concurrency to System Design (ACSDrsquo09) IEEE Computer SocietyPress 2009
[168] Richard Payne and John Fitzgerald Evaluation of ArchitecturalFrameworks Supporting Contract-Based Specification Technical Re-port CS-TR-1233 Computing Science Newcastle University UK Dec2010 available from httpwwwcsnclacukpublicationstrspapers1233pdf
[169] Robert W Floyd Assigning meaning to programs In JT Schwartzeditor Proceedings of Symposium on Applied Mathematics volume 19pages 19ndash32 1967
[170] A Sangiovanni-Vincentelli S Shukla J Sztipanovits G Yang andD Mathaikutty Metamodeling An emerging representation paradigmfor system-level design Special Section on Meta-Modeling IEEEDesign and Test 26(3)54ndash69 2009
[171] Alberto Sangiovanni-Vincentelli Quo vadis sld Reasoning aboutthe trends and challenges of system level design Proc of the IEEE95(3)467ndash506 2007
[172] D Schmidt Model-driven engineering IEEE Computer pages 25ndash31February 2006
[173] German Sibay Sebastian Uchitel and Viacutector Braberman ExistentialLive Sequence Charts Revisited In ICSE 2008 30th InternationalConference on Software Engineering ACM May 2008
[174] Joseph Sifakis Component-Based Construction of HeterogeneousReal-Time Systems in Bip In Giuliana Franceschinis and KarstenWolf editors Petri Nets volume 5606 of Lecture Notes in ComputerScience page 1 Springer 2009
[175] Functional safety of electricalelectronicprogrammable electronicsafety-related systems Standard IEC 61508
[176] Eugene W Stark A proof technique for relyguarantee properties InS N Maheshwari editor FSTTCS volume 206 of Lecture Notes inComputer Science pages 369ndash391 Springer 1985
[177] Stavros Tripakis Ben Lickly Thomas A Henzinger and Edward ALee On relational interfaces In Proc of the 9th ACM amp IEEEInternational conference on Embedded software (EMSOFTrsquo09) pages67ndash76 ACM 2009
[178] Stavros Tripakis Ben Lickly Thomas A Henzinger and Edward ALee A theory of synchronous relational interfaces ACM TransProgram Lang Syst 33(4)14 2011
[179] Sebastiaacuten Uchitel and Marsha Chechik Merging partial behaviouralmodels In Proc of the 12th ACM SIGSOFT International Symposiumon Foundations of Software Engineering (SIGSOFT FSErsquo10) pages43ndash52 ACM 2004
[180] Jos Warmer and Anneke Kleppe The Object Constraint LanguageGetting Your Models Ready for MDA Addison-Wesley LongmanPublishing Co Inc Boston MA USA 2nd edition 2003
RR ndeg 8147
RESEARCH CENTRERENNES ndash BRETAGNE ATLANTIQUE
Campus universitaire de Beaulieu35042 Rennes Cedex
PublisherInriaDomaine de Voluceau - RocquencourtBP 105 - 78153 Le Chesnay Cedexinriafr
ISSN 0249-6399
- Introduction
-
- The Present System Design
- The Future CPS and SoS
- The Need for a Methodological Effort
- Contract based design
- Readers guide
-
- System Design Challenges
-
- Complexity of Systems
- Complexity of OEM-Supplier Chains
- Managing Requirements
- Managing Risks
- System-wide Optimization
-
- How Challenges have been addressed so far
-
- Complexity of Systems and System-wide Optimization
-
- Layered design
- Component-based design
- The V-model process
- Model-Based Design
- Virtual Integration
- Platform Based Design
-
- Complexity of OEM-Supplier Chains Standardization and Harmonization
-
- Standardization of design entities
- Harmonization of processes and certification
-
- Managing Requirements Traceability and Multiple Viewpoints
- Cross-company Shared Risk Management
- The Need for Contracts
-
- Contracts what why where and how
-
- Contracts
-
- Components and their Environment Contracts
-
- Contract Operators
-
- Contract Composition and System Integration
- Contract Refinement and Independent Development
- Contract Conjunction and Viewpoint Fusion
-
- Contracts in requirement engineering
- Contract Support for Design Methodologies
-
- Supporting open systems
- Managing Requirements and Fusing Viewpoints
- Design Chain Management Re-using and Independent Development
- Deployment and Mapping
-
- Bibliographical note
-
- A Mathematical Meta-theory of Contracts
-
- Components and their composition
- Contracts
- Refinement and conjunction
- Contract composition
- Quotient
- Discussion
- Observers
- Bibliographical note
-
- Panorama of concrete theories
- Panorama AssumeGuarantee contracts
-
- Dataflow AG contracts
- Capturing exceptions
- Dealing with variable alphabets
- Synchronous AG contracts
- Observers
- Discussion
- Bibliographical note
-
- Panorama Interface theories
-
- Components as io-automata
- Interface Automata with fixed alphabet
- Modal Interfaces with fixed alphabet
- Modal Interfaces with variable alphabet
- Projecting and Restricting
- Observers
- Bibliographical note
-
- Panorama Timed Interface Theories
-
- Components as Event-Clock Automata
- Modal Event-Clock Specifications
- Bibliographical note
-
- Panorama Probabilistic Interface Theories
-
- Components as Probabilistic Automata
- Simple Modal Probabilistic Interfaces
- Bibliographical note
-
- The Parking Garage an example in Requirements Engineering
-
- The contract framework
- Top level requirements
- Formalizing requirements as contracts
- Sub-contracting to suppliers
- The four ``C
-
- Consistency amp Compatibility
- Correctness
- Completeness
-
- Discussion
-
- Contracts in the context of Autosar
-
- The Autosar context
- The contract framework
- Exterior Light Management System
-
- Function and timing
- Safety
-
- Integrating Contracts in Autosar
- Summary and discussion
-
- Conclusion
-
- What contracts can do for the designer
- Status of research
- Status of practice
- The way forward
-
- References
-
