Contracts for the Design of Embedded SystemsPart I: Methodology and Use Cases

Albert Benveniste†, Werner Damm∗∗, Alberto Sangiovanni-Vincentelli‖,Dejan Nickovic§, Roberto Passerone‡, and Philipp Reinkemeier∗∗

†INRIA/IRISA, Rennes, France. corresponding author: Albert.Benveniste@inria.fr‖University of California at Berkeley and University of Trento ∗∗Offis and University of Oldenburg

Abstract—This is Part I of a sequence of two papers onContract-Based Design (CBD). It is intended to:• Introduce the concepts underlying CBD;• Present the challenges facing facing designers of large-scale

complex systems today;• Review the design methodologies so far used to address these

challenges and show how contracts can be used in all theseapproaches to enhance their applicability and the quality ofthe final result, and

• Present three examples of the use of contracts: one simpleexample to underline the key steps of contract-based design,one about the use of contracts in enhancing and extendingthe AUTOSAR automotive standard and one related toanalog-mixed signal integrated circuit design.

Part II covers the theoretical foundations for contracts that areessential to make the methodology robust and well supportedby tools and software frameworks. We believe contract-baseddesign is going to be a key part of the future of system designand for this reason, this contribution is important for the designcommunity.

CONTENTS

I Introduction and Challenges 3I-A Managing Complexity . . . . . . . . . . 3I-B Managing the Industrial Supply Chain . 4I-C Capturing and Managing Requirements 6I-D Product optimization . . . . . . . . . . 6I-E Risk Management . . . . . . . . . . . . 6I-F Moving Forward . . . . . . . . . . . . . 6

II Addressing the Challenges 7II-A Contracts in embedded system design:

once over lightly . . . . . . . . . . . . . 7II-B Coping with complexity of systems . . 7

II-B1 Viewpoints . . . . . . . . . . 7II-B2 Layered design . . . . . . . . 9II-B3 Component-based design . . 9II-B4 The V-model of the design

process . . . . . . . . . . . . 10II-B5 Model-Based Development . 11

This work was funded in part by the European STREP-COMBEST projectnumber 215543, the European project CESAR of the ARTEMIS JointUndertaking, the Artist Design Network of Excellence number 214373, theMARCO FCRP MuSyC and GSRC grants, the DARPA METAII Project, theVKR Center of Excellence MT-LAB, and the German Innovation Alliance onEmbedded Systems SPES2020.

II-B6 Virtual Integration . . . . . . 11II-C Coping with the complexity of the sup-

ply chain . . . . . . . . . . . . . . . . . 12II-C1 Standardization of design

entities . . . . . . . . . . . . 12II-C2 Standardization/harmonization

of processes . . . . . . . . . 13II-D Getting initial requirements right . . . . 13II-E Coping with multi-layer design opti-

mization . . . . . . . . . . . . . . . . . 13II-F Managing risk across the development

process . . . . . . . . . . . . . . . . . . 14II-G Platform-Based Design and Contracts . 14

II-G1 Platform-based design . . . . 14II-G2 Contract-based design: Con-

tracts in PBD . . . . . . . . 15II-H Moving forward: the importance of con-

tracts . . . . . . . . . . . . . . . . . . . 17

III Contracts in Requirement Engineering: theParking Garage Example 18

III-A Top-level specification of the example . 18III-B Domain specific ontology . . . . . . . . 18III-C Defining and firming up requirements . 19III-D Executing requirements . . . . . . . . . 19III-E Identifying responsibilities . . . . . . . 19III-F Partitioning and allocating requirements

to subsystems . . . . . . . . . . . . . . 19III-G Further Refining Requirements . . . . . 20III-H More on Fundamental Properties . . . . 21III-I Requirements and system architecture . 21

IV AUTOSAR and Contracts 22IV-A Today - Offering a Smooth Integration

of Contract-Based System Engineeringwith AUTOSAR . . . . . . . . . . . . . 22

IV-B The Future - Integrating Contracts inAUTOSAR . . . . . . . . . . . . . . . . 23

IV-C An Approach for Integrating Contractsin AUTOSAR . . . . . . . . . . . . . . 23

IV-D AUTOSAR Model of an AdaptiveCruise Control Enriched by Contracts . 23

1

IV-D1 SW-compositionCrsCtrlAndAcc . . . . . . 23

IV-D2 Sub-contracting . . . . . . . 24IV-D3 Vertical Assumptions on

Software Components . . . . 24IV-D4 Vertical Assumptions on

AssemblySwConnectors . 25IV-E Using Contracts for Safety Specification 26IV-F Summary and discussion . . . . . . . . 27

V Contracts and Analog Mixed-Signal Circuit De-sign 27

V-A Analog Circuit Design: Why Are Con-tracts Important? . . . . . . . . . . . . . 27

V-B Analog Platform-Based Design andContracts . . . . . . . . . . . . . . . . . 28

V-C Contract-Based Design Flow . . . . . . 29

VI Concluding Remarks 29

References 30*

2

I. INTRODUCTION AND CHALLENGES

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 functionality,correctness, 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 Millioncars worldwide for reasons that ranged from the infamoussticky accelerator pedals to steering and engine problems. Thelast recall at the end of August 2010 was for the engine controlmodule. Toyota is not alone in this situation. Most of theautomotive makers had one or more major recalls in the recentpast (see e.g., http://www.autorecalls.us) involving electronicsas well as mechanical parts. Boeing and Airbus Industrie 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 (100,000 wires and 40,300 connectors) was considereda major issue (see http://en.wikipedia.org/wiki/Airbus_A380).The delays caused the departure of both the EADS and AirbusCEOs and of the program manager for the A380 and causedan overall earning short fall of 4.8 Billion Euros. Boeing orig-inally planned the first flight of the 787 for August 2007 (seehttp://en.wikipedia.org/wiki/Boeing_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 2.3Billion USD write-off not counting the claim of Air India of1 Billion USD damages for delayed delivery and the revenueshort falls. These are examples of the devastating effectsthat design problems may cause. Problems also come fromthe disconnect between the sales and marketing departmentand engineering when contracts are signed that are based onlimited evidence of their feasibility.

The specific root causes of these problems are complex andrelate to a number of issues ranging from design processes andrelationships with different departments of the same companyand with suppliers1 to incomplete requirement specificationand testing.2

Further, there is a widespread consensus in the industrythat there is much to gain by optimizing the implementationphase that today is only considering a very small subset of thedesign space. Some attempts at a more efficient design spaceexploration have been afoot but there is a need to formalizethe problem better and to involve in major ways the differentplayers of the supply chain. Information about the capabilitiesof the subsystems in terms of timing, power consumed, size,

1Toyota sticky accelerator problem came in part from components providedby two contractors whose interaction was not verified appropriately, Airbusdelay problems were in part due to contractors who had different versions ofthe CAD software

2Boeing stated that a structural problem was discovered late in the designprocess

weight and other physical aspects transmitted to the systemassemblers during design time would go a long way inproviding a better opportunity to design space exploration. Inthis landscape, a wrong turn in a system design project couldcause so much economic, social and organizational upheavalthat it may imperil the life of an entire company. No wonderthat there is much interest in risk management approaches toassess risks associated to design errors, delays, recalls andliabilities. Finding appropriate countermeasures to lower risksand to develop contingency plans is then a mainstay of the waylarge projects are managed today. The overarching issue is theneed of a substantive evolution of the design methodologyin use today in system companies. The issue to address is theunderstanding of the principles of system design, the necessarychange to design methodologies, and the dynamics of thesupply chain. Developing this understanding is necessary todefine a sound approach to the needs of the system companiesas they try to serve their customers better, to develop theirproducts faster and with higher quality.

This paper describes the notion of “contracts”, which canbe used in conjunction with the most popular design method-ologies to yield a novel framework where the problems listedabove can be addressed effectively.

As argued above, we need to address how to deal withthe design chain in a more effective way, how to managecomplexity and integration, how to improve the creation andmanagement of the requirements of the design, and howto make design space exploration more effective in productquality.

A. Managing Complexity

The ability to integrate an exponentially rising number oftransistors within a chip, the ever-expanding use of electronicembedded systems to control increasingly many aspects ofthe real world, and the trend to interconnect more and moresuch systems (often from different manufacturers) into aglobal network are creating a challenging scenario for systemdesigners. In this scenario, the three challenges that are takingcenter stage are as follows.

The Hardware Platform Complexity: The present inte-gration capabilities make it possible to build a real complexsystem on a chip including analog and RF components,general purpose processors (GPP) and Application-SpecificInstruction-set Processors (ASIP). The decision of what goeson a chip is no longer dictated by the amount of circuitrythat can be placed there, but by reliability, yield, powerconsumption, performance, and ultimately cost (it is wellknown that analog and RF components force the use of moreconservative manufacturing lines with more processing stepsthan pure digital ICs). The cost of designing semiconductorshas risen to a level that makes it impractical for systemcompanies to develop application specific solutions. Hence,most system companies rely on COTS and programmabilityto implement their applications.

For companies who build “physically large” systems suchas avionics and automotive companies, the complexity of the

3

hardware platform is reflected in the number of ElectronicControl Units and in their interconnections. For a top-of-the-line automobile, the number of processors to manage andinterconnect is above 50. The layout of the cables that connectthese processing elements with sensors and actuators is aserious concern. Initial production of the Airbus A380 wastroubled by delays in part attributed 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 and/or by software programmability. Inparticular, software is taking the lion’s share of the imple-mentation budgets and cost. In cell phones, more than 1million lines of code is standard today, while in automobilesthe estimated number of lines by 2010 is in the order ofhundreds of millions and in the Boeing 787 is in the orderof 20 million lines. However, as this happens, the complexityexplosion of the software component causes serious concernsfor the final quality of the products and the productivity ofthe engineering teams. In transportation, the productivity ofembedded software programmers using the traditional methodsof software development ranges in the few tens of lines perday. The reasons for such a low productivity are in the timeneeded for verification of the system and long redesign cyclesthat come from the need for developing full system prototypesfor the lack of appropriate virtual engineering methods andtools for embedded software.

Embedded software is substantially different from tradi-tional software for commercial and corporate applications.By virtue of being embedded in a surrounding system, thesoftware must be able to continuously react to stimuli in thedesired way, i.e., within bounds on timing, power consumed,and cost. Verifying the correctness of the system requiresthat the model of the software be transformed to includeinformation that involves physical quantities to retain onlywhat is relevant to the task at hand. In contrast, in traditionalsoftware systems, the abstraction process leaves out all thephysical aspects of the systems as only the functional aspectsof the code matter.

Given the impact that embedded software has on the safetyof embedded system devices and on the quality of the finalartifact, there is an increasingly strong interest in having highassurance that embedded software is correct. There is a riskthat certification will enter into new safety-critical domainsand will create an additional, serious burden on the embeddedsoftware design process for an increasingly large numberof companies worldwide. We believe it will be of extremeimportance to link the certification process with the contentof the software and not only with the development process,as already enforced today in advocating requirement basedtesting. We expect evolutions of these standards to further pushthis view by enforcing the use of formal verification methodsfor highest safety integrity levels, such as in the forthcomingsafety standard for airborne software development DO 178-C.

The Integration Complexity: A standard technique to dealwith complexity is decomposing top-down the system into sub-systems. This approach, which has been customarily adoptedby the semiconductor industry for years, has a limitation asa designer or a group of designers has to fully comprehendthe entire system and to partition appropriately its variousparts, a difficult task given the enormous complexity of today’ssystems. Hence, the future is one of developing systemsby composing pieces that all or in part have already beenpredesigned or designed independently by other design groupsor even companies. This has been done routinely in verticaldesign chains for example in the avionics and automotive ver-ticals, albeit in a heuristic and ad hoc way. The resulting lackof an overall understanding of the interplay of the subsystemsand of the difficulties encountered in integrating very complexparts cause system integration to become a nightmare in thesystem industry, as demonstrated by Table I.3

The source of these problems is clearly the increase incomplexity, but also the difficulty of the OEMs in managingthe integration and maintenance process with subsystemsthat come from different suppliers who use different designmethods, different software architecture, different hardwareplatforms, and different (and often proprietary) real-time op-erating systems.

Therefore, there is a need for standards, methods and toolsin the software and hardware domains that will allow plug-and-play of subsystems and their implementation. The abilityto integrate subsystems will then become a commodity item,available to all OEMs. The competitive advantage of an OEMwill increasingly reside on novel and compelling functionali-ties. There is also the need for improving the interaction amongall the players in the supply chain to improve the integrationchallenges in a substantial way.

B. Managing the Industrial Supply ChainThe design and supply chains are the backbone for any

industrial sector. Their health and efficiency are essential foreconomic viability. While tools for supply chain managementhave been around for quite some time, support for the designchain has not been pursued nearly as vigorously. There aregreat opportunities for improving the situation substantiallyat least in the safety-driven industrial sector, which includesthe transportation as well as industrial automation domain,with a combination of tools and methodologies. We are justat the beginning. Integration of electronic and mechanicaldesign tools and frameworks will be essential in the nearfuture. Integration of chemical, electronic, and biology toolswill also be essential in the further future for nanosystems.Data integration and information flow among the companiesforming the chain have to be supported. In other words,it is essential that the fundamental steps of system design(functional partitioning, allocation on computational resources,integration, and verification) be supported across the entiredesign development cycle.

3VDC research, Track 3: Embedded Systems Market Statistics Exhibit II-13from volumes on automotive/industrial automation/medical, 2008

4

Design task Tasks Tasks Tasks Tasks Tasks Tasksdelayed delayed delayed causing delay causing delay causing delayautomotive automation medical automotive automation medical

System integration 63.0% 56.5% 66.7% 42.3% 19.0% 37.5%test, and verificationSystem architecture 29.6% 26.1% 33.3% 38.5% 42.9% 31.3%design and specificationSoftware application 44.4% 30.4% 75.0% 26.9% 31.0% 25.0%and/or middlewaredevelopment and testProject management 37.0% 28.3% 16.7% 53.8% 38.1% 37.5%and planning

Table IDIFFICULTIES RELATED TO SYSTEM INTEGRATION

Thus, whether the integrations pertains to SW-SW inte-gration on a distributed network, HW-SW integration ona single electronic control unit (ECU), or electronics andmechanical integration for a subsystem, tools and modelshave to be integrated seamlessly from a static point of view(e.g., data dictionaries and off-line model transformations)and dynamic point of view (e.g., co-simulation, HW-in-the-loop simulations and emulation). The dynamics in the systemindustry is similar across the vertical domains but certainlythere are important differences. For example, for embeddedcontrollers in industrial engineering applications, automotive,avionics, energy production, and health related equipment,safety considerations, and hence hard real-time constraints, areof paramount importance. In the case of consumer electronics,including entertainment subsystems in cars and airplanes, cellphones, cameras, and games, the concerns are on sound, video,and recording quality and on the look and feel of the devicesin presence of severe cost constraints.

The need for integrating widely different subsystems such assafety, propulsion, communication, and entertainment makesthe Automotive Design Chain very interesting for our purposesand as such, it is an interesting example to expose the chal-lenges in supporting a complex design chain. The Automotivesupply chain includes:

1) Car manufacturers (OEMs) such as Audi, BMW, GM,Ford, Daimler, Renault, PSA, Toyota, and VW, whoprovide the final product to the consumer market.

2) Tier 1 suppliers such as Bosch, Continental, Delphi,Magneti-Marelli, and Nippon-Denso, who provide sub-systems such as powertrain management, suspensioncontrol, and brake-by-wire devices to OEMs.

3) Tier 2 suppliers, e.g., chip manufacturers such asFreescale, Infineon, ST, and Renesas, IP provider e.g.,ARM and RTOS suppliers such as WindRiver andETAS, who serve OEMs and more likely Tier 1 sup-pliers.

4) Manufacturing suppliers such as Flextronics and TSMCwho provide manufacturing services. Opposite to ver-ticals that are not safety critical, liability issues makethe recourse to outside manufacturing not as common.However, there are signs that manufacturing for Tier 1

suppliers is increasingly considered for outsourcing.

Car makers express the desire of gaining a stronger grip on theintegration process and on the critical parts of the electronicssubsystems. At the same time, there is evidence that sharingIPs among car makers and Tier 1 suppliers could improvesubstantially time-to-market, development, and maintenancecosts. The essential technical problem to solve for this vision isthe establishment of standards for interoperability among IPsand tools. AUTOSAR http://www.autosar.org/, a world-wideconsortium of almost all players in the automotive domainelectronics supply chain, has this goal very clear in mind.

However, there are technical and business challenges toovercome. In particular, from the technical point of view, whilesharing algorithms and functional designs seems feasible atthis time, the sharing of hard real-time software is difficulteven assuming substantial improvements in design methodsand technology, if run-time efficiency has to be retained. Theissues are related to the interplay that different tasks can haveat the RTOS level. The timing of the software tasks depend onthe presence or absence of other tasks. A scheduling policy thatcould prevent timing variability in the presence of dynamicalchanging task characteristics can be conceived (for example,timing isolation or resource reservation policies) but it willcarry overhead, albeit potentially not prohibitive; further, thiskind of policy is not supported by any of the commerciallyavailable RTOS. This situation is the standard tradeoff betweenefficiency and reliability but it has more important businessimplications than usual.

In fact, if software from different sources has to be inte-grated on a common hardware platform, in the absence ofcomposition rules and formal verification of the properties ofcomposed systems, who will be responsible for the correctfunctioning of the final product? Whoever will take on thisresponsibility would need a very strong methodology and aniron fist to make suppliers and partners comply with it. Thismay not be enough, in the sense that software characteristicsare hard to pin down and with the best intentions of thisworld, one may not be able to guarantee functional andtiming behavior in the presence of foreign components. Anadditional benefit from a real plug-and-play environment willbe the acceleration of the rate of innovation. For example, if

5

a well-oiled mechanism existed to migrate from one hardwareplatform to another, the optimal solutions would be selectedinstead of the ones that have been traditionally used. In thiscase, the Tier 2 market place will also be rationalized andthe rate of innovation will likely be increased. As a finalconsequence, the introduction of new functionalities will bea matter of algorithm and architecture rather than detailedsoftware and hardware selection. The trend in electronics forthe automotive industry (but for other verticals as well) isclear: less customization, more standardization. For a subsys-tem supplier, the choice will be richer in terms of platformsbut it will not require heavy investment in IC design or RTOSdevelopment. For car manufacturers, the granularity of thechoices will be also richer because of interoperability. Theywill have the choice of selecting entire macro systems orcomponents that could be integrated in a large automotiveplatform. The choice will be guided by cost, quality, andproduct innovation. The final goal of the strategy is ratherclear. The way of getting there is not as clear and the roadhas many bumps and turns that are difficult to negotiate. Apositive outcome will have to come from a process of deepbusiness and technical cooperation among all players in thedesign chain as well as the research community. It is a uniqueopportunity and a great challenge.

C. Capturing and Managing Requirements

We argued that the design chains should connect seamlesslyto minimize design errors and time-to-market delays. Yet,the boundaries among companies are often not as clean asneeded and design specs move from one company to the nextin non-executable and often imprecise forms, thus yieldingmisinterpretations and consequent design errors. In addition,errors are often caught only at the final integration step asthe specifications were not complete and imprecise; further,nonfunctional specifications (e.g., timing, power consumption,size) are difficult to trace.

Requirement engineering is a discipline that aims at improv-ing this situation by paying close attention to the managementof the requirement descriptions (commercial tools such asDOORS are available to carry out this task) and by insertingwhenever possible precise formulation and analysis methodsand tools. Research in this area is active but we believe moreneeds to be done to make this essential step a first classcitizen in system design. Indeed, if the specification qualityis low, then the entire design process is marred since thevery beginning! The overall system product specification issomewhat of an art today since to verify its completeness andits correctness there is little that it can be used to compare with.However, we believe that principles can be stated so that theinitial specification process could be guided in a fairly preciseway and properties related to its “quality” could be assessedusing appropriate tools.

On the other hand, when the specifications are for asubsystem and are derived from previous design steps, thenthe formalization of the specifications is definitely feasiblewith the appropriate efforts and it would go a long way in

improving the customer-provider relationships, it would allowbetter integration and consequently better product quality andtime to market.

D. Product optimization

We believe that since the design process is fragmented,product optimization is rarely carried out across more thanone company boundary and even then, it is limited due to• The lack of appropriate internal and external models that

include both functional and non-functional aspects whichare crucial to evaluate the quality of the design;

• Time pressure to meet the product deadlines;• 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 virtualcompany including all the players shown above, the overallecosystem would greatly benefit. The issue here is to allowa reasonably efficient design space exploration by providinga framework where different architectures could be quicklyassembled and evaluated at each layer of abstraction corre-sponding to the design task being considered in the chain.

E. Risk Management

The complexity of the entire design process and of the rela-tionships between players in the supply chain creates the needto elaborate risk management plans because of the potentialenormity of the impact that design errors and supplier soliditymay have on the economics of a company. Risk managementhas become a requirement of most of public companies inthe Western world where financial, social and political risksare analyzed and appropriate countermeasures have to beprepared as a requirement from the regulatory bodies. In ourdiscussion, risks to be considered are related to the engineeringprocess and countermeasures require the modification of theprocesses themselves. These processes are highly concurrent,distributed, and typically multi-domain engineering processes,often involving more than one hundred sub-processes. Riskmitigation measures typically cover all phases of design pro-cesses, ranging from assuring high quality initial requirementsto early assessments of risks in meeting 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. If we will be able to changethe design process along the lines of more formal approaches,better complexity handling, better requirement engineering,then risks will be substantially lower than they are today.Indeed, the nature of the risks and potential countermeasurescould be factored in the requirement development phase aswell as in detailed product implementation.

F. Moving Forward

System companies had not perceived as yet design method-ology or tools to be on their critical path; hence they had

6

not been willing to invest in expensive tools. Clearly, as theyare hitting a wall in the development of the next generationsystems, this situation is rapidly changing. Major productivitygains are needed and better verification and validation is anecessity as the safety and reliability requirements becomemore stringent and complexity is hitting an all-time high.Our experience is that many of the design chain problemsare typical of very diverse verticals, the difference betweenthem being in the importance given to time-to-market and tothe customer appeal of the products versus safety and hard-time constraints. This consideration motivates the view that aunified methodology and framework could be used in many(if not all) industrial vertical domains.

Our view, shared by the research community, is that anew design science must then be developed to address thechallenges listed above where the physical is married to theabstract, where the world of analog signals is coupled withthe one of digital processing, and where ubiquitous sensingand actuation make our entire environment safer and moreresponsive to our needs. System design should be based onthe new design science to address the industry and societyneeds in a fundamental way. However, the present directionsare not completely clear as the new paradigm has not yetfully emerged in the design community with the strengthnecessary to change the design technology landscape, albeitresearchers have chartered the field with increasing clarity. Wedo believe that system design needs to be concerned about theentire industrial supply chain that spans from customer-facingcompanies to subsystem and component suppliers, since thehealth of an industrial sector depends on the smooth interactionamong the players of the chain as if they were part of the samecompany.

In this paper, it is our goal to offer a new approach tothe system design problem that is rigorous and effective indealing with the problems and challenges described beforeand at the same time, it does not require a radical changein the way industrial designers carry out their task as it cutsacross design flows of different type: contract-based design.The way the approach can be shared in a variety of commondesign methodologies is explained in the following section.

II. ADDRESSING THE CHALLENGES

In this section we revisit the key design challenges facingsystems companies as presented in the introduction, we presentsolutions in place to cope with the challenges and how theconcept of contract can significantly strengthen these solutions.The goals of this section are:

• identifying weaknesses of current industrial practices, and• pointing out how conservative extensions of current pro-

cesses exploiting contracts could tackle these weaknesses,and

• demonstrating that contracts are usable in every designmethodology proposed so far for system design strength-ening it.

A. Contracts in embedded system design: once over lightly

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 thesupplier. Contracts can also be used through their technicalannex in concurrent engineering, when different teams developdifferent subsystems or different aspects of a system withina same company. In our view of the term, contracts can beactually used everywhere and at all stages of system design,from early requirements capture, to embedded computinginfrastructure and detailed design involving circuits and otherhardware. In particular, contracts explicitly handle pairs ofproperties, respectively representing the assumptions on theenvironment and the promises of the system under theseassumptions. More formally, a contract is a pair C = (A,G) of{Assumptions, Promises}, where both A and G are propertiessatisfied by the set of all inputs and all outputs of a design.

Assume/Guarantee reasoning has been known for a longtime, but it has been used as verification mean for the designof software. Our purpose is much more ambitious: contractbased design with explicit assumptions is a design philosophythat should be followed all along the design, with all kindsof models, whenever necessary. Here, the models we meanare rich — not only profiles, types, or taxonomy of data, butalso models describing the functions, performances of variouskinds (time and energy), and safety.

In the following sections, we will review methods to copewith the challenges posed in the introduction underlying theroles of contracts in every approach. It is indeed our take thatthe concept of contract is a unifying view on how to formalizerequirements and rules that appear at all steps of the designprocess.

B. Coping with complexity of systems

Multiple lines of attack have been developed by researchinstitutions and industry to cope with the exponential growthin systems complexity. These are: Viewpoints, Model-baseddevelopment, Virtual integration, Layered design, Component-based design, and Platform-based design. We review themnext.

1) Viewpoints: The key need to view one and the samearchitecture from the perspective of multiple stake-holdersis reflected in the IEEE 1471 recommended practices oforganizing architecture descriptions along views which coverone or more concerns of the stake-holders. A stake-holdercould be an individual, a team, or organization (or collectionsthereof) with interests in, or concerns relative to, the systemunder development. Concerns are seen to be those stake-holderinterests which pertain to the development, operation, or otherkey characteristics of the system (e.g., performance, reliability,security, evolvability, and distribution). Each view, then, givesa complete representation of the system with respect to theset of concerns covered by the view, hence allowing one

7

to demonstrate that the given architecture fully meets stake-holder requirements of the supported class of concerns. Weshall use the term viewpoint to refer to views in the sequel.Based on an assessment by the system companies processesin the CESAR project4 and the German Embedded SystemsInnovation alliance5, and building on the finding of the Inte-grated Project SPEEDS6, viewpoints can be categorized intoperspectives and aspects.

Perspectives are viewpoints relevant to architecture model-ing, as carried out by different stake-holders during the devel-opment process. While the number of perspectives employedmight differ from company to company, the following oneshave been found relevant in the transportation sector:• The operational perspective models the operational con-

text of the system, i.e., the different activities performedby actors with the system.

• The functional perspective models the functional needsof the system and its breakdown into sub-functions, thathence together realize the top-level system functionality.

• The logical perspective constitutes the grouping of thefunctions identified in the functional perspective intoreusable components. Thus, the logical perspective pro-vides the application architecture as a network of reusablefunction components. Resources or properties of thetarget platform are not considered at this point.

• The technical perspective specifies the architecture interms of resources, where the (logical) components shallbe allocated to. In contrast to the logical perspective, inthe technical perspective resource limitations come intoplay. Some resources, such as ECUs, will be shared bymultiple logical components. The actual behavior of thesecomponents will thus also depend on the properties ofthese resources.

• The geometrical perspective7 models the physical layoutof the system. While in the technical perspective someresource is modeled in terms of its properties, its inter-faces and its behavior, in the geometrical perspective itsspatial dimensions and physical are modeled. The geo-metrical perspective deals for example with cable lengths,space limitations, mechanical behavior, thermodynamicalbehavior, and so on.

All these viewpoints share an emphasis on structure, yet fromthe perspectives of different stakeholders/roles in the designprocess, typically from different disciplines, such as• structural engineers being responsible for the structural

design of an aircraft (within the geometric perspective);• the partitioning of mechatronic systems into hydraulic,

mechanical, and EE subsystems, and the refinement oftheir structure and interfaces within the technical perspec-tive, requiring interdisciplinary teams from mechanicaland electrical engineering;

4www.cesarproject.eu5http://spes2020.informatik.tu-muenchen.de6http://www.speeds.eu.com7From its definition, the reader should notice that a more appropriate

naming would rather be physical perspective.

• requirement engineering supporting stakeholder analysiswithin the operational perspective;

• function design supporting the identified requirementswithin the functional perspective by systems engineers

• component design supporting product line developmentand distributed development across the supply chain bygrouping functions into re-usable components by systemsengineers.

To account for this, the meta-model underlying the CESARRTP is able to maintain links such as the satisfy, derive, verify,refine and allocate relationships between design artifacts ofdifferent perspectives and across abstraction layers.

Aspects 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.

• The safety aspect is commonly considered today in thetransportation sector. Safety is concerned with the riskof primary faults and failures, how they could propagatethroughout the system, and what the consequences for theresilience of the overall system would be.

• For some companies, safety often also comprises thefunctions in charge of on-line monitoring and off-lineinspections for maintenance. For other companies, theseare duties collected within the maintainability aspect.

• Depending on the sector, the performance aspect com-prises system performance in terms of overall service,plus environmental footprint and energy costs. It is con-sidered in tradeoff with the cost aspect.

The determination of these extra-functional system character-istics is complex, and can ultimately be done precisely once allperspectives of a system are fully evolved. As an example, thesafety aspect is dependent on an assessment of the criticalityof aircraft functions based on a functional hazard analysis(using the functional perspective of the aircraft), its refinementduring preliminary system-level hazard analysis and system-level hazard analysis is based on the logical and technicalperspective and their interdependency, i.e. the mapping offunctions to components, and components to resources. Onlyby assessing the concrete placement and routing of compu-tation and communication resources is it possible to identifycommon-cause failures resulting from physical intrusion intothe body of the aircraft. In spite of this interdependency,industrial practice shows the efficiency of separating concernsof the analysis of aspects, such as safety above, to one orneighboring perspectives. Indeed, the use of contract-basedaspect specifications allows explicating assumptions whichare otherwise often only established in later phases of thedesign. It is under these assumptions that a demonstrationof the compliance of an architecture to meet aspect-specificrequirements is based. As an example, results of a system-level fault tree analysis may be made subject to assumingindependence of root-causes. These assumptions must thenbe explicitly validated by taking into account allocation ofcomputing and communication resources in the geometric

8

perspective.However, carrying out contract-based aspect analysis early

in the design process comes with the risk of deep iterations inthe design process, where e.g. the fact that safety objectivescannot be realized becomes only evident by taking into ac-count the actual placement of functions on Integrated ModularAvionics (IMA) [7] modules, and their allocation to a particu-lar bay of the aircraft. To mitigate this risk while retainingthe capability of carrying out aspect analysis early in thedesign flow (an essential part of the design methodology wesupport), estimation of the aspects in the final implementationcan be used so that albeit not with 100% confidence, we canexplore effectively the design options minimizing the chancesof discovering late that our early design choices lead to anunfeasible solution. Indeed, the bottom-up characterization ofcomponents in the library of reusable parts advocated byPlatform Based Design is an example of how aspect analysiscan be done early in the design process with appropriateaccuracy guarantees.

2) Layered design: Layered design copes with complexityby focusing on those aspects of the system pertinent to supportthe design activities at the corresponding level of abstraction.This approach is particularly powerful if the details of a lowerlayer of abstraction are encapsulated when the design is carriedout at the higher layer. Layered approaches are well under-stood and standard in many application domains. As an ex-ample, consider the AUTomotive Open System ARchitecture(AUTOSAR), an open and standardized automotive softwarearchitecture, jointly developed by automobile manufacturers,suppliers and tool developers,8 which we will use throughoutthe paper as an industrial reference to discuss contracts andtheir use. This standard defines several abstraction layers.Moving from “bottom” to “top”, the micro-controller abstrac-tion layer encapsulates completely the specifics of underlyingmicro-controllers, the second layer abstracts from the concreteconfiguration of the Electronic Control Unit (ECU), the em-ployed communication services and the underlying operatingsystem, whereas the (highest) application layer is not aware ofany aspect of possible target architectures, and relies on purelyvirtual communication concepts in specifying communicationbetween application components. Similar abstraction levels aredefined by the ARINC standard in the avionic domains.

The benefits of using layered design are manifold. Usingthe AUTOSAR layer structure as example, the completeseparation of the logical architecture of an application (asrepresented by a set of components interconnected using theso-called virtual function bus) and target hardware is a keyaspect of AUTOSAR, in that it supports complete decouplingof the number of automotive functions from the number ofhardware components. In particular, it is flexible enough tomix components from different applications on one and thesame ECU. This illustrates the double role of abstraction lay-ers, in allowing designers to focus completely in this case onthe logic of the application and abstracting from the underlying

8See http://www.autosar.org/

hardware, while at the same time imposing a minimal (oreven no) constraint on the design space of possible hardwarearchitectures. In particular, these abstractions allow re-usingthe application design across multiple platforms, varying innumber of bus-systems and/or number and class of ECUs.These design layers can, in addition, be used to match theboundaries of either organizational units within a company,or to define interfaces between different organizations in thesupply chain.

The challenge, then, rests in providing the proper abstrac-tions of lower-level design entities. which must meet thedouble criteria of, on one hand, being sufficiently detailedto support virtual integration testing even with respect tonon-functional viewpoints on the next higher level, while atthe same time not overly restricting the space of possiblelower-level implementations. As a concrete example, considerthe AUTOSAR application layer and an application requiringguaranteed service under a given failure hypothesis. Suchfailure hypothesis would typically relate both to failures ob-servable on the application layer itself (such as a componentsending an incorrect value, a component flushing its neighborswith unwanted messages), as well as to failures dependingon the underlying (unknown!) target hardware. This points toan inherent dilemma: on one side, the desire of completelyabstracting from the underlying hardware, while at the sametime wishing to perform analysis of properties which inher-ently depend on it.

Using what we call vertical assumptions as abstractions ofthe underlying target hardware can solve this dilemma. Re-turning to the above example, such vertical assumptions couldexplicate the failure hypothesis of either execution platforms orcommunication platforms, and thus decorate either (individualRunnables9) components or entities of the virtual function bus.More general, any logical communication must be seen as a(fictitious) component itself, which, at deployment time, willbe mapped to communication services of the operating system.

3) Component-based design: Whereas layered designs de-compose complexity of systems “vertically”, component-basedapproaches reduce complexity “horizontally” whereby designsare obtained by assembling strongly encapsulated design enti-ties called “components” 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 implementation.While these interface specifications are key and relevant forany system, the “quality attribute” of perceiving a subsystemas a component is typically related to two orthogonal criteria,that of “small interfaces”, and that of minimally constrainingthe deployment context, so as to maximize the potential for re-use. “Small interfaces”, i.e., interfaces which are both smallin terms of number of interface variables or ports, as well

9Runnables are defined in the virtual bus function specifications ofAUTOSAR. Runnable entities are the smallest code-fragments that areprovided by the component and are (at least indirectly) a subject for schedulingby the operating system.

9

as “logically small”, in that protocols governing the invoca-tion of component services have compact specifications notrequiring deep levels of synchronization, constitute evidenceof the success of encapsulation. The second quality attributeis naturally expressible in terms of contract-based 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 contract-based virtual integration testing, asoutlined above.

The second challenge is related to product line design,which allows for the joint design of a family of variants ofa product. The aim is to balance the contradicting goals ofstriving for generality versus achieving efficient componentimplementations. Methods for systematically deriving “quo-tient” specifications to compensate for “minor” differencesbetween required and offered component guarantees by com-posing a component with a wrapper component compensatingfor such differences as characterized by quotient specificationsexists for restricted classes of contracts and restricted classesof component models [29].

4) The V-model of the design process: A widely acceptedapproach to deal with complexity of systems in the defenseand transportation domain is to structure product developmentprocesses along variations of the V diagram shown in Figure 1,originally developed for defense applications by the GermanDoD.10

Safety A

ssesment P

rocess

e.g. Maintainability A

ssessment P

rocess

Softw

areM

echanical

Digital H

ardware

Electrical

e.g. Cost A

ssessment P

rocess

Development of Technology

oriented Architecture

Development of

Logical Architecture

Subsystem

Integration

Development

of ECU

Architecture

Development of

Functional Architecture

Analysis of Product

Level Reqiuirements

Integration

Product

Integration

System

Cer

tific

atio

n

Figure 1. The V Model.

Its characteristic V-shape splits the product developmentprocess into a design and an integration phase. Annotations ofsub-phases of the design-phase were chosen to be consistent

10See e.g. http://www.v-model-xt.de

with perspectives, as discussed in Subsection II-B1. Specifi-cally, following product level requirement analysis, subsequentsteps would first evolve a functional architecture supportingproduct level requirements. Sub-functions are then re-groupedtaking into account re-use and product line requirements into alogical architecture, whose modules can be developed indepen-dently, e.g., by different subsystem suppliers. The realizationof such modules often involves mechatronic design. The top-level of the technology-oriented architecture would then showthe mechatronic architecture of the module, defining interfacesbetween the different domains of mechanical, hydraulic, elec-trical, and electronic system design, such as exemplified belowfor the mechatronic architecture of a simplified aircraft brakingsystem. Subsequent phases would then unfold the detaileddesign for each of these domains, such as the design of theelectronic subsystem involving among others the design ofelectronic control units. These design phases are paralleledby integration phases along the right-hand part of the V,such as integrating basic- and application software on theECU hardware to actually construct the electronic control unit,integrating the complete electronic subsystems, integrating themechatronic subsystem to build the module, and integratingmultiple modules to build the complete product. Not shown,but 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, e.g., a parti-tioning of the aircraft into different subsystems (such asprimary and secondary flight systems, cabin, fuel, and wing),different domains such as the interface of the electronicsubsystem to hydraulic and/or mechanical subsystems, control-law design, telecommunications, software design, hardwaredesign, diagnostics, and development-depth separated designactivities carried out at the OEM and supplier companies.This partitioning of the design space (along perspectives andabstraction layers) naturally lends itself to a parallelization ofdesign activities, a must in order to achieve timely delivery ofthe overall product, leading often into the order of hundredsof concurrent design processes. We elaborate on the role ofcontract-based design to mitigate the risks from concurrentengineering in the section on risk-based design below.

Secondly, each of these sub-processes will have its owndesign basis, as determined by the role of an organization inthe supplier chain. As previously pointed out in the section oflayered design, abstraction levels define, then, what is seen asbasic design-unit at a given level in the supplier hierarchy,such as on the module-level (such as an aircraft- engine),the ECU level (such as in traditional automotive developmentprocesses, where tier 1 suppliers were providing a completeECU implementing a single new vehicle function), or themicroprocessor layer. This approach is further elaborated inthe section on platform-based design below.

10

Third, and tightly linked to the previous item, is the observa-tion, that re-use strategies such as component-based design andproduct line design lead to separate design activities, whichthen short-cut or significantly reduce the effort both in designand integration steps in the individual sub-processes for anindividual product.

Finally, Figure 2 indicates the need of supporting processesfor key viewpoints, such as for safety, where domain stan-dards prescribe activities to be carried out during productdevelopment, which are often anchored with separate rolesin the organization, e.g. Airbus Recommended Practices 4754prescribes the activities in a safety assessment process aswell as its interface to the aircraft development process,ultimately yielding a safety case to be approved by certificationauthorities.

Monitor

2

Command

2

Command

1

Monitor

1

Braking System Control Unit

(BSCU)

AccumulatorReserve

Mechanical

Pedal Position

Wheel

Pow

er 1

Pow

er 2

Ped

al

Pos

ition

1

Ped

al

Pos

ition

2

Green

Pump

Blue

Pump

Isolation

Valve

Shut Off

Selector

Valve

Meter

Valve

Meter

Valve

Anti Skid

Shut Off

Valve

Selector ValveNor

mal

Alte

rnat

e

Anti Skid (AS)

Command (CMD) /

Anti Skid

CD

M /

AS

1

AS

1

AS

2CDM

/ AS

2

1 In

valid

2 In

valid

HYDRAULICELECTRICAL

CO

MP

UT

ER

/ D

IG

IT

AL

MECHANICAL

Figure 2. The technical architecture of an airplane braking system.

Subsequent sections will focus on particular aspects inthe general setting of V-based development processes andelaborate on the role of contract-based design in these.

5) Model-Based Development: Model-based development(MBD) is today generally accepted as a key enabler to copewith complex system design due to its capabilities to supportearly requirement validation and virtual system integration.MBD-inspired design languages and tools such as SysML [26]or AADL [28] for system level modeling, Catia and Modelica[15] for physical system modeling, Matlab-Simulink [22] forcontrol-law design, and UML [5], Scade [4] and TargetLinkfor detailed software design, depend on design layer andapplication class. The state-of-the-art in MBD includes au-tomatic code-generation, simulation coupled with requirementmonitoring, co-simulation of heterogeneous models such asUML and Matlab-Simulink, model-based analysis includingverification of compliance of requirements and specificationmodels, model-based test-generation, rapid prototyping, andvirtual integration testing as further elaborated below.

In MBD today non-functional aspects such as performance,timing, power or safety analysis are typically addressed indedicated specialized tools using tool-specific models, with theentailed risk of incoherency between the corresponding mod-els, which generally interact. To counteract these risks, meta-models encompassing multiple views of design entities, en-abling co-modeling and co-analysis of typically heterogeneousviewpoint specific models have been developed. Examplesinclude the MARTE UML [25] profile for real-time systemanalysis and the Metropolis semantic meta-model [2], [10],[31]. In Metropolis multiple views are accommodated via theconcept of “quantities” that annotate the functional view of adesign and can be composed along with subsystems. Quantitiesare equipped with an “algebra” that allows quantities associ-ated to compositions of subsystems to be computed from thequantities of each of the subsystems. Multiple quantities suchas timing and power can be handled simultaneously. Alongthe same lines, the need to enable integration of point-toolsfor multiple viewpoints with industry standard developmenttools has been the driving force in providing the SPEEDSmeta-model building on and extending SysML, which hasbeen demonstrated to support co-simulation and co-analysisof system models for transportation applications allowing co-assessment of functional, real-time and safety requirements,and forms an integral part of the meta-model-based inter-operability concepts of the CESAR (see www.cesarproject.eu) reference technology platform. The SPEEDS meta-modelbuilding on and extending SysML has been demonstrated tosupport co-simulation and co-analysis of system models fortransportation applications allowing co-assessment of func-tional, real-time and safety requirements. It forms an integralpart of the meta-model-based inter-operability concepts of theCESAR reference technology platform.

6) Virtual Integration: Rather than “physically” integratinga system from subsystems at a particular level of the right-hand side of the V, model-based design allows systems to bevirtually integrated based on the models of their subsystemand the architecture specification of the system. Such virtualintegration thus allows detecting potential integration problemsup front, in the early phases of the V.

Virtual system integration is often a source of heteroge-neous system models, such as when realizing an aircraftfunction through the combination of mechanical, hydraulic,and electronic systems — virtual system integration thenrests on well defined principles allowing the integration ofsuch heterogeneous models. Heterogeneous composition ofmodels with different semantics was originally addressed inPtolemy [14] and Metropolis [2], [10] albeit with differentapproaches. These approaches have then been further elab-orated in the SPEEDS meta-model of heterogeneous richcomponents [9]. Virtual integration involves models of thefunctions, the computer architecture with its extra-functionalcharacteristics (timing and other resources), and the physicalsystem for control. Some existing frameworks offer significantsupport for virtual integration: Ptolemy II, Metropolis, and

11

RT-Builder. Developments around Catia and Modelica as wellas the new offer SimScape by Simulink provide support forvirtual integration of the physical part at an advanced level.

While virtual integration is already well anchored in manysystem companies development processes, the challenge restsin lifting this from the current level of simulation-based analy-sis of functional system requirements to rich virtual integrationtesting catering as well for non-functional requirements. Anapproach to do so is contract-based virtual integration testing,where both subsystems and the complete system are equippedwith multi-viewpoint contracts. Since subsystems now charac-terize their legal environments, we can flag situations, where asubsystem is used out of specification, i.e., in a design context,for which no guarantees on the subsystems reaction can begiven. Our experience from a rich set of industrial applicationsshows that such virtual integration tests drastically reduce thenumber of late integration errors.

Instances of virtual integration tests revealing failed integra-tion early in the V thanks to the use of contracts include:• The lack of a component to provide complete fault isola-

tion (a property presumed by a neighboring subsystem);• The lack of a subsystem to stay within the failure

hypothesis assumed by a neighboring subsystem;• The lack of a subsystem to provide a response within

an expected time-window (a property presumed by aneighboring subsystem);

• The unavailability of a shared resource such as a bus-system in a specified time-window;

• Non-allowed memory accesses;• Glitch rates exceeding specified bounds (a property pre-

sumed by a neighboring subsystem);• Signal strengths not meeting specified thresholds (a prop-

erty presumed by a neighboring subsystem).Multi-viewpoint contracts in virtual integration testing thusdrastically extend the potential of uncovering integration er-rors early. Additionally, using such rich contracts in systemspecification comes with two key benefits, which help dealingwith the complexity in the OEM-supplier relationship.

First, the above approach to virtual integration testing ispurely based on the subsystems contract specifications. Inother words, if virtual integration testing is successful, anyimplementation of a subsystem compliant to this contract spec-ification will not invalidate the outcome of virtual integrationtesting. Note that using this method the IP of subsystemsuppliers is protected — the only evidence required is theconfirmation that their implementation meets the subsystemcontract specification. Second, assuming that the virtual inte-gration test was passed successfully, we can verify whether thesystem itself meets its contract purely based on the knowledgeof the subsystems contract and the systems architecture (andevidence that the subsystem implementation is compliant withthis contract).

This entails that, at any level of the supplier hierarchy, thehigher-level organization can — prior to contracting suppliers— analyze whether the subsystems contracts pass the virtualintegration test and are sufficient to establish the system

requirements. By then basing the contracts to suppliers on thesubsystem contracts, and requiring subsystem suppliers to giveevidence (such as through testing or through formal analysismethods) that their implementation complies to their contract,the final integration of subsystems to the complete system willbe free of all classes of integration errors covered by contractsin the virtual integration test.

C. Coping with the complexity of the supply chain

To ensure coherent product development across complexsupply chains, standardization of design entities, and harmo-nization/standardization of processes are key trends. There aremultiple challenges in defining technical annexes to contractsbetween OEM and suppliers. Specifications used for procure-ment should be precise, unambiguous, and complete. However,a recurrent reason for failures causing deep iterations acrosssupply chain boundaries rests in incomplete characterizationsof the environment of the system to be developed by thesupplier, such as missing information about failure modesand failure rates, missing information on possible sources forinterferences through shared resources, and missing boundaryconditions. This highlights the need to explicate assumptionson the design context in OEM-supplier contracts. In the lightof an increased sharing of hardware resources by applicationsdeveloped by multiple suppliers, this contract-based approachseems indispensable for resolving liability issues and allowingapplications with different criticality levels to co-exist (suchas ASIL levels [] in automotive).

1) Standardization of design entities: By agreeing on (do-main specific) standard representations of design entities,different industrial domains have created their own linguafranca, thus enabling a domain wide shared use of designentities based on their standardized representation. Examplesof these standards in the automotive sector include the recentlyapproved requirement interchange format standard RIF11,the AUTOSAR12 de-facto standard, the OSEK13 operatingsystem standard, standardized bus-systems such as CAN14

and Flexray15, standards for “car2X” communication, andstandardized representations of test supported by ASAM16.Examples in the aerospace domain include ARINC stan-dards17 such as the avionics applications standard interface,IMA, RTCA18 communication standards. In the automationdomain, standards for interconnection of automation devicessuch as Profibus19 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 layers,

11http://www.w3.org/2005/rules/wiki/RIF_Working_Group12http://www.autosar.org/13http://www.osek-vdx.org/14http://www.iso.org/iso/search.htm?qt=Controller+Area+

Network&searchSubmit=Search&sort=rel&type=simple&published=true15http://www.flexray.com/16http://www.asam.net/17http://www.aeec-amc-fsemc.com/standards/index.html18http://www.rtca.org/19http://www.profibus.com/

12

the challenge increases to incorporate all facets of designentities required to optimize the overall product, while at thesame time enabling distributed development in complex supplychains. As an example, to address the different viewpointsrequired to optimize the overall product, AUTOSAR extendedin transitioning from release 3.1 to 4 its capability to capturetiming characteristics of design entities, a key prerequisite forassessing alternate deployments with respect to their impacton timing. More generally, the need for overall system op-timization calls for the standardization of all non-functionalviewpoints of design entities, an objective yet to be achievedin its full generality.

2) Standardization/harmonization of processes: Harmoniz-ing or even standardizing key processes (such as developmentprocesses and safety processes) provides for a further levelof optimization in interactions across the supply chain. As anexample, Airbus Directives and Procedures (ADBs) providerequirements for design processes of equipment manufactures.Often, harmonized processes across the supply chain buildon agreed maturity gates with incremental acceptance testingto monitor progress of supplier development towards finalacceptance, often building on incremental prototypes. Shareduse of Product Lifcycle Management (PLM) [30] databasesacross the supply chain offers further potentials for cross-supply chain optimization of development processes. Also, indomains developing safety related systems, domain specificstandards clearly define the responsibilities and duties ofcompanies across the supply chain to demonstrate functionalsafety, such as in the ISO 2626220 for the automotive domain,IEC 6150821 for automation, its derivatives Cenelec EN 50128and 5012622 for rail, and Do 178 B23 for civil avionics.

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. Similarly,the potential of using formal verification techniques to copewith increasing system complexity is considered in the movefrom DO 178 B to DO 178 C standards.

D. Getting initial requirements right

Depending on application domains, up to 50% of all errorsresult from imprecise, incomplete, or inconsistent and thusunfeasible requirements. Out of the many approaches takenin industry for getting requirements right, we focus here onthose for initial systems requirements, relying on ISO 26262compliant approaches.

To cope with the inherently unstructured problem of(in)completeness of requirements, industry has set up domain-and application-class specific methodologies. As particularexamples, we mention learning process, such as employed

20http://www.iso.org/iso/catalogue_detail.htm?csnumber=4346421http://www.iec.ch/functionalsafety/22http://www.cenelec.eu/Cenelec/CENELEC+in+action/Web+Store/

Standards/default.htm23http://www.do178site.com/

by Airbus to incorporate the knowledge base of externalhazards from flight incidents, the Code of Practice proposedby the Prevent Project using guiding questions to assess thecompleteness of requirements in the concept phase of thedevelopment of advanced driver assistance systems. Use-caseanalysis methods as advocated for UML based developmentprocess follow the same objective. A common theme of theseapproaches is the intent to systematically identify those aspectsof the environment of the system under development whoseobservability is necessary and sufficient to achieve the systemrequirements. Pushing this further again leads to using con-tracts: based on a determined system boundary, responsibilitiesof achieving requirements are split into those to be establishedby the system-under-development (the “guarantees” of thecontract) and those characterizing admissible environmentsof the system-under-development (the “assumptions” of thecontract).

However, the most efficient way of assessing completenessof a set of requirements is by executing it. This consistsin what David Harel called “playing out” for the particularcase of live sequence charts [18], [19], [20], i.e., the use offormalized contract specifications to generate trajectories ofinterface observations compliant with the considered set ofcontracts. Such simulation capabilities turn out to be instru-mental in revealing incompleteness: typically, they will exhibitunexpected traces, e.g., due to an insufficient restriction ofthe environment, or only partially specified system reactions.Executing requirements is only possible if semi-formal orformal specification languages are used, where the particu-lar shape of such formalizations is viewpoint and domaindependent. Examples include the use of failure propagationmodels for safety contracts, the use of probabilistic timedautomata to specify arrival processes, the use of live sequencecharts for capturing scenarios in the interaction of actors andsystems, or formalized requirement languages such as thePSL standard [27] combining temporal logic and automatabased specifications used in the EDA domain, or the pattern-based contract specification language defined by the integratedproject SPEEDS.

In addition, using contracts resting on logic-based for-malisms comes with the advantage, that “spurious” unwantedbehaviors can be excluded by “throwing in” additional con-tracts, or strengthening assumptions, or by considering addi-tional cases for guarantees. A second advantage rests in thecapability of checking for consistency by providing effectivetests, whether a set of contracts is realizable, or whether, incontrast, facets of these are inherently conflicting, and thus noimplementation is feasible.

E. Coping with multi-layer design optimization

System designs are often the result of modifications ofprevious designs with the attempt of minimizing risks andreducing delays and design costs. While this was an effectiveway of bringing new products to market in the past, with theincrease in demand for new functionality and the advances ofthe implementation platforms, this strategy has yielded more

13

problems than it has fixed. Indeed, there is a shared consensusthat in most of the cases the designs are not optimized inthe sense that the full exploitation of the new opportunitiestechnology offers is not achieved and that having visibility ofthe available options and an evaluation framework for designalternatives are a sorely missing capability.

An ideal scenario for optimization is to have access to theentire design space at the lowest possible level of abstractionand then run a global optimization algorithm that could selectthese components satisfying constraints and optimizing mul-tiple criteria involving non-functional aspects of the design.Unfortunately this approach is obviously out of the questionfor most designs given the size of the design space and thecapabilities of optimization algorithms.

What is possible is to select solutions in a pre-selecteddesign space where the number of alternatives to choosefrom is finite and searchable by state-of-the-art optimizationprograms. Indeed, the platform-based design paradigm offersscaffolding that would support this approach. In fact, at anyabstraction layer, we need to optimize with respect to thecomponents of the platform. The selection process will haveto look only at feasible combinations of the components asdictated by the composability contracts.

F. Managing risk across the development process

The realization of complex systems calls for design pro-cesses that mitigate risks in highly concurrent, distributed,and typically multi-domain engineering processes, often in-volving more than one hundred sub-processes. Risk mitigationmeasures 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 version development time and effort:completely 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.

Current practice leads to typically implicit assumptionsabout design aspects to be guaranteed by concurrent processes— designers are “speculating” on outcomes of concurrentengineering sub-processes, based on their experiences fromprevious designs. These assumptions should be made explicit— emphasizing once again the high methodological value ofassumptions — and associate these with risk-levels, whichqualify or quantify the expected risks in not achieving suchassumptions [8]. This very same instrument can be put inplace during the concept phase of development processes,where vertical assumptions form the key basis for assessingrealizability of requirements. We see the following key use-cases for exploiting risk-level labeled assumptions within risk-mitigation strategies, assuming a setting with multi-viewpointcontracts.

• We extend requirements management tool in exploitingthe structure of contracts to maintain a full dependencygraph between guarantees and their supporting assump-tions including risk levels. Prototype implementations ofthis based on the Reqtify product of Geensys (now aDassault company) have been developed in the context ofthe integrated project SPEEDS. This goes beyond currentpractice in its capability to quantify the risk level for theparts of the design which must be modified.

• By monitoring the criticality of risk-levels of assump-tions within individual sub-processes to achieve this sub-processes objectives we can trigger synchronization withprocesses responsible for establishing such assumptionsto reduce their risk-level. Within the integrated projectsSPEEDS, we have developed a process advisor [17] foron-line monitoring the risk-level of assumptions as basisfor advices on such risk-reducing measures.

• We can assess the effect of replacing parts of the designbasis by computing the cumulative risk induced frompartially invalidated assumptions induced by the change,if any. Ideally, the effect of the change can be com-pletely encapsulated by re-establishing the contracts ofthe original design base. If this is not achievable, one canexactly identify the violated assumptions and quantify theresulting risk.

G. Platform-Based Design and Contracts

In the previous sections, we have reviewed a number ofapproaches that tackle the challenges set up in the Introduc-tion. We outlined briefly the use of contracts in each contextand their relevance. The extreme flexibility of contracts allowstheir universal use in all methodologies. It is therefore appeal-ing to anchor the discussion introducing a design methodologythat encompasses all the methods described in the previoussections and exemplify the use of contracts in this framework.This combination will be used in the rest of the paper as thereference design approach.

1) 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 so,support 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 rigorous framework to reasonabout design. Indeed, the concepts have been applied to avariety of very different domains: from automotive, to System-on-Chip, from analog circuit design, to building automation tosynthetic biology.

The basic tenets of platform-based design are as follows:The design progresses in precisely defined abstraction layers;at each abstraction layer, functionality (what the system issupposed to do) is strictly separated from architecture (how

14

the 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 of

• 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.

• Models of the components that represent a characteri-zation in terms of performance and other non-functionalparameters together with the functionality it can support.Not all elements in the library are pre-existing com-ponents. Some may be “place holders” to indicate theflexibility of “customizing” 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.

• 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 architecture.Then, a platform rep-resents a family of designs that satisfies a set of platform-specific constraints. This aspect is related to component-based design enriched with multiple viewpoints.

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 “architecture”(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 AUTOSAR.This 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 designer’screating 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 perspectivesin a general way. The five perspectives presented in the

section II-B1 on viewpoints are indeed special cases of thisgeneral approach.

2) Contract-based design: Contracts in PBD: In PBD,contracts can play a fundamental role in determining thecorrect composition rules so that when the architecture spaceis explored, only “legal” compositions of available compo-nents are taken into consideration. They can be used toverify whether the system obtained by composing the libraryelements according to the horizontal contracts satisfies therequirements posed at the higher level of abstraction. If thesesets of contracts are satisfied, the mapping mechanism of PBDcan be used to produce design refinements that are correct byconstruction.

To be more precise about these concepts that are key forthe rest of the paper, consider a snapshot in a platform baseddesign process, as shown in Figure 3, covering adjacent designlayers N + 1, N , and N − 1. System S is realized at layer Nby the composition of systems S1, S2, and S3.

Figure 3. Contracts in a PBD flow.

Horizontal contracts: In this setting, contracts servedifferent objectives. As highlighted in the subsection on virtualintegration testing, a key value of contracts is to detectintegration errors early. We use the term horizontal contractrelated to virtual integration testing, which thus in Figure 3define under what conditions the integration of subsystemsinto the composite system S is considered successful. Specif-ically, a horizontal contract CH of a system S represents inits assumption AH the constraints it itself imposes on anypossible integration context C[ ], so as to be able to realize itsfunction F .

As an example of this contract-based virtual integrationtesting, consider Figure 3. Each of the subsystems Sj areequipped with horizontal contracts CH(Sj) = (AHj , G

Hj ).

To simplify, we restrict assumptions to be carried by inputports and guarantees to be carried by output ports. The theorydeveloped in companion paper [3] covers the general case butexplanations would be less intuitive. Contract-based virtual

15

integration testing then requires to be able to demonstrate allassumptions AHj from the given design context. For example,let us consider subsystem S2. Its design context is in partgiven by subsystem S1, which thus becomes responsible forestablishing those horizontal assumptions relating to S2´s in-port p21. Intuitively, then, we expect the guarantee GH1 ofthe horizontal contract of S1 to be sufficient to demonstratecompliance of any restrictions S2 was placing on alloweduses of p21. Note also the dependency of S2 on the yetundetermined part of the design context of S2 reflected byinput p3S to the realization of system S on layer N . Ingeneral, then, in contract-based virtual integration testing,this yet unknown design context is represented by horizontalcontracts of the composed system S itself; Figure 3 highlightsthe horizontal contract CHN (S) = (AHN (S), GHN (S)) of S atlayer N . This contract will enforce, that any design contextof S will be guaranteed to be compliant to AHN (S). Thus,when checking the design context of S2 for compliance to itshorizontal assumptions on uses of port p3S , we expect thisto be derivable from AHN (S). In general, then, in contract-based virtual integration testing, we need to demonstrate thatall horizontal assumptions of subsystems can be derived fromthe conjunction of all horizontal guarantees of subsystems andhorizontal assumptions of the composed system.

Circular reasoning: The detailed mathematical formula-tion of this will be discussed in companion paper [3]. However,already at the current level of discourse we point to the fact,that the above argument typically involves circular reasoning.For example, in Figure 3 GH1 will only be guaranteed for legaldesign contexts of S1. Thus, only once AH1 is established,can we actually rest our argumentation on GH1 . Establishing,then, AH1 , we would like to involve GH3 , which, however,is only sound once AH3 is established. This, finally, wouldinvolve GH2 as witness, but it is exactly for the purposeof establishing AH2 , that this reasoning chain is established.The mathematical theory essentially justifies the use of suchseemingly circular arguments, for classes of contracts whoseassumptions and guarantees are expressible in the rich set ofsafety properties (which can always be proven and disprovenby finite observations). However, certain restrictions on howassumptions and guarantees refer to out-ports respectively in-ports of a system have to be observed.

Vertical contracts: Each of the subsystems Sj can theneither be further refined, or assumed to be given as design basisat layer N , as platform library elements. Such components, asS2 in Figure 3, could be placeholders, to be then elaborated ina design process at layer N−1. Symmetrically, Figure 3 showsthe system S at layer N as a realization of the placeholder Sat layer N+1. To transition across design layers, we use whatwe call vertical contracts.

Specifically, when using placeholder S at layer N + 1,bottom-up vertical contracts are used to capture what isexpected to be offered by possible implementations of S atlayer N , so as to be able for S to perform its intended functionat layer N + 1 as expressed by a top-down vertical contract.This entails, that the correctness of the level N + 1 design

hinges on finding an implementation of S meeting this bottom-up vertical contract.

When using budgeting, the designer assigns responsibilitiesto the subsystems of S by deriving top-down contracts foreach, which jointly establish S´s bottom-up vertical contract.Alternatively, when using a bottom-up approach, we assumethe top-down vertical contracts of Sj as given, and establisheither directly or passing through a characterization of thefunctionality realized by S at layer N (as a top-down contract),that the layer N + 1 bottom up contract of S is satisfied. Inboth the top-down and bottom up approach, the verification ofthis cross-layer design steps would assume that the contract-based virtual integration test was successful. This allows usingthe guarantees of horizontal contracts as additional premise inthe verification of refinement steps.

We finally point out that additional verification steps arerequired for each component to demonstrate that, based onthe expected capabilities of its realization, as expressed byits bottom-up vertical contract, the functionality of the com-ponent as expressed by its top-down vertical contract can beachieved. Again, this proof can take horizontal contracts of thecomponent as additional supportive arguments. For composedsystems, such as the system S at layer N in Figure 3, thebottom-up contracts are given by the set of bottom-up contractsof its leaf components.

Crossing design layers thus asks for verification of eitherrefinement (top-down) or aggregation (bottom-up) steps. Thepresentation given so far ignores extensions of the frameworkrequired in practice to deal with what is often called interfacerefinement, e.g., [6], [23]. Due to the very purpose of abstrac-tion layers of hiding complexity, a representation of a design atlevel N will typically explicate implementations aspects suchas representations of messages and variables, protocols usedfor communication and synchronization. In general, both therepresentation of the system in the data-domain as well as inthe time domain may change, calling for notions of refinementwhich are expressive enough to deal both with re-timingand type conversions. The theory for these notions of weaksimulation relations is well understood for particular classes ofmathematical models (see [16]), which jointly are rich enoughto support a broad spectrum of viewpoints, including safety,real-time, performance, power.

To allow to build on these in the methodology for contract-based design, we introduce what we call simulation compo-nents relating traces, i.e. sequences of observations of ports ofa level N + 1 component S to sequences of observations ofports of components S at level N . Referring to Figure 3, thiscomponent would thus have an interface towards layer N + 1observing ports p1S and p2S , and an interface towards layerN observing ports p1S , p2S , and p3S . Simulation componentscan use contracts to characterize the intended inter-relationbetween valuations of these. As discussed in later sections,these contracts can take the form of both logic-based andautomata-based formalisms, giving sufficient expressivity incapturing the intended relations between traces of interfaceobjects of S at level N + 1 and level N .

16

Strong vs. weak assumptions and the issue of compatibil-ity: We close this section by pointing out a subtle, but highlyrelevant, difference in the methodological use of assumptionsin horizontal and vertical contracts. Within horizontal con-tracts, assumptions are used to restrict the allowed design con-text of a component. By enforcing contract-based virtual inte-gration testing, as discussed above, we therefore complementeach model-based integration steps with verification activitiesdemonstrating that the currently known design context C[ ] ofa component S actually complies to these restrictions. Thisis key to enforcing what has been called composability ofsystems by [24], a fundamental principle in good architecturedesign ensuring functionality realized by components of thearchitecture are maintained when integrating these into acompound architecture. It is the purpose of assumptions tosupport this composability property. Specifically, if systemS realizes function F (S) (e.g. as expressed in a top-downvertical contract), and C[ ] meets the contract-based virtualintegration test for S, then S will be guaranteed to offer itsfunctionality F (S) when being put into this design contextC[ ]. We refer to assumptions which must be enforced for thecomponent to behave as expected as strong assumptions.

In contrast, additional assumptions may be added to thestrong assumption to ensure that if these assumptions are met,then “non essential” but desired properties are guaranteed.These additional assumptions are called in contrast weakassumptions. In vertical contracts, in particular in bottom-up contracts, weak assumptions represent anticipations oftenbased on experience or estimation functions on what could beassumed to be realizable by lower implementations levels. Asthe designs refines vertically across multiple layers, eventuallysuch assumptions either become validated based on top-downcontracts of completed designs, or invalidated (e.g. due toinsufficient processing power, non-matching assumptions onfailure distributions, or insufficient signal strength). By main-taining dependency between contracts, it is then possible tobacktrack to the higher-level bottom up assumption which thusbecame invalidated, and explore possibilities of weakening,such as by re-budgeting.

Turning assumptions in vertical contracts to strong assump-tions would entail a binding restriction of the design space:a failure to meet such strong vertical assumptions would beconsidered a contract failure. Strong vertical assumptions canbe used to enforce compliance to standards, or within thesupply chain hierarchy, to eliminate the likelihood of deepdesign iterations crossing organizational boundaries. In a gen-eralized setting, such as currently pushed in the context of theGerman Innovation Alliance for Embedded Systems,24 we thusallow contracts to refer to both strong and weak assumptions,allowing to customize design processes supporting additionaluse cases of strong assumptions as outlined above.

24See SPES2020 Architecture Modeling Deliverable of the German Inno-vation Alliance on Embedded Systems SPES 2020,BMBF grant FK 01 ISO8045 W, http://spes2020.informatik.tu-muenchen.de

H. Moving forward: the importance of contracts

Contracts in their most elementary form may just take theform of informal textual requirements, yet with the key dis-tinguishing feature of explicating the separation of concerns:what must be guaranteed by the system itself, and what are theconstraints on environments, which are fundamentally requiredso as to allow the system — based on such assumptions— to enforce its guarantees. We have then seen how thiscore paradigm matches well with the orthogonal notion ofviewpoints: contracts can thus be flagged as to the view-point they relate to. Clearly, the number of viewpoints tobe supported may vary from application to application —thus it is up to the customization of contract-based designwithin a company’s development process, to determine theset of viewpoints that must be supported. For sure, this willgo beyond capturing the functionality, with safety viewpointsand real-time viewpoints being a necessity in safety relevantembedded systems development. Business related viewpointssuch as the ones reflecting costs, constraints from manufactur-ing, maintainability are natural choices, as are those related toresource consumption.

Orthogonal to this discussion is the degree of formalizationused in contracts. As highlighted above, there is already highmethodological value when using informal contracts. A naturalnext step is to restrict the vocabulary of contracts to (domainspecific) ontologies. Further steps towards formalization areviewpoint dependent: as elaborated in subsequent sections,they can, for example, take the form of automata-basedspecifications, employ suitable logics, build on a library ofpatterns, and capitalize on sequence charts. The additionaleffort in providing a degree of formalization is typicallywell invested due to the additional benefits we have outlinedabove, such as testing consistency of requirements, identifyingcomplex integration errors early through virtual integrationtesting, boosting re-use though component-based design, andallowing cross-layer design optimizations based on performingplatform-based design. The key point we raise is that thisformalization can be done incrementally and on a case-by-case basis. Thus, there is a clear migration strategy from usingcontracts informally, to incorporating domain ontologies, togradually enriching the number of covered viewpoints, and togradually increase the degree of formalization. No matter inwhich order such steps are taken, each of these comes withsignificant potentials for process improvements.

It is the objective of this paper to let designers capitalize onthis so-far largely unexploited tool. The value proposition ofadding contracts to system companies deveLopment processesis now on the table — the ultimate test rests in the market takeup. Strong indications of market acceptance are the anchoringof the contract-based approach within the CESAR 25 ReferenceTechnology Platform (RTP), where 25 European global playersin the systems market team up with leading vendors, researchinstitutes, and SMEs, to create an innovation ecosystem aroundthe emerging standard meta-model of the CESAR RTP.

25www.cesarproject.eu

17

The next section is intended to make examples of contract-based design more concrete by going through the varioussteps of contract-based systems engineering with a simple butsufficiently representative design example.

III. CONTRACTS IN REQUIREMENT ENGINEERING: THEPARKING GARAGE EXAMPLE

In this section we discuss the use of contract-based design asdefined in the previous section in a simple example to exposethe issues related to contracts in the early design phases. Usingthe example, we also outline the need for requirement engi-neering as a prerequisite for using contracts effectively (andfor ANY well-structured design methodology). This exampledeals with the design of a parking system. This example waschosen to be simple but rich enough to cover many issuesrelated to contracts and pinpoint problems raised by the currentpractice and pitfalls that may result.

A. Top-level specification of the example

A parking lot offers a certain amount of physical resourcesto its users (the parking slots). These resources are grantedupon availability. For parking garages that are operated com-mercially, the resource is granted subject to payment that isintended to create a revenue stream to the operator and at thesame time, to regulate the use of the resource.

A top-level specification for the parking garage with itsusers can be stated as follows:

Specification 1 (Top-level specification):1) The parking garage shall offer 500 locations and shall

support a ratio of 10% of entry/exit with respect to thetotal number of locations;

2) Access shall be granted if the parking is not full;3) Fairness shall be enforced in using the resource, i.e., no

user can occupy a parking slot for an indefinite time;4) This is a commercial service, subject to payment.

The top-level specification involves the closed system con-sisting of the parking together with its users. In the earlyphase of the design, this specification should state only veryhigh-level objectives and should not preclude any particulartechnical solution to allow maximal freedom for effectiveimplementation.

Given this top-level specification, the system designer must:1) Explore its feasibility, draw solutions, and derive a

system architecture, and2) Partition the system into subsystems, define require-

ments for the subsystems and establish contracts withthe suppliers.

For our design, we rely on gates for the mechanism of grantingaccess. This step can be considered as a refinement of theoriginal system since additional details are offered for theimplementation of the various processes. A further refinementto define the architecture of the system is related to thepayment process. We can consider two solutions: one wherethe payment is connected to the exit gates, the other wherepayment machines are located in a centralized zone so that the

number of payment stations can be substantially reduced withthe respect to the previous option and so that the gates and thepayment machines could be designed separately. The secondoption was chosen to yield the system architecture of Figure 4.To prepare the contracts with the suppliers, the following set

PaymentUser

ParkingSystem

functionalviewpoint

safetyviewpoint

Figure 4. Parking system top-level architecture. See Section III-I regardingfunctional and safety viewpoints for the Parking.

of requirements is derived by the system designers:Specification 2 (System level derived requirements):1) A user may enter only if the entry gate is open;2) The entry gate may open only if the parking is not full;3) If the user presses the button, then the entry gate may

open and must return a ticket marked with the time ofentrance;

4) The cost of parking is a monotonic function of the timespent in the garage;

5) Parking is not allowed for more than 3 days;6) The user may pay only after having introduced her

ticket;7) [blank]8) The user can pay only with coins;9) The payment machine only accepts coins or credit cards;

10) If the payment is correct, a clearance ticket is returned;11) [blank]12) The clearance ticket is valid for 5 minutes;13) Upon entering a valid clearance ticket, the exit gate

opens;14) A user may exit only if the exit gate is open.

The [blank] are place holders for additional requirements thatwill be discussed in the sequel. Specification 2 must then beallocated to two suppliers—one in charge of the gates andone the payment machines, respectively stipulated as usagerules for users. Beforehand, several tasks must be performed tovalidate Specification 2, i.e., to demonstrate that they providea valid solution to the top-level specification, which must beachieved even if the latter is not stated in formal terms. Wereview these tasks now. The consideration of requirements 8and 9 may seem strange; it is, however, motivated by thediscussion on Section III-H.

B. Domain specific ontology

It is essential that all members of different design teamsagree on a common and unambiguous structured vocabularyfor their specific domain or application area. This is referred toas the domain specific ontology. In our example, see Figure 4,

18

we first identify the different subsystems related to the systemarchitecture: the parking garage, with its entry gates and exitgates; the payment machine; and, finally, the users.

Then, we must identify, in Specification 2, which otherentities are meaningful for the system and its subsystems andhow they are structured: interaction between user and parkinginvolves the entry gates and exit gates; interaction between theuser and the payment machine involves the ticket and payment;interaction between the user, the payment machine, and theexit gate involves the clearance ticket.

Observe that “parking” has a dual meaning, namely theparking with its gate seen as a subsystem, and the actionof parking (in Specification 2.4 and 2.5). If requirements areto be formalized, then these two different meanings must beassigned two different terms. We propose to use the termstaying-in-parking for the latter meaning.

For large documents involving thousands of requirements,building the ontology must be done concurrently with theaction of writing the requirements. This is by no means trivial,but is out of the scope of this paper.

C. Defining and firming up requirements

Since the top-level specification is often informal, gatheringsystem level requirements typically represent the first step ofthe design flow.

Requirements may not faithfully represent the designer’sintent and thus cannot be taken as “the right definition ofthe system”, they must be validated. They are subject toerrors—erroneous requirements are indeed a serious source ofproblems in system design. Therefore, a deep scenario analysiswith a variety of tests should be performed with the goal ofanswering a fundamental question: How good are the statedrequirements in reflecting the designer’s (and users’) intent?

In particular, the process of requirement capture and of writ-ing requirement documents are important matters for discus-sions with certification bodies. These bodies would typicallyassess a number of quality criteria for example, selecting themfrom the following list elaborated by INCOSE [21]: Accuracy,Affordability, Boundedness, Class, Complexity, Completeness,Conciseness, Conformance, Consistency, Correctness, Criti-cality, Level, Orthogonality, Priority, Risk, Unambiguousness,and Verifiability. There are several specific means that can beused to evaluate these criteria.

D. Executing requirements

We insist that analyzing the requirements and verifyingtheir consistency and coverage is essential in any well-formeddesign process, albeit in practice, this step is missing in manyindustrial flows. To do so, the informal textual descriptionshould be converted into a mathematical representation. Sim-ulation and formal verification then can be used to performthese tasks. A mathematical representation allows executingthe requirements. Requirements constrain events, actions, andparameters of the system under design. Executing require-ments is necessary for exploring instances and behaviors ofthese events, actions, and parameters that meet the constraints

imposed by the requirements. This process helps the designerassess the quality of her specification. It is also useful for thedesigner to interact with the customer to assess whether therequirements reflect her expectations.

Executing requirements is, of course, not possible for everytype of requirement even if they are expressed in mathematicalterms; for instance, requirements involving physical character-istics of the system cannot be executed until an implementationis proposed. In the context of our running example, it maybe asked that the gates shall be soft enough not to hurta pedestrian neither to damage a car. Clearly this kind ofrequirement cannot be executed—until the material used inthe construction of the gate and its dynamics behavior (hence,its implementation) are available. Still, a large part of require-ments can generally be executed—all of the requirements inSpecification 2 can once expressed in mathematical form.

E. Identifying responsibilities

Identifying responsibilities in the requirements, i.e., whichactor is supposed to guarantee that the requirements are metand which actor impacts and is impacted by the requirement,allows identifying some implicit assumptions that may becomea source of faulty design. Referring to our running example,analyzing Specification 2, we note that this specificationassumes that the user will not cheat by producing falsifiedtickets that reuse the Id of other tickets—this could allowleaving the parking by paying for 5min while having spentone day; alternatively, a user could use several times a ticketthat has been cleared after payment. Thus, the [blank] placeholders must indeed be filled with the following additionalrequirements to prevent malicious behaviors of the users:

Corrections to Specification 2:7) Only tickets issued by the parking can be inserted in

the payment machine and tickets can be inserted at mostonce;

11) Only clearance tickets issued by the payment machinecan be inserted in the exit gate and clearance tickets canbe inserted at most once.

The pilot trials performed within the SPEEDS EU-project(see http://www.speeds.eu.com) highlighted the central roleof identifying responsibilities and making assumptions explicitin achieving a higher degree of completeness in systemspecification. Note that identifying responsibilities is purelya methodological step and has its value regardless of anyformalization. Table II identifies, for each requirement, whichsubsystem is responsible for satisfying it and which ones areaffected and affect the requirement. The subsystems involvedin the table are ”user”, ”payment” and ”parking”.

F. Partitioning and allocating requirements to subsystems

To allocate requirements to a subsystem, e.g., “payment”,we proceed as follows, using Table II:• Collect from Table II the requirements that are involved

with “payment” but are not under its responsibility—these are R2.7 and R2.8. These are not requirements for

19

Requirement Responsible InvolvedR2.1 user parkingR2.2 parkingR2.3 parking userR2.4 payment userR2.5 userR2.6 payment userR2.7 user paymentR2.8 user paymentR2.9 payment userR2.10 payment userR2.11 user parkingR2.12 parking userR2.13 parking userR2.14 user parking

Table IIIndentifying subsystem (including the “user”) responsible for and the onesinvolved with the requirements. Notation R2.i refers to the ith requirement

among Specification 2.

the “payment” subsystem. Instead, they constitute theassumptions under which the “payment” subsystem mustoperate.

• Collect the requirements that are under the responsibilityof “payment”—these are R2.4, R2.6, R2.9, and R2.10. Theyconstitute the obligations for the “payment” subsystemand are taken as subsystem requirements. To highlight thesymmetry with respect to the assumptions when dealingwith contracts, the obligations above are often calledguarantees. We will stick to this wording in the the restof the paper.

Performing this operations yields the following set of assump-tions and guarantees, thus constituting the contract for the“payment” subsystem. In this and the following contracts,“guarantees” are in italics, whereas “assumptions” are inroman:

Contract 1 (Subsystem “Payment”):4) The cost of staying-in-parking is proportional to the time

spent;6) The user may pay only after having introduced her ticket;7) Only tickets issued by the parking can be inserted in

the payment machine and tickets can be inserted at mostonce;

8) The user pays with coins;9) The payment machine only accepts coins or credit cards;

10) If payment is correct, a clearance ticket is returned.

Contract 2 (subsystem “Parking”):1) A user may enter only if the entry gate is open;2) The entry gate may open only if the parking is not full;3) If the user presses the button, then the entry gate may

open and then must return a ticket marked with the timeof entrance;

11) Only clearance tickets issued by the payment machinecan be inserted in the exit gate and clearance tickets canbe inserted at most once;

12) The clearance ticket is valid for 5 minutes;

13) Upon entering the clearance ticket, the exit gate opens;14) A user may exit only if the exit gate is open.

So far this completes the subsystems’ requirements. The laststep consists of deriving the user’s requirements:

Contract 3 (“User”):1) A user may enter only if the entry gate is open;3) If the user presses the button, then the entry gate may

open and then must return a ticket marked with the timeof entrance;

4) The cost of staying-in-parking is proportional to the timespent;

5) Staying-in-parking is not allowed for more than 3 days;6) The user may pay only after having introduced her ticket;7) Only tickets issued by the parking can be inserted in

the payment machine and tickets can be inserted at mostonce;

8) The user pays with coins;9) The payment machine only accepts coins or credit cards;

10) If payment is correct, a clearance ticket is returned;11) Only clearance tickets issued by the payment machine

can be inserted in the exit gate and clearance tickets canbe inserted at most once;

12) The clearance ticket is valid for 5 minutes;13) Upon entering the clearance ticket, the exit gate opens;14) A user may exit only if the exit gate is open.Assumption 1.7 expresses that the user cannot cheat byfalsifying a ticket in some way. It occurs as a guarantee inContract 3 for the “user”. It is tempting to consider thatstarting with no such assumption as a first step, and thenadding it in a second step after further thinking, is a correctprocess. It is, however, not! Indeed, as we shall later see,it is problematic to strengthen the assumptions made on theenvironment, when updating the requirements for a subsystem(here: the “payment”). Problems may arise at integration levelif this strengthening of assumptions is not forwarded to theother subsystems with which the considered subsystem isinteracting (here: the “user”).

G. Further Refining Requirements

Suppose that the system designer (an OEM) has subcon-tracted the subsystem “parking” to some supplier for itsdesign. Based on her experience in designing parking man-agement systems, this supplier has an off-the-shelf designimplementing a set of assumptions and guarantees consistingof Contract 2 augmented with the following additional as-sumptions and guarantees (we use fresh labels for these, whilekeeping the same convention as before regarding assumptionsversus guarantees):

Contract 4 (Subsystem “Off-the-shelf parking”): This con-tract consists of Contract 2 augmented with the followingassumptions and guarantees:

1) If the user presses the button, the entry gate must openwithin 10 sec;

2) Upon entering the clearance ticket, the exit gate mustopen within 10 sec;

20

3) When the exit gate opens, the user must exit within 10sec;

4) Entry and exit gates are soft enough not to hurt pedes-trians.

The first two additional guarantees refer to the timing behaviorof the gates. The new assumption specifies the timing behaviorof the user. Finally, the last guarantee is related to the parkinghardware. Since the supplier has achieved more with thisoff-the-shelf parking management system, the correspondingdesign can be delivered to the OEM, at least as it seems tobe the case. . .

H. More on Fundamental Properties

At the beginning of this section we mentioned a number ofproperties that qualify the goodness of the requirements docu-ment, these were referred to as INCOSE criteria. A number ofthese criteria are clearly subject to human judgement. Exam-ples of such properties include: Accuracy, Affordability, Level,Priority. However, several INCOSE criteria are more essentialin that they qualify the soundness of both the requirementsdocument and system design flow. We review them next. Thefirst one is related to the completeness of requirements:

Property 1 (Completeness): Are the requirements listed inSpecification 2 complete?Completeness should be defined according to some reference.However, by definition, such a reference does not exist sinceSpecification 2 is the entry point of the design process.Consequently, this question cannot be really formalized inour context, albeit it can be given a formal meaning inother contexts, e.g., for ontologies. Still, completeness can beexplored in practice by executing and analyzing requirementsas explained in Section III-C. Regarding our example, inspec-tion of Specification 2 could reveal that there is a missingrequirement specifying that the gates should be closed after auser enters or exits—to simplify our example we do not addthis missing requirement though.

The second question concerns what it means for a designto satisfy a contract.

Property 2 (Correctness of Designs): What does it meanfor an actual design to satisfy a given contract?

The basic idea is that the design should “satisfy all re-quirements”. While this idea conforms to our proposal thatrequirements belonging to the same document are composedin a conjunctive way, this is not sufficient. We must inparticular handle assumptions and guarantees differently. Avalid understanding of correctness is thus the following: Whena design is inserted in an environment that includes othercomponents of the design as well as external agents, if itsinteractions with the environment satisfy the assumptions, thenthe component is such that its guarantees to the environmentare met.

The next property to be checked concerns the assignment ofrequirements to subsystems: In which sense can we ensure thatreplacing system wide Specification 2 by the composition of

Contracts 1 to 3 is a safe step? Also, was the supplier for theparking right in proposing her off-the-shelf design? These areimportant questions that are typically formulated as follows:

Property 3 (Refinement):1) Does the composition of Contracts 1 to 3 refine Speci-

fication 2?2) Does Contract 4 for the off-the-shelf parking refine the

original Contract 2 for the parking?

Observe that this refinement property resembles the informalrequest of “completeness” that was stated as Property 1. Thedifference here is that system-wide requirements provide themissing reference against which refinement can be assessed.

Each requirement document sets obligations on the con-sidered subsystem (the requirements in italics) and implicitobligations on the environment (the assumptions made by thesubsystem, written in roman). Are these feasible obligations?Note that the same issue arises when we consider the compo-sition of Contracts 1 to 3. This property is generally referredto as “consistency”. We also consider its symmetric propertyof “compatibility” since we distinguished guarantees (to whichthe subsystem is committed) from assumptions (which are theduty of the environment).

Property 4 (Consistency and Compatibility): Do designsexist that meet Contract 1-4 consistency? Do environmentsexist that meet Contract 1-4 compatibility?For example, requirements R2.8 and R2.9 might have been asource of non compatibility for the system wide requirementsdocument—they are, however, compatible as they stand.

Other properties are often requested by certification bodiesregarding requirements engineering. Some of these propertiesconcern ontologies. For example, are the terms used in therequirements capture well defined? are these terms consistentlyused? (This should not be confused with property 4.) Otherproperties concern the design flow. For example, are therequirements verifiable? (Are there ways of and design stepsfor checking these requirements?) While these are importantissues, they are not fundamental to the development of theoriesunderpinning requirements engineering.

I. Requirements and system architectureWhile refining requirements during the design flow, we may

encounter requirements that involve multiple view points, forexample reliability of the design. As an example, consider thefollowing safety (or reliability) viewpoint for the parking:

Contract 5 (subsystem “Parking”, safety viewpoint):1) The probability that a user will cause damage to the

gates is less than 10−10;2) If the parking is not full, the probability that the entry

gate remains closed is less than 10−9;3) If a clearance ticket is entered, the probability that the

exit gate remains closed is less than 10−9.

Observe that we have again assigned responsibilities for thesafety requirements by distinguishing between the “sponta-neous” failures of the gates and the damage caused by theenvironment (the users).

21

The question arises of how to deal with requirements thatinvolve assumptions and guarantees that relate to differentaspects of the design and yet they are to be consideredsomehow together.

Question 1 (Conjunction): What does it mean to structurea contract into a set of viewpoints?

Contracts 2 and 3 involve several assumptions and guarantees.Thus we need to define how these different properties arecombined: since the intent is that “all properties apply”,it is tempting to consider that assumptions and guaranteesare combined in a conjunctive way. This is, however notcorrect in general. Indeed, assumptions and guarantees mustbe handled differently when dealing with two viewpoints. Inother words, assumptions and guarantees must be combinedin specific ways when taking the conjunction of viewpoints,e.g., functions, interfaces, safety, energy, and so on.

An important issue related to viewpoints is to understandwhat should be the meaning of their conjunction. Referringto our running example, we need to deal with the functionrealized by the parking (Contract 2, denoted by Cpark) andits safety requirements (Contract 5, denoted by Cpark_safety).What should their conjunction Cpark_all_viewpoints = Cpark ∧Cpark_safety guarantee? If users respect the rules of usage (nocheating with tickets, no damaging), then all guarantees mustbe met. If, however, users do not cause damage but may cheatwith tickets, then only the safety guarantees will be met. Vice-versa, if users do not cheat with tickets but may cause damage,then only the functional guarantees will be guaranteed. Theimportant point here is that functional and safety viewpointsmust be kept autonomously, considering them jointly shouldnot cause spurious interaction between them. Only necessaryinteractions should remain, corresponding to shared states,events or messages, between their respective contracts.

The next issue is of paramount importance, since it relatesthe subsystems requirements to the systems requirements:

Question 2 (Composition): What is the meaning of assign-ing requirement documents to different subsystems?

Contracts 1 and 2 are documents attached to the differentsubsystems (not including the “user”). The intent is that thesesubsystems will be composed to form the whole system. Howto mirror the composition of subsystems into a correspondingcomposition of requirements documents? It should be clear thatthis new type of composition differs from the conjunction ofrequirements documents, for a same subsystem or component.

Question 1 and 2 discussed in this section are fundamental.Still, to the best of our knowledge, they seem to be ignored inthe current system design practice by both the designers andthe certification bodies. The different questions raised in thissection are further discussed in companion paper [3].

IV. AUTOSAR AND CONTRACTS

In this section, we use AUTOSAR as an industrial exampleof how to leverage contracts within an existing standard toextend it.

Industrial deployment is now on its way and tools arebeing developed and fielded that support the AUTOSARdesign methodology. Modifications to the standard must becarefully weighted against the risk of causing disturbances inthe current critical roll-out phase of Version 4. In dealing withthe issue of introducing the contract-based paradigm withinAUTOSAR, we carefully distinguish between benefits whichcan be achieved based on the current release, and what couldbe additional benefits in future releases. This section benefitsfrom discussions with industrial partners, as well as from theinvolvement of the organizations of some of the authors asAUTOSAR development members.

A. Today - Offering a Smooth Integration of Contract-BasedSystem Engineering with AUTOSAR

The metamodel underlying the CESAR reference technol-ogy platform has been carefully designed to support a seamlessdesign flow from the derivation of high-level requirementsof new automotive functions to the level of detailed appli-cation design defined as entry point in AUTOSAR’s designmethodology. The key for this smooth integration has beenlaid by AUTOSAR itself, notably in the enforcement of theclean separation between application development on one side,and deployment to distributed target architectures, on the otherside. This then enables to capitalize on all the benefits of acontract based design methodology, as long as they are abovethe scope of the AUTOSAR meta model, notably then methodsrelated to improving the quality of initial requirements andhandling complex designs. As to layered design, the jointlandscape covered by CESAR and AUTOSAR can supportsuch design levels at the systems-of-systems levels for Car2Xapplications, all phases for supporting the introduction of newautomotive functions, down to the detailed design level. Aspointed out in the previous section, such phases would build onestablished design processes and currently used design tools,where contracts and viewpoints care conservatively added asadditional flavor to existing design methodologies. The hand-over to AUTOSAR will take place at the detailed design stage,where rich components can then be mapped to the AUTOSARcomponent model, providing the entry point for AUTOSAR’sdesign 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 analysis.Vertical 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 ECUs,communications of the virtual functional bus are mapped to theinter-component communications on the physical architecture.

22

B. The Future - Integrating Contracts in AUTOSAR

The current 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. However,the 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 is about tobecome binding, we see the need for a systematic integrationof the safety viewpoint.

Since we anticipate the addition of a second viewpoint, itis at least worthwhile to weigh the costs for such additionalviewpoint integration against the costs of introducing theconcepts of viewpoints systematically. Doing so will ease theiractivation at times when other market factors such as power-management mandate their introduction. Specifically, we coulduse contracts for both the encapsulation of Basic SoftWare(BSW) modules and the characterization of communicationservices. An ISO 26262 compliant encapsulation would, forinstance, distinguish between BSW modules that (1) contributeto safety ("safety mechanisms") and (2) those that couldpotentially impact system’s safety (by providing their failurepropagation behavior). A typical example for (1) would be thefunction 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 H/W that impacts communication services.

An additional use for contracts is to deal with compliancebetween functional safety, where functions, hazards and safetyfunctions are kept in a (functional) model and safety ofthe AUTOSAR architecture instance guaranteeing that theAUTOSAR implementation - using given safety functions ofthe AUTOSAR architecture - indeed implements the identifiedfunctional safety concept.

C. An Approach for Integrating Contracts in AUTOSAR

The AUTOSAR meta-model is defined as an UML [5]model. It consists of AUTOSAR templates providing thevocabulary that can be used by developers of AUTOSAR basedsystems. For example the Software Component Template26

provides all artifacts necessary for the definition of AUTOSARsoftware components.

To integrate contracts supporting multiple viewpoints, wecan use the mechanism of defining events that refer to elementsof an underlying AUTOSAR model and provide syntax andsemantics of a suitable contract specification language. thataddresses multiple viewpoints. In an intermediate solutionone may keep the introduction of new events (e.g. an event,denoting the point in time when a certain failure condition

26See http://www.autosar.org/index.php?p=3&up=1&uup=0, AUTOSARSpecifications R.4 2009.

TimingDescription

TimingDescriptionEvent

Contract

Assertion

ObservableEvent

View point

+guarantee+weakAssumption+strongAssumption

Figure 5. Conceptual meta-model for integrating contracts in AUTOSAR

becomes active on a software component) separate from theones already defined in the timing extensions and allow multi-viewpoint contracts to refer to both. Figure 5 depicts an excerptof a conceptual meta-model for this intermediate solution. Inthe long-term it may be desirable to harmonize these eventdefinitions, effectively merging them.

D. AUTOSAR Model of an Adaptive Cruise Control Enrichedby Contracts

We illustrate the benefits of contract-based systems engi-neering in AUTOSAR by means of an example: an AdaptiveCruise Control (ACC). With this example we show howrequirements can be refined to contracts and discuss the addedvalue of those contracts for negotiations between OEM andsuppliers. The components and their interfaces of the presentedexample are based on AUTOSAR Specifications R.4 2009.Note that the decomposition of the ACC is not part of theAUTOSAR standard, but is only used for clarification. Withthis example we will illustrate the use of vertical contracts,e.g., to specify the expected latency of the communicationsolution from a timing point of view or a failure hypothesisin terms of reliability. Figure 6 shows the integration of theACC in the Chassis Domain as per AUTOSAR SpecificationsR.4 2009.

VFB

CrsCtrlAndAccSW-Composition

VlcSurrSnsr

ECU Abstraction

ev4ev1

ev3

ev2

…

Figure 6. Integration of the ACC in System-Composition (system view)

1) SW-composition CrsCtrlAndAcc: This SW-Composition shown in Figure 7: specifies the ACC. Itcontrols the velocity of the vehicle and its distance to othervehicles in front of itself (the ego-vehicle). The real interfacenames and ports have been abstracted for the sake of brevity.The DelegationSwConnectors model the delegation of theouter ports of a composition to ports of components beingparts of that composition. The AssemblySwConnectors

23

CrsCtrlAndAcc SW-Composition

Esc

Vlc

…

������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

HardwareComplexDeviceDriver

AccObjTarSeln

CrsCtrlAndAccObsvrForVehSt

CrsCtrlFree

CrsCtrlAndAccStCtrl

Sensor SnsrDaProcGen

(HMI)

FolwCtrlAndAArbnSurrndgsSnsr

(Powertrain)EscEpb....

(Powertrain)EscEpb....

ev1 ev2

ev7

Supplier

ev3

ev5

ev4

ev8

ev9

ev6

Figure 7. ACC as the SW-composition CrsCtrlAndAcc

link the ports of parts of a composition and are subject tocommunication refinement.

The components used in the composition and their functionsare as follows (evx denotes an observable event):• AccObjTarSeln selects target objects (e.g. ahead-

moving vehicles) that are necessary for the ACC tocontrol the velocity of the ego-vehicle and its distanceto vehicles in front of it.

• CrsCtrlFree controls the acceleration of the ego-vehicle depending on the set speed of the driver.

• FolwCtrlAndAArbn controls the acceleration of the ego-vehicle depending on the selected target objects.

• CrsCtrlAndAccStCtrl27 provides the control mode ofthe system and its status. It also determines the state ofthe ACC according to the HMI inputs and the pedals(acceleration and brake) pressed by the driver (ev2). Theoutputs (set speed and time gap) go to the follow andfree cruise controllers (ev7).

• CrsCtrlAndAccObsvrForVehSt28 provides informa-tion about the ego-vehicle, e.g., its speed, steering wheelangle, and curvature of its predicted path.

Non-functional properties of the ACC can be specified bymeans of contracts. In the ISO2002 standard29 performancerequirements on an ACC are specified. The latter could serveas input for such contracts. For example, referring to Figure 7,the time gap — the time required to travel the distance betweenthe ego-vehicle and the forward vehicle — is refined into a la-tency requirement constraining the time between the receptionof a new sensor sample (ev3) and producing a correspondingacceleration value (ev4). As this required latency depends onmany factors like the mass of the vehicle, the used sensors,polling frequency, other ACC design parameters, we simplyassume a fictitious value of 200ms here.

For system integration this becomes part of an end-to-end latency involving the components connected to theCrsCtrlAndAcc composition (cf. Figure 6). The latency can

27Cruise Control and ACC State Machine28Cruise Control and ACC Vehicle State Observer29http://www.iso.org/iso/catalogue_detail?csnumber=31169

only be guaranteed under assumptions about the triggering-frequency. Corresponding contract C1 is shown on Table III.The strong assumption specifies a periodic activation (denoted

strong assumption: ev3 occurs each 500ms with jitter 50msweak assumption: trueguarantee: delay between ev3 and

ev4 within [0ms,200ms]

Table IIICONTRACT C1 FOR CRSCTRLANDACC . TERMS IN BOLDFACE ARE

KEYWORDS OF A PATTERN-BASED LANGUAGE TO SPECIFY CONTRACTS.

by ev3) while the guarantee concerns the end-to-end latency.This end-to-end latency must then be budgeted among thecomponents involved in the composition, for separate imple-mentation by suppliers. The weak assumption is true, whichmeans the context characterized by the strong assumption hasnot been further refined here.

2) Sub-contracting: CrsCtrlAndAccStCtrl andCrsCtrlAndAccObsvrForVehSt have the widest interfaceto other domains and would ideally be developed by the OEMto ensure proper system integration of the SW-compositionCrsCtrlAndAcc. The follow cruise control, the free cruisecontrol, their arbitration and connection to sensor(s) areencapsulated as components, for implementation by suppliers.In a time budgeting process involving OEM and supplier(s)the latency requirement of 200ms is decomposed into smallerslots allocated to the different components involved in thecomposition. The choice of how the timing requirement isdecomposed can be done on estimated figures from previousprojects.

3) Vertical Assumptions on Software Components: Figure8 shows the internal behavior of component AccObjTarSeln.

AccObjTarSeln

Internal Behavior

ev3 ev5

MainRunnable

dataReadAccess dataWriteAccess

ev10 ev11

Figure 8. Internal behavior of AccObjTarSeln-component

This component consists of a single runnableMainRunnable, which reads the sensor values available at itsrequired Sender/Receiver port and provides information aboutthe selected target object on its provided Sender/Receiver

24

port. The depicted events refer to an observable behavior ofthe AccObjTarSeln component. The following events areinvolved:• Event ev3 denotes the reception of a data on the re-

quired Sender/Receiver port of the AccObjTarSeln-component. This data is then available in the commu-nication buffer of the RTE.

• Event ev10 denotes the start of MainRunnable, which ispart of the InternalBehavior of the AccObjTarSeln-component.

• Event ev5 denotes the point in time theAccObjTarSeln-component has successfully sent outthe selected target object on its provided Sender/Receiverport.

• Event ev11 denotes the termination of MainRunnable,which is part of the InternalBehavior of theAccObjTarSeln-component.

Figure 9 shows that some segments of the control flow fromev3 to ev5 cannot be guaranteed by the provider of the SW-component without knowing the system configuration. She canonly specify that MainRunnable shall be triggered when adata element is received at the required Sender/Receiver portby means of RTEEvents and that MainRunnable will send adata item on its provided Sender/Receiver port, e.g. by meansof dataWriteAccess.

COM RTE MainRunnable

Rte_COMCkb

Com_ReceiveSignal

E_OKActivate anOSEK Task

MainRunnable

ev3

ev10 ev11

MainRunnable

OtherRunnable

Task

RTE gluecode

Runnable

ev10

ev11

ev5ev5

Figure 9. Observable events in the BSW-modules COM, OS and the RTE

However the time from ev3 to ev10 depends on the RTE,the RTOS, and their configuration. For example there mightbe a second Runnable that is mapped to the same OSEK task(see Figure 9) and is executed by it prior to MainRunnable.This would extend the latency between ev3 and ev10 by atleast the execution time of the other runnable. In addition theunderlying OSEK task may be preempted by other OSEK taskswith higher priority. Thus, the latency between ev10 and ev5

also depends on the ECU configuration.If implementations of the involved components already exist

for particular ECUs, those latencies can be obtained by anal-ysis and formulated as vertical contracts. Table IV shows theresulting vertical contract C2 for component AccObjTarSeln.When the ECU is configured components in addition to

strong assumption: ev3 occurs each 500ms with jitter 100msdelay between ev3 and,ev10 within [0ms,55ms]delay between ev10 and,ev11 within [0ms,55ms]

weak assumption: trueguarantee: delay between ev3 and,

ev5 within [0ms,120ms]

Table IVCONTRACT C2 FOR COMPONENT ACCOBJTARSELN .

AccObjTarSeln are mapped to the same ECU, the verticalassumptions of timing contracts can be established by meansof schedulability analysis. That analysis would reveal theresponse times, which need to fulfill the vertical assumptions.The vertical assumptions (the 2nd and 3rd strong assumptions)of contract C2 can be used to constrain possible ECU config-urations in advance.

Figure 10, top, sketches a possible outcome of such an ECUconfiguration design step. The components SurrSnsr andAccObjTarSeln are integrated on the same ECU and theirRunnables are mapped to tasks of the OSEK operating system.Especially R1 is mapped to the same task as MainRunnable

and will be executed first. The analysis has to prove that underthe given scheduling strategy this task has a response time ofless than 55ms in order to establish the 2nd vertical assumptionof C2. Further it must be ensured that it takes at most 55msfrom the point in time data is available at the RTE (denotedby ev3) until the task hosting MainRunnable is activated(denoted by ev10).

4) Vertical Assumptions on AssemblySwConnectors:Figure 10, bottom, shows the possible outcome of a sys-tem configuration step. The topology includes two ECUs,which are connected via a Bus (e.g. CAN). The componentsAccObjTarSeln and FolwCtrlAndAArbn, whose ports weredirectly connected in the CrsCtrlAndAcc composition (seeFigure 7), are now mapped to different ECUs. Their connec-tion is mapped onto ISignals, which are handled by the Commodule and packed into I-PDUs (Interaction layer ProtocolData Unit), which in turn may be segmented and reassembledby a transport layer module and finally passed to the bus driverfor transmission in a frame. The configuration of that com-munication stack is specified by means of a “communicationmatrix” defined as part of the system configuration.

With regard to the latency requirements specified in thesystem view (see Figure 6), there must be vertical assump-tions on each AssemblySwConnector. Thus contract C1 ofTable III should actually be enriched by vertical assumptions,thus resulting in the contract C′1 shown on Table V, top.

If the framework used for contracts supports contract con-junction, we can instead consider contract C̃1 shown onTable V, bottom, and then get C′1 = C1 ∧ C̃1. This alternativeway favors modularity in the design and is thus preferred.

25

ECU1

BSW1

RTE1

SurrSnsr AccObjTarSeln

ECU Hardware

Standard IF

CAN-Drv

Com

Standard IF

Standard IF

: Dataflow in BSW-Stack

ev3 ev5

OSEKOS

MainRunnable…R1

: Runnable to task mapping

…

ECUAbstraction

Standard IF

MCAL

BSW1

RTE1

ECU2

BSW2

RTE2

AccObjTarSeln FolwCtrlAndAArbn

ECU Hardware

ECU1

ECU Hardware

Com

Standard IF

Standard IF

CAN-Drv

Standard IF

CAN-Drv

Com

Standard IF

Standard IF

: Dataflow in BSW-Stack and on the Bus

Bus

ev5 ev6

Standard IF

…

…

…

…

…

ev4ev3

…

Figure 10. ECU configuration with mapping of Runnables(top) and SystemConfiguration showing the refinement ofAssemblySwConnectors (bottom).

E. Using Contracts for Safety Specification

Contracts have already been introduced as an harmonicextension to AUTOSAR from the process point of view atthe beginning of this chapter. Furthermore the possibility ofexpressing timing behavior has been demonstrated. Driven bythe need for compliance to the upcoming ISO26262 standard,the safety aspects, especially with respect to contract basedspecification, gained attention. The ISO26262 does not onlyrequire comprehensive checking of requirements but ratherstates explicitly the need for using assumptions on the envi-ronment to develop a safety relevant element on the supplierside (safety element out of context). This fact manifestedin a concept for extending the AUTOSAR methodology andtemplates to directly integrate contracts for safety propertyspecification. Besides the obvious interest in enabling reason-ing on assumptions the focus is also on supporting a widerange of safety analysis like FTA or safety-completeness fromthe AUTOSAR templates without having to rely on externalsources storing requirements and functionality of used counter

C′1:

strong assumption: ev3 occurs each 500ms with jitter 50msdelay between ev5 and,ev6 within [0ms,80ms]

weak assumption: trueguarantee: delay between ev3 and,

ev4 within [0ms,200ms]

eC1:

strong assumption: delay between ev5 and,ev6 within [0ms,80ms]

weak assumption: trueguarantee: true

Table VCONTRACTS C′1 (TOP) AND eC1 (BOTTOM).

C3:strong assumption: {Double_Fault} does not occur.weak assumption: trueguarantee: {Undetected_fail(Vlc_out)} does not occur.

C4:strong assumption: {fail(HMI_in)} does not occur.weak assumption: trueguarantee: {fail(Vlc_out)} does not occur.

C5:strong assumption: {fail(valid)} does not occur.weak assumption: trueguarantee: always(valid == 0 → fail(Vlc_out))

Table VICONTRACTS C3 (TOP) AND REFINED CONTRACTS: C4 AND C5 .

measures and failure propagation rules.We already demonstrated the use of contracts for handling

time budgets and pinning down timing assumptions about ECUand system configuration by means of vertical contracts. Inthe same manner allocations to hardware components and theresulting propagation of hardware failures can be part of thesafety specification.

Figure 11 depicts a small part of the ACC system describedearlier with an added component Monitor. The correspondingcontracts can be found in table VI. In this example the connec-tion between failure modes, counter measures and allocationsshall be demonstrated.

Contract C3 is attached to component CrsCtrlAndAcc andrepresents the safety goal that no undetected failure of thecomponent can occur under the assumption that only onefailure may occur.

Contract C4 is attached to component FolwCtrlAndAArbnand clarifies the failure propagation of the component. In thiscase no design failure of the component is considered to keepthe example simple. The contract states a typical propagation.If there is no failure on the input ports, then there is also nofailure at the output ports.

Contract C5 specifies the Monitor component which hasbeen added to the ACC system in order to have a countermeasure. The monitor gets the input and output of theFolwCtrlAndAArbn component and detects failure in thecalculation.

There are hardware faults assigned to each ECU (contractsnot stated here). In Figure 11 two possible allocations aredepicted. Mapping the two components to the same ECU

26

12

CrsCtrlAndAcc SW-Composition

FolwCtrlAndAArbn

Monitor

HMI_in Vlc_out

valid

ECU1 ECU2

Folw

Ctrl

AndA

Arbn

Mon

itor

ECU1

Folw

CtrlA

ndAA

rbn

Mon

itor

Figure 11. Extract of ACC System

would result in an error during the completeness analysissince the promise that no undetected error can occur would beviolated by the occurrence of the hardware failure of the ECUboth component are mapped to. An allocation to two separateECUs would create a successful completeness analysis result.

With regard to the underlying failure model, contracts canbe translated to various formal representations and verified bymodel checking or SAT engines.

F. Summary and discussion

We have proposed a smooth path for integrating contractsin the context of AUTOSAR at the level of detailed design.We believe that the main aspects for consideration whileintroducing contracts are the handling of time budgets andthe specification of failure modes and failure propagation. Wedid not consider the functional aspect as we think that theOEM would subcontract subsystems to different suppliers onlyif they are loosely, not tightly, coupled from the functionalpoint of view. Vertical contracts were instrumental in handlingtime budgets. Such contracts relate two different layers ofthe AUTOSAR framework. The safety aspect with its design-time part (reliability analysis) and run-time part (On-BoardDiagnosis, OBD2) can be handled using the same philosophy.

Of course, this use of contracts at the level of detailed designcould be complemented with a use of them at the early phaseof requirements capture, following the parking garage exampleof Section III.

V. CONTRACTS AND ANALOG MIXED-SIGNAL CIRCUITDESIGN

In this section, we address how to use contracts for assem-bling analog integrated systems out of pre-designed analog

components. The difficulty in doing so resides in the needof developing the notion of contracts for continuous-timesystems.

A. Analog Circuit Design: Why Are Contracts Important?

Analog, mixed-signal, and RF (AMS-RF) componentsare indispensable parts of many integrated Systems-on-Chip(SoCs). Integration and verification of these blocks in thecomplete system is the bottleneck in terms of design timeand required resources. As both Non-Recurring Engineering(NRE) costs and demands on quick product cycles continueto increase, AMS-RF design productivity must be improved.In particular, structured and rigorous design methodologies athigher levels of abstraction should be developed to overcomecomplexity and take advantage of design reuse.

To address this problem, analog platform-based design(APBD) was introduced in [11], [13] (see Section II-G) asa meet-in-the-middle approach for fast and reliable designspace exploration at the system-level. Circuit components arefirst built and characterized bottom-up by exporting high-levelbehavioral and performance models. System functionalitiesare independently specified and propagated top-down as con-straints on the library of pre-characterized component models.Systems are optimized leveraging global tradeoffs among allcomponents, while ensuring implementation feasibility at thecircuit level. In [33], [32], contracts were introduced intothe design flow to ensure predictable component behaviorafter integration into the system, by accounting for the ex-ternal interface effects on circuit performances. Circuits areconstrained to operate under the same environment as inthe assumptions made during characterization, so that theirbehavior in the system is as close as possible to the one pre-dicted by the component models. Component-level contractsare horizontal since they are enforced among components atthe same abstraction level to guarantee the validity of theircomposition. When composing parts described by integro-differential equations as analog circuits, the difficulty is thatthe behavior of each of the components is affected by thepresence of the other in a substantial way (loading effect)given the lack of the robustness provided by the digitalabstraction: in analog circuits waveforms are essential. Hence,the horizontal contracts have to be carefully defined. Theirrole is to establish the limits on the interface variables of acomponent so that the behavior of the component is withinwhat was expected by the designer. The contracts then will bedefined themselves in general as integro-differential equationsand inequalities.

Horizontal contracts are not sufficient, in general, to guar-antee that the system behaves as specified at higher abstractionlevels. They are intended to make sure that the componentsmaintain their behavior. We need additional constructs tocapture the fact that system architects introduce requirementsto craft the behavior of a chosen architecture according tothe desired functionality. Further, at different design stages,more knowledge about the system is gained, and additionalinformation is incrementally accumulated to refine the system

27

behavior into the desired function. These are top-down verticalrequirements.

When verifying the behavior of mixed-signal systems con-sisting of several potentially complex components, detailedmodels at the transistor level are very difficult to analyze andsimulate. Indeed, experienced designer use simplified macro-models that are intended to capture the relevant behavior ofthe components at higher level of abstraction. In a rigorousdesign methodology, we would like to have guarantees onthe accuracy of the macro-models with respect to models atlower levels of abstraction. The conditions under which thehigher level models are ’faithful’ with respect to the lowerlevel models can be captured by vertical bottom-up contracts.

In the following sections, we define more precisely whatwe described above albeit we refer the interested readers fordetails to [13], [32].

B. Analog Platform-Based Design and Contracts

In APBD, circuits and systems are represented as AnalogPlatforms.

Definition 1: An Analog Platform (AP) consists of a col-lection of:• Variables: inputs u ∈ U ; outputs y ∈ Y; internal signalsx ∈ X ; and configuration parameters κ ∈ K.

• Behavioral model: F(u, y, x, κ) = 0, which is a setof integro-differential equations representing the desiredbehavior of the component.

• Performance feasibility model :

P(y, x) = 1⇔ ∃κ, u, (y, x) = φy(κ, u)

where the classifier P(y, x) denotes the feasible perfor-mance space [12] and φy denotes the mapping obtainedby solving the behavioral model with respect to theoutput and internal variables, also called the performancemapping. This mapping can be computed for a givenvalue of κ and u by a numerical solver, e.g., a circuitsimulator.

• Assumptions: A(u, y, x, κ, δ) ≤ 0, which is a set ofconstraints on the variables of the AP for which bothbehavioral and performance models are guaranteed to bevalid within a set of tolerable margins δ ∈ D. An APmodel is defined to be valid when all assumptions aresatisfied, which guarantees the model outputs correspondto the actual circuit performance within a tolerance dic-tated by δ.a) Horizontal Contracts: Given a set of AP components

at level l, systems can be composed and represented as APs atlevel l+1, which themselves are components for a higher-level.Contracts help ensure component validity during compositionand are defined as follows.

Definition 2: A horizontal contract C for an AP componentis a set of assume/guarantee tuples {ci = (aδi , gi) : i =1, . . . , N} where for each i,

1) aδi is the set of vectors (u,y,x,κ) ∈ U×Y×X×K, thatsatisfies assumption constraints A of the AP component

within the margins δ, where δ defines the assumptionranges.

2) gi is the set of all (y,x) ∈ Y×X , such that aδi |= A =⇒P(gi) = 1, that is, if aδi satisfies A, then gi is containedin the AP performance feasibility model. Clearly, gi canbe also computed by directly executing the behavioralmodel under the condition aδi |= A.

To guarantee that models and compositions are valid, all APassumptions must be satisfied for all components. In particular,only compatible components can be composed to construct ahigher level AP. While we direct interested readers to [33]for a formal definition of compatible components30 we sayinformally that two AP components are compatible if thereexists a set of values for their input, output and internalvariables that satisfy the assumptions of both components andfollow their behavioral and performance feasibility models.However, composition is not, in general, commutative, as alsodiscussed in [33].

The set of all compatible component configurations formthe compatible regions for the APs during composition, whichare the valid search spaces to explore while ensuring that APsremain valid after system construction.

b) Vertical Contracts: System-level assumptions mayresult from several modeling and architectural decisions madeby system architects. As pictured in Figure 13, the desiredbehavior of the system, as dictated by specifications, canalready be translated into a set of constraints, both equalitiesand inequalities, which are independent of any architecture.As soon as an architecture is chosen for exploration, thespecification constraints are further translated into constraintson the selected architecture and its underlying components.At this stage, the architect may already make assumptions tobound the behavior of the chosen architecture to capture thedesired specifications.

As a first step, when no feasibility constraints (verticalbottom-up contracts) are propagated bottom-up, idealizedmodels may be assumed for the components. However, anexperienced designer could already anticipate and account forpossible undesired behaviors or non-idealities, such as loadingeffects, unwanted signal paths and coupling. Additional as-sumptions can then be made this time to minimize the impactof undesired behaviors on the overall system.

Finally, there is clearly a tradeoff between the numberof effects accounted for in a model and its computationalcomplexity. Therefore, assumptions might also be needed toreduce the complexity of the system macro-model used forhigh-level simulation and design exploration, which otherwisemay be too computationally expensive to evaluate or toocomplex to offer intuitive insights.

As a result, several assumptions are aggregated incremen-tally during the system-level specification refinement process.We define these assumptions as system-level assumptions, and

30In [33], compatible components are called consistent components. Wechanged the terminology here, from ’consistent’ and ’consistency’ to ’com-patible’ and ’compatibility’, to align with the definitions developed in theSPEEDS contracts [1]

28

we represent them as a set AS in Figure 12. AS is thenthe set of vectors (uS ,yS ,xS ,κS) ∈ US×YS×XS×KS , thatsatisfies the system-level assumptions within system marginsδS , where uS and yS are the system input and output variables,xS are the system internal variables and κS denotes the systemconfigurations. In APBD the final design is obtained viamapping of the desired specification onto an implementationspace made up of the pre-characterized AP components [13].Mapping is cast as an optimization problem, where a setof performance metrics and quality factors are optimizedover a space constrained by both system requirements andcomponent feasibility constraints. Therefore, to ensure thatcorrect systems are constructed, AS need to be consideredduring the optimization phase. In this presentation, we includethe effect of system-level assumptions by propagating backAS onto the components and their pre-existing horizontalcontracts. This “vertical propagation” step for AS is pictoriallyrepresented in Figure 12.

Let AC be the set of all satisfying vectors for thecomponent-level assumptions, and, similarly, GC be the setof all guarantees of a component. Moreover, let A′C and G′Cbe the compatible assume and guarantee subsets. When AS isprojected onto the space of the component parameters, it gen-erates an additional assumption set A′S . As discussed above,system-level assumptions may be defined in a somewhat inde-pendent fashion with respect to component-level assumptions,so that simply satisfying the consistency conditions of thecomponent-level contracts A′C is not, in general, sufficient tosatisfy A′S . A′C needs to be intersected with A′S and onlyconfigurations in A′′C = A′C ∩ A′S , will guarantee both avalid composition and the desired system behavior. In fact,if G′′C is the set of guaranteed component behaviors under theassumptions A′′C , G′′C ⊆ G′C will necessarily hold by definitionof contracts, and the final composition will be correct. Byprojecting back A′′C and G′′C up to the system-level, wegenerate the new system-level contract as the tuple (A′′S ,GS)where A′′S and GS are obtained from A′′C and G′′C , respectively,after projection. The newly generated system-level contractcan then be used for compositions at higher abstraction levelsthus enabling hierarchical system construction.

Gc

AcA'c A"c

As

G'c

G"c

Gs

Component-Level Contract

System-Level Contract

AssumeSet

GuaranteeSet

A's

A"s

Figure 12. Vertical Propagation of System-level Contracts

C. Contract-Based Design Flow

Component Model

System Model

Optimized System Configuration

Component Design

Select Sample Configurations

Simulate

CharacterizeModel

Define Component Assumptions

ComponentCharacterization

System Specification

Define System Behavior

Select System Architecture

Define System Assumptions

SystemModeling

System Design

Optimization

Design Validation

Figure 13. APBD Design Flow

As shown in Figure 13, in the APBD design flow com-ponent design and characterization is completely orthogonal-ized from system specification and architectural design. APcomponents are built bottom-up satisfying vertical bottom-up contracts to provide component models to a system-leveloptimization engine. On the other side, system constraintscapturing the desired specification are propagated top-down,possibly associated with more abstract system-level behavioralmodels via vertical top-down constraints. The optimizationphase leverages information from both the system and thecomponent levels to evaluate global tradeoffs among compo-nents, while respecting the physical constraints dictated bythe performance feasibility models of the AP components(horizontal contracts). The optimized results are then passedto a validation stage, where the design is verified againstelectrical simulations.

We validated our methodology by using it to optimize aSallen-Key base-band filter for UWB applications. Circuit-level simulation results show that the constructed systemsclosely matches the desired behavior at the system-level, withan average error reduction of 10% for base-band gain and 60%for filter bandwidth, when compared with systems constructedwithout accounting for system-level assumptions. Moreover,the system design could be efficiently configured to satisfyvarious specification sets with high accuracy, which makesour approach suitable to design reuse.

VI. CONCLUDING REMARKS

In this paper, we introduced the concepts underlyingContract-Based Design and its use in a variety of scenar-ios. In particular, we presented the challenges facing facingdesigners of large-scale complex systems today. Then wereviewed the design methodologies and design concepts so farused to address these challenges (viewpoints, layered design,component-based design, the V-model of design, model-baseddevelopment, virtual integration, platform-based design) andshowed how contracts can be used in all these approaches toenhance their applicability and the quality of the final result.Finally, we examined three examples of the use of contracts:

29

one simple example to underline the key steps of contract-based design, one about the use of contracts in enhancing andextending the AUTOSAR automotive standard and one relatedto analog-mixed signal integrated circuit design.

In this paper, central to contracts was the distinction be-tween assumptions and guarantees, mirroring the differentroles and responsibilities in the design of systems. In con-cluding this section, we advocate the need for a mathe-matically sound theory underpinning the use of contracts interms that are more general than the assumption-guaranteeform of contracts to provide solid, unambiguous bases forcontract-based design tools and methods. In fact, we stronglybelieve that any methodology and tool set MUST be basedon solid theoretical foundations to be universally usable andlong lasting. In the companion paper [3] we formalize therequirements for contract theories and present some candidatetheories that satisfy in full or partially the requirements.

REFERENCES

[1] Albert Benveniste and Benoît Caillaud and Alberto Ferrari and LeonardoMangeruca and Roberto Passerone and Christos Sofronis. Contract-Based Specification and Design, 2008. submitted.

[2] F. Balarin, H. Hsieh, L. Lavagno, C. Passerone, A. L. Sangiovanni-Vincentelli, and Y. Watanabe. Metropolis: an integrated electronicsystem design environment. Computer, 36(4), 2003.

[3] A. Benveniste, J.B. Raclet, B. Caillaud, D. Nickovic, R. Passerone,T. Henzinger, and Larsen K. Contracts and Interfaces for the Designof Embedded Systems; Part II: theory. Proceedings of the IEEE, 2011.companion paper.

[4] Gerard Berry. The effectiveness of synchronous languages for the de-velopment of safety-critical systems. White paper, Esterel Technologies,2003.

[5] G. Booch, I. Jacobson, and J. Rumbaugh. The Unified ModelingLanguage User Guide. Addison-Wesley, 1998.

[6] M. Broy. Compositional refinement of interactive systems. Journal ofthe ACM, 44(6):555–600, November 1997.

[7] Henning Butz. The Airbus approach to open Integrated ModularAvionics (IMA): technology, functions, industrial processes and futuredevelopment road map. In International Workshop on Aircraft SystemTechnologies, Hamburg, March 2007.

[8] Werner Damm. Controlling speculative design processes using richcomponent models. In Proceedings of 5th International Conference onApplication of Concurrency to System Design (ACSD), 2005.

[9] Werner Damm, Angelika Votintseva, Alexander Metzner, BernhardJosko, Thomas Peikenkamp, and Eckard Böde. Boosting reuse ofembedded automotive applications through rich components. In Pro-ceedings of FIT 2005 - Foundations of Interface Technologies, 2005.

[10] 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 Jose’, California, 2007.

[11] F. De Bernardinis, S. Gambini, R. Vincis, F. Svelto, A. Sangiovanni-Vincentelli, and R. Castello. Design space exploration for a umts front-end exploiting analog platforms. In ICCAD ’04 Proceedings, pages923–930, 2004.

[12] F. De Bernardinis, M. I. Jordan, and A. Sangiovanni-Vincentelli. Supportvector machines for analog circuit performance representation. In DAC’03 Proceedings, pages 964–969, 2003.

[13] F. De Bernardinis, P. Nuzzo, and A. Sangiovanni-Vincentelli. Mixedsignal design space exploration through analog platforms. In DAC 2005Proceedings, pages 1390–1393, 2005.

[14] Johan Eker, Jörn W. Janneck, Edward A. Lee, Jie Liu, Xiaojun Liu,J. Ludvig, Stephen Neuendorffer, S. Sachs, and Yuhong Xiong. Tamingheterogeneity - the ptolemy approach. Proc. of the IEEE, 91(1):127–144,2003.

[15] Peter Fritzson. Principles of Object-Oriented Modeling and Simulationwith Modelica 2.1. Wiley, 2003.

[16] R. Glabbeek and W. P. Weijland. Branching time and abstraction inbisimulation semantics. Journal of the ACM, 43(3):555–600, 1996.

[17] C. Haerdt and A. Keis. A. model-based integration of analysis services:Experiences with an analysis dashboard. In 3rd Workshop on Model-Driven Tool and Process Integration, 2010.

[18] David Harel, Hillel Kugler, Rami Marelly, and Amir Pnueli. Smartplay-out of behavioral requirements. In FMCAD, pages 378–398, 2002.

[19] David Harel and Rami Marelly. Come, Let’s Play: Scenario-BasedProgramming Using LSCs and the Play-Engine. Springer-Verlag, 2003.http://www.wisdom.weizmann.ac.il/∼harel/ComeLetsPlay.pdf.

[20] David Harel and Itai Segall. Planned and traversable play-out: A flexiblemethod for executing scenario-based programs, . In TACAS, pages 485–499, 2007.

[21] INCOSE. Incose systems engineering handbook, 2010. http://www.incose.org/ProductsPubs/products/sehandbook.aspx.

[22] S. Karris. Introduction to Simulink with Engineering Applications.Orchard Publications, 2006.

[23] Y. Kesten, N. Piterman, and A. Pnueli. Bridging the gap between fairsimulation and trace inclusion. Information and Computing, 200(1):35–61, 2005.

[24] H. Kopetz. Composability in the time-triggered architecture. SAEInternational Congress and Exhibition (2000-01-1382), Detroit, MI,USA, 6-9 March 2000, March 2000.

[25] Object Management Group (OMG), . A UML profile for MARTE, beta1. OMG Adopted Specification ptc/07-08-04, OMG, August 2007.

[26] Object Management Group (OMG), . System modeling languagespecification v1.1. Technical report, OMG, 2008.

[27] The Design Automation Standards Committee of the IEEE Com-puter Society, editor. 1850-2010 - IEEE Standard for Property Specifi-cation Language (PSL). IEEE Computer Society, 2010.

[28] J. Hudak P. Feiler, D. Gluch. The Architecture Analysis and DesignLanguage (AADL): An Introduction. Software Engineering Institute(SEI) Technical Note, CMU/SEI-2006-TN-011, February 2006.

[29] 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.

[30] R. Sudarsan and S.J. Fenves and R.D. Sriram and F. Wang. A productinformation modeling framework for product lifecycle management.Computer-Aided Design, 37:1399–1411, 2005.

[31] 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):54–69, 2009.

[32] X. Sun, A. Puggelli, P. Nuzzo, and A. Sangiovanni-Vincentelli. Verticalpropagation of system-level contracts in analog platform-based design.submitted for publication, 2010.

[33] Xuening Sun, P. Nuzzo, Chang-Ching Wu, and A. Sangiovanni-Vincentelli. Contract-based system-level composition of analog circuits.In Proceedings of 2009 Design Automation Conference, pages 605 –610,jul. 2009.

30