Taming Dr. Frankenstein: Contract-Based Design for …disi.unitn.it/~roby/pdfs/ASVDammPasserone12EJC.pdf · Taming Dr. Frankenstein: Contract-Based Design for Cyber-Physical Systems

European Journal of Control (2012)3:217–238© 2012 EUCADOI:10.3166/EJC.18.217–238

Taming Dr. Frankenstein: Contract-Based Designfor Cyber-Physical Systems∗g

Alberto Sangiovanni-Vincentelli1,3,∗∗, Werner Damm2,4, Roberto Passerone3

1 University of California, Berkeley, CA, USA;2 Kuratorium OFFIS e.V., Oldenburg, Germany;3 DISI, University of Trento, Trento, Italy;4 Carl von Ossietzky University of Oldenburg, Oldenburg, Germany

Cyber-physical systems combine a cyber side (comput-ing and networking) with a physical side (mechani-cal, electrical, and chemical processes). In many cases,the cyber component controls the physical side usingsensors and actuators that observe the physical sys-tem and actuate the controls. Such systems present thebiggest challenges as well as the biggest opportunitiesin several large industries, including electronics, energy,automotive, defense and aerospace, telecommunications,instrumentation, industrial automation.

Engineers today do successfully design cyber-physicalsystems in a variety of industries. Unfortunately, the devel-opment of systems is costly, and development schedulesare difficult to stick to. The complexity of cyber-physicalsystems, and particularly the increased performance thatis offered from interconnecting what in the past have beenseparate systems, increases the design and verificationchallenges. As the complexity of these systems increases,our inability to rigorously model the interactions betweenthe physical and the cyber sides creates serious vulnerabil-ities. Systems become unsafe, with disastrous inexplicablefailures that could not have been predicted. Distributedcontrol of multi-scale complex systems is largely anunsolved problem.

A common view that is emerging in research programsin Europe and the US is “enabling contract-based design(CBD),” which formulates a broad and aggressive scope to

∗∗Correspondence to: A. Sangiovanni-Vincentelli, E-mail: [email protected]

address urgent needs in the systems industry. We presenta design methodology and a few examples in controllerdesign whereby contract-based design can be merged withplatform-based design to formulate the design process as ameet-in-the-middle approach, where design requirementsare implemented in a subsequent refinement process usingas much as possible elements from a library of availablecomponents. Contracts are formalizations of the condi-tions for correctness of element integration (horizontalcontracts), for lower level of abstraction to be consistentwith the higher ones, and for abstractions of availablecomponents to be faithful representations of the actualparts (vertical contracts).

Keywords: Contract, cyber-physical, design methodolo-gies, platform-based, correctness.

1. Introduction

System industry that includes automotive, avionics andconsumer electronics companies are facing significant dif-ficulties due to the exponentially rising complexity of their

∗Paper associated with the semi-plenary lecture of A. Sangiovanni-Vincetelli at the 50th IEEE CDC and ECC 2011, Orlando, FL, USA,December 2011.

Received 14 November 2011Recommended by E.F. Camacho

218 A. Sangiovanni-Vincentelli et al.

products coupled with increasingly tight demands on func-tionality, correctness, and time-to-market. The cost due tobeing late to market or due to imperfections in the productsis staggering as witnessed by the recent recalls and deliv-ery delays that system industries had to bear. There areexamples of the devastating effects that design problemsmay cause.

The specific root causes of these problems are com-plex and relate to a number of issues ranging from designprocesses and relationships with different departmentsof the same company and with suppliers1 to incompleterequirement specification and testing.2

In addition, there is a widespread consensus in theindustry that there is much to gain by optimizing the imple-mentation phase that today is only considering a very smallsubset of the design space. Some attempts at a more effi-cient design space exploration have been afoot but thereis a need to formalize the problem better and to involve inmajor ways the different players of the supply chain. Infor-mation about the capabilities of the subsystems in terms oftiming, power consumption, size, weight and other phys-ical aspects transmitted to the system assemblers duringdesign time would go a long way in providing a betteropportunity to design space exploration.

In this landscape, a wrong turn in a system designproject could cause an important economic, social andorganizational upheaval that may imperil the life of anentire company. No wonder that there is much interestin risk management approaches to assess risks associatedto design errors, delays, recalls and liabilities. Findingappropriate countermeasures to lower risks and to developcontingency plans is then a mainstay of the way largeprojects are managed today. The overarching issue is theneed of a substantive evolution of the design methodologyin use today in system companies. The issue to addressis the understanding of the principles of system design,the necessary change to design methodologies, and thedynamics of the supply chain. Developing this understand-ing is necessary to define a sound approach to the needs ofthe system companies as they try to serve their customersbetter, to develop their products faster and with higherquality.

The focus of this paper is on cyber-physical systems(CPS) [13], [28], [43]. Cyber-physical systems are integra-tions of computation with physical processes. Embeddedcomputers and networks monitor and control the physi-cal processes, usually with feedback loops where physicalprocesses affect computations and vice versa.

1 Toyota sticky accelerator problem came in part from componentsprovided by two contractors whose interaction was not verified appro-priately, Airbus delay problems were in part due to contractors whohad different versions of the CAD software.

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

The emerging applications of cyber-physical systemsare destined to run in distributed form on a platform thatmeshes high performance compute clusters (the infras-tructure core) with broad classes of mobiles in turnsurrounded by even larger swarms of sensors (from thevery large to the microscopic). The broad majority ofthese new applications can be classified as “distributedsense and control systems” that go substantially beyondthe “compute” or “communicate” functions, traditionallyassociated with information technology. These applica-tions have the potential to radically influence how we dealwith a broad range of crucial problems facing our societytoday: for example, national security and safety, includingsurveillance, energy management and distribution, envi-ronment control, efficient and reliable transportation andmobility, and effective and affordable health care. A recur-ring property of these applications is that they engage allthe platform components simultaneously—from data andcomputing services on the cloud of large-scale servers,data gathering from the sensory swarm, and data accesson the mobiles. Another property is that the resulting sys-tems span many scales—in space (from the very large tothe very small), in time (from the very fast to the veryslow), in function (consisting of complex hierarchies ofheterogeneous functionalities), and in technology (inte-grating a broad range of diverse technologies). Each of thecomponents of this distributed platform (compute and dataclusters, mobiles/portables, and sensory systems) forms amulti-scale system on its own, and offers some uniquedesign challenges.

Engineers today do successfully design cyber-physicalsystems in a variety of industries. Unfortunately, the devel-opment of systems is costly, and development schedulesare difficult to stick to. The complexity of cyber-physicalsystems, and particularly the increased performance thatis offered from interconnecting what in the past have beenseparate systems, increases the design and verificationchallenges. As the complexity of these systems increases,our inability to rigorously model the interactions betweenthe physical and the cyber sides creates serious vulnerabil-ities. Systems become unsafe, with disastrous inexplicablefailures that could not have been predicted.

The challenges in the realization and operation of thesemulti-scale systems are manifold, and cover a broad rangeof largely unsolved design and run-time problems. Theseinclude: modeling and abstraction, verification, validationand test, reliability and resiliency, multi-scale technol-ogy integration and mapping, power and energy, security,diagnostics, and run-time management. Failure to addressthese challenges in a cohesive and comprehensive waywill most certainly delay if not prohibit the widespreadadoption of these new technologies.

We believe the most promising means to addressthe challenges in systems engineering of cyber-physical

Contract-Based Design for Cyber-Physical Systems 219

systems is to employ structured and formal design method-ologies that seamlessly and coherently combine the var-ious dimensions of the multi-scale design space (be itbehavior, space or time), that provide the appropriateabstractions to manage the inherent complexity, and thatcan provide correct-by-construction implementations.

The following technology issues must be addressedwhen developing new approaches to system design:

• The overall design flows for heterogeneous systems—meant here both in a technical and also an orga-nizational sense—and the associated use of modelsacross traditional boundaries are not well developed andunderstood.

• The verification of “complex systems,” particularly atthe system integration phase, where any interactionsare complicated and extremely costly to address, isa common need in defense, automotive, and otherindustries.

• Dealing with variability, uncertainty, and life-cycleissues, such as extensibility of a product family, arenot well-addressed using available systems engineeringmethodology and tools.

• System requirement capture and analysis is in large parta heuristic process, where the informal text and natu-ral language-based techniques in use today are facingsignificant challenges. Formal requirement engineeringis in its infancy: mathematical models, formal analysistechniques and links to system implementation must bedeveloped.

• Design-space exploration is rarely performed ade-quately, yielding suboptimal designs where the archi-tecture selection phase does not consider extensibility,re-usability, and fault tolerance to the extent that isneeded to reduce cost, failure rates, and time-to-market.

The design technology challenge is to address theentire process and not to consider only point solutionsof methodology, tools, and models that ease part of thedesign. Addressing this challenge calls for new modelingapproaches that can mix different physical systems, con-trol logic, and implementation architectures. In doing so,existing approaches, models, and tools must be subsumedand not eliminated to ensure that designers can evolvesmoothly their design methods and do not reject the pro-posed design innovations. In particular, a design platformhas to be developed to host the new techniques and tointegrate a set of today’s poorly interconnected tools.

A common view that is emerging in research programsin Europe and the US is “enabling contract-based design,”which formulates a broad and aggressive scope to addressurgent needs in the systems industry. Contracts in the lay-man use of the term are established when an OEM mustagree with its suppliers on the subsystem or componentto be delivered. Contracts involve a legal part binding the

different parties and a technical annex that serves as a ref-erence regarding the entity to be delivered by the supplier.Contracts can also be used through their technical annex inconcurrent engineering, when different teams develop dif-ferent subsystems or different aspects of a system withina same company. In our view of the term, contracts canbe actually used everywhere and at all stages of systemdesign, from early requirements capture, to embeddedcomputing infrastructure and detailed design involvingcircuits and other hardware. In particular, contracts explic-itly handle pairs of properties, respectively representingthe assumptions on the environment and the promises ofthe system under these assumptions. More formally, a con-tract is a pair C = (A, G) of {Assumptions, Promises},where both A and G are properties satisfied by the set ofall inputs and all outputs of a design.

Assume/Guarantee reasoning has been known for quitesome time, but it has been used mostly as verification meanfor the design of software. Our purpose is much moreambitious: contract based design with explicit assump-tions is a design philosophy that should be followed allalong the design, with all kinds of models, whenever nec-essary. Here, the models we mean are rich—not onlyprofiles, types, or taxonomy of data, but also modelsdescribing the functions, performances of various kinds(time and energy), and safety.

To make contract-based design a technique of choicefor system engineers, we must develop:

• Mathematical foundations for contract representationand requirement engineering that enable the design offrameworks and tools;

• A system engineering framework and associatedmethodologies and tool sets that focus on systemrequirement modeling, contract specification, and veri-fication for cyber-physical systems at multiple abstrac-tion layers.

• A systems engineering framework focusing on cross-boundary design flows that include addressing theorganizational impacts of contract design and the evo-lution over time of systems, including configurationmanagement.

In this paper, it is our goal to describe contract-baseddesign in the context of system level design.

In the following sections, we will review methods tocope with the challenges posed in the introduction. It isindeed our take that the concept of contract is a unify-ing view on how to formalize requirements and rules thatappear at all steps of the design process. Then, we will pro-vide a short formalization of the notion of contract. Armedwith this notion, we show how to combine contracts withplatform-based design to encompass all other methods.We present a simple control problem to demonstrate theuse of the proposed methodology and we close the paper


presenting potential developments that could make the useof contracts pervasive in industry.

2. Addressing the System DesignChallenges: Methodologies

System companies have not yet perceived design method-ology or tools to be on their critical path; hence they havenot been willing to invest in expensive tools. Clearly, asthey are hitting a wall in the development of the nextgeneration systems, this situation is rapidly changing.Major productivity gains are needed and better verificationand validation is a necessity as the safety and reliabilityrequirements become more stringent and complexity is hit-ting an all-time high. Our experience is that many of thedesign chain problems are typical of very diverse verti-cals, the difference between them being in the importancegiven to time-to-market and to the customer appeal of theproducts versus safety and hard-time constraints. This con-sideration motivates the view that a unified methodologyand framework could be used in many (if not all) industrialvertical 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 tothe abstract, where the world of analog signals is coupledwith the one of digital processing, and where ubiquitoussensing and actuation make our entire environment saferand more responsive to our needs. System design shouldbe based on the new design science to address the indus-try and society needs in a fundamental way. However,the present directions are not completely clear as the newparadigm has not yet fully emerged in the design com-munity with the strength necessary to change the designtechnology landscape, albeit researchers have charteredthe field with increasing clarity. We do believe that systemdesign needs to be concerned about the entire industrialsupply chain that spans from customer-facing companiesto subsystem and component suppliers, since the healthof an industrial sector depends on the smooth interactionamong the players of the chain as if they were part ofthe same company. In this section we review some of theproposed system-design methods in place to cope withthese challenges, from the point of view of the system,the supply chain, and the development process includingrequirement capture and optimization.

2.1. Coping with Complexity of Systems

Multiple lines of attack have been developed by researchinstitutions and industry to cope with the exponentialgrowth in systems complexity, starting from the iterativeand incremental development several decades ago [27].

Among them, of particular interest to the development ofembedded controllers are: Layered design, Component-based design, the V-model process, Model-based devel-opment, Virtual integration and Platform-Based Design.We review them next.

2.1.1. Layered Design

Layered design copes with complexity by focusing onthose aspects of the system pertinent to support the designactivities at the corresponding level of abstraction. Thisapproach is particularly powerful if the details of a lowerlayer of abstraction are encapsulated when the design iscarried out at the higher layer. Layered approaches are wellunderstood and standard in many application domains.As an example, consider the AUTOSAR standard.3. Thisstandard defines several abstraction layers. Moving from“bottom” to “top”, the micro-controller abstraction layerencapsulates completely the specifics of underlying micro-controllers, the second layer abstracts from the concreteconfiguration of the Electronic Control Unit (ECU), theemployed communication services and the underlyingoperating system, whereas the (highest) application layeris not aware of any aspect of possible target architectures,and relies on purely virtual communication concepts inspecifying communication between application compo-nents. Similar abstraction levels are defined by the ARINCstandard 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 usingthe so-called virtual function bus) and target hardware isa key aspect of AUTOSAR, in that it supports completedecoupling of the number of automotive functions fromthe number of hardware components. In particular, it isflexible enough to mix components from different applica-tions on one and the same ECU. This illustrates the doublerole of abstraction layers, in allowing designers to focuscompletely in this case on the logic of the application andabstracting from the underlying hardware, while at thesame time imposing a minimal (or even no) constraint onthe design space of possible hardware architectures. Inparticular, these abstractions allow the application designto be re-used across multiple platforms, varying in numberof bus-systems and/or number and class of ECUs. Thesedesign layers can, in addition, be used to match the bound-aries of either organizational units within a company, orto define interfaces between different organizations in thesupply chain.

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


The challenge, then, rests in providing the properabstractions of lower-level design entities. which mustmeet the double criteria of, on one hand, being sufficientlydetailed to support virtual integration testing even withrespect to non-functional viewpoints on the next higherlevel, while at the same time not overly restricting thespace of possible lower-level implementations. As a con-crete example, consider the AUTOSAR application layerand an application requiring guaranteed service under agiven failure hypothesis. Such failure hypothesis wouldtypically relate both to failures observable on the applica-tion layer itself (such as a component sending an incorrectvalue, a component flushing its neighbors with unwantedmessages), as well as to failures depending on the underly-ing (unknown!) target hardware. This points to an inherentdilemma: on one side, the desire of completely abstract-ing from the underlying hardware, while at the same timewishing to perform analysis of properties which inherentlydepend on it.

Using what we call vertical assumptions as abstractionsof the underlying target hardware can solve this dilemma.Returning to the above example, such vertical assumptionscould explicate the failure hypothesis of either executionplatforms or communication platforms, and thus deco-rate either (individual Runnables4) components or entitiesof the virtual function bus. In more general terms, anylogical communication must be seen as a (fictitious) com-ponent itself, which, at deployment time, will be mappedto communication services of the operating system.

2.1.2. Component-Based Design

Whereas layered designs decompose complexity of sys-tems “vertically”, component-based approaches reducecomplexity “horizontally” whereby designs are obtainedby assembling strongly encapsulated design entities called“components” equipped with concise and rigorous inter-face specifications. Re-use can be maximized by findingthe weakest assumptions on the environment sufficient toestablish the guarantees on a given component implemen-tation. While these interface specifications are key andrelevant for any system, the “quality attribute” of perceiv-ing a subsystem as a component is typically related to twoorthogonal criteria, that of “small interfaces”, and that ofminimally constraining the deployment context, so as tomaximize the potential for re-use. “Small interfaces”, i.e.,interfaces which are both small in terms of number of inter-face variables or ports, as well as “logically small”, in thatprotocols governing the invocation of component services

4 Runnables are defined in the virtual bus function specifications ofAUTOSAR. Runnable entities are the smallest code-fragments thatare provided by the component and are (at least indirectly) a subjectfor scheduling by the operating system.

Fig. 1. The V model.

have compact specifications not requiring deep levels ofsynchronization, constitute evidence of the success ofencapsulation. The second quality attribute is naturallyexpressible in terms of interface specifications, where re-use can be maximized by finding the weakest assumptionson the environment sufficient to establish the guaranteeson a given component implementation.

One challenge, then, for component-based design ofembedded systems, is to provide interface specificationsthat are rich enough to cover all phases of the designcycle. This calls for including non-functional character-istics as part of the component interface specifications,which is best achieved by using multiple viewpoints. Cur-rent component interface models, in contrast, are typicallyrestricted to purely functional characterization of compo-nents, and thus cannot capitalize on the benefits of virtualintegration testing, as outlined 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 compo-nent implementations. Methods for systematically deriv-ing “quotient” specifications to compensate for “minor”differences between required and offered component guar-antees by composing a component with a wrapper compo-nent (compensating for such differences as characterizedby quotient specifications) exists for restricted classes ofcomponent models [36].

2.1.3. The V-Model of the Design Process

A widely accepted approach to deal with complexity ofsystems in the defense and transportation domain is tostructure product development processes along variationsof the V diagram shown in Fig. 1, originally developed fordefense applications by the German DoD.5

Its characteristic V-shape splits the product develop-ment process into a design and an integration phase.

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


Specifically, following product level requirement anal-ysis, subsequent steps would first evolve a functionalarchitecture supporting product level requirements. Sub-functions are then re-grouped taking into account re-useand product line requirements into a logical architec-ture, whose modules can be developed independently,e.g., by different subsystem suppliers. The realization ofsuch modules often involves mechatronic design. The top-level of the technology-oriented architecture would thenshow the mechatronic architecture of the module, defininginterfaces between the different domains of mechanical,hydraulic, electrical, and electronic system design, suchas exemplified below for the mechatronic architecture ofa simplified aircraft braking system. Subsequent phaseswould then unfold the detailed design for each of thesedomains, such as the design of the electronic subsysteminvolving among others the design of electronic controlunits. These design phases are paralleled by integrationphases along the right-hand part of the V, such as integrat-ing basic- and application software on the ECU hardwareto actually construct the electronic control unit, integrat-ing the complete electronic subsystems, integrating themechatronic subsystem to build the module, and integrat-ing multiple modules to build the complete product. Notshown, but forming an integral part of V-based devel-opment processes are testing activities, where at eachintegration level test-suites developed during the designphases are used to verify compliance of the integratedentity to their specification.

This presentation is overly simplistic in many ways.The design of electronic components in complex systemssuch as aircrafts inherently involves multi-site, multi-domain and cross-organizational design teams, reflecting,e.g., a partitioning of the aircraft into different sub-systems (such as primary and secondary flight systems,cabin, fuel, and wing), different domains such as theinterface of the electronic subsystem to hydraulic and/ormechanical subsystems, control-law design, telecommu-nications, software design, hardware design, diagnostics,and development-depth separated design activities carriedout at the OEM and supplier companies. This partitioningof the design space (along perspectives and abstractionlayers) naturally lends itself to a parallelization of designactivities, a must in order to achieve timely delivery of theoverall product, leading often into the order of hundredsof concurrent design processes.

Secondly, each of these sub-processes will have its owndesign basis, as determined by the role of an organizationin the supplier chain. As previously pointed out in thesection of layered design, abstraction levels define, then,what is seen as basic design-unit at a given level in thesupplier hierarchy, such as on the module-level (such asan aircraft- engine), the ECU level (such as in traditionalautomotive development processes, where tier 1 suppliers

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

were providing a complete ECU implementing a singlenew vehicle function), or the microprocessor layer. Thisapproach is further elaborated in the section on platform-based design below.

Third, and tightly linked to the previous item, is theobservation, that re-use strategies such as component-based design and product line design lead to separatedesign activities, which then short-cut or significantlyreduce the effort both in design and integration steps inthe individual sub-processes for an individual product.

Finally, Fig. 2 indicates the need of supporting pro-cesses for key viewpoints, such as for safety, wheredomain standards prescribe activities to be carried out dur-ing product development, which are often anchored withseparate roles in the organization, e.g., Airbus Recom-mended Practices 4754 prescribes the activities in a safetyassessment process as well as its interface to the aircraftdevelopment process, ultimately yielding a safety case tobe approved by certification authorities.

2.1.4. Model-Based Development

Model-based development (MBD) is today generallyaccepted as a key enabler to cope with complex systemdesign due to its capabilities to support early require-ment validation and virtual system integration. MBD-inspired design languages and tools such as SysML6 [33]and/or AADL [35] for system level modeling, Catia andModelica [18] for physical system modeling, Matlab-Simulink [23] for control-law design, and UML7 [7], [31]Scade [6] and TargetLink for detailed software design,depend on design layer and application class. The state-of-the-art in MBD includes automatic code-generation,simulation coupled with requirement monitoring, co-simulation of heterogeneous models such as UML and

6 http://www.omg.org/spec/SysML/7 http://www.omg.org/spec/UML/


Matlab-Simulink, model-based analysis including verifi-cation of compliance of requirements and specificationmodels, model-based test-generation, rapid prototyping,and virtual integration testing as further elaborated below.

In MBD today non-functional aspects such as perfor-mance, timing, power or safety analysis are typicallyaddressed in dedicated specialized tools using tool-specific models, with the entailed risk of incoherencybetween the corresponding models, which generally inter-act. To counteract these risks, meta-models encompassingmultiple views of design entities, enabling co-modelingand co-analysis of typically heterogeneous viewpoint spe-cific models have been developed. Examples include theMARTE UML [32] profile for real-time system analysis,the SPEEDS HRC metamodel [37] and the Metropolissemantic meta-model [2], [3], [11], [41]. In Metropo-lis multiple views are accommodated via the concept of“quantities” that annotate the functional view of a designand can be composed along with subsystems. Quanti-ties are equipped with an “algebra” that allows quantitiesassociated to compositions of subsystems to be computedfrom the quantities of each of the subsystems. Multi-ple quantities such as timing and power can be handledsimultaneously. Along the same lines, the need to enableintegration of point-tools for multiple viewpoints withindustry standard development tools has been the driv-ing force in providing the SPEEDS meta-model buildingon and extending SysML, which has been demonstrated tosupport co-simulation and co-analysis of system modelsfor transportation applications allowing co-assessment offunctional, real-time and safety requirements, and formsan integral part of the meta-model-based inter-operabilityconcepts of the CESAR (see www.cesarproject.eu) ref-erence technology platform. The SPEEDS meta-modelbuilding on and extending SysML has been demonstratedto support co-simulation and co-analysis of system mod-els for transportation applications allowing co-assessmentof functional, real-time and safety requirements. It formsan integral part of the meta-model-based inter-operabilityconcepts of the CESAR reference technology platform.

Meta-modeling is also at the center of the model driven(software) development (MDD) methodology. MDD isbased on the concept of the model-driven architecture(MDA), which consists of a Platform-Independent Model(PIM) of the application plus one or more Platform-Specific Models (PSMs) and sets of interface defini-tions. MDA tools then support the mapping of the PIMto the PSMs as new technologies become available orimplementation decisions change [30]. This is similar toPlatform-Based Design, however the definition of plat-form is not fully described in MDD nor are the semanticsto be used for embedded software design. The VanderbiltUniversity group [24] has evolved an embedded soft-ware design methodology and a set of tools based on

MDD. In their approach, models explicitly represent theembedded software and the environment it operates in andcapture the requirements and the design of the application,simultaneously, using domain-specific languages (DSL).The generic modeling environment (GME) [24] providesa framework for model transformations enabling easyexchange of models between tools and offers sophisticatedways to support syntactic (but not semantic) heterogene-ity. The KerMeta metamodeling workbench [17] is similarin scope.

2.1.5. Virtual Integration

Rather than “physically” integrating a system from sub-systems at a particular level of the right-hand side ofthe V, model-based design allows systems to be virtu-ally integrated based on the models of their subsystemand the architecture specification of the system. Such vir-tual integration thus allows detecting potential integrationproblems up front, in the early phases of the V.

Virtual system integration is often a source of hetero-geneous system models, such as when realizing an air-craft function through the combination of mechanical,hydraulic, and electronic systems—virtual system inte-gration then rests on well defined principles allowing theintegration of such heterogeneous models. Heterogeneouscomposition of models with different semantics was orig-inally addressed in Ptolemy [16] and Metropolis [2], [11],[3] albeit with different approaches. These approacheshave then been further elaborated in the SPEEDS meta-model of heterogeneous rich components [10]. Virtualintegration involves models of the functions, the computerarchitecture with its extra-functional characteristics (tim-ing and other resources), and the physical system for con-trol. Some existing frameworks offer significant supportfor virtual integration: Ptolemy II, Metropolis, and 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 anchoredin many system companies development processes, thechallenge rests in lifting this from the current level ofsimulation-based analysis of functional system require-ments to rich virtual integration testing catering as wellfor non-functional requirements. An approach to do so iscontract-based virtual integration testing, where both sub-systems and the complete system are equipped with multi-viewpoint contracts. Since subsystems now characterizetheir legal environments, we can flag situations, where asubsystem is used out of specification, i.e., in a design con-text, for which no guarantees on the subsystems reactioncan be given. Our experience from a rich set of indus-trial applications shows that such virtual integration testsdrastically reduce the number of late integration errors.


Instances of virtual integration tests revealing failedintegration early in the V 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 failurehypothesis assumed by a neighboring subsystem;

• The lack of a subsystem to provide a response withinan 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

presumed by a neighboring subsystem);• Signal strengths not meeting specified thresholds (a

property presumed by a neighboring subsystem).

First, the above approach to virtual integration testingis purely based on the subsystems contract specifica-tions. In other words, if virtual integration testing issuccessful, any implementation of a subsystem compli-ant to this contract specification will not invalidate theoutcome of virtual integration testing. Note that usingthis method the IP of subsystem suppliers is protected—the only evidence required is the confirmation that theirimplementation meets the subsystem contract specifica-tion. Second, assuming that the virtual integration testwas passed successfully, we can verify whether the systemitself meets its contract purely based on the knowledge ofthe subsystems contract and the systems architecture (andevidence that the subsystem implementation is compliantwith this contract).

This entails that, at any level of the supplier hierarchy,the higher-level organization can—prior to contractingsuppliers—analyze whether the subsystems contracts passthe virtual integration test and are sufficient to establishthe system requirements. By then basing the contracts tosuppliers on the subsystem contracts, and requiring sub-system suppliers to give evidence (such as through testingor through formal analysis methods) that their implemen-tation complies to their contract, the final integration ofsubsystems to the complete system will be free of allclasses of integration errors covered by contracts in thevirtual integration test.

2.2. Coping with the Complexity of the SupplyChain

To ensure coherent product development across com-plex supply chains, standardization of design entities,and harmonization/standardization of processes are keytrends. There are multiple challenges in defining technical

annexes to contracts between OEM and suppliers. Spec-ifications used for procurement should be precise, unam-biguous, and complete. However, a recurrent reason forfailures causing deep iterations across supply chain bound-aries rests in incomplete characterizations of the environ-ment of the system to be developed by the supplier, such asmissing information about failure modes and failure rates,missing information on possible sources for interferencesthrough shared resources, and missing boundary condi-tions. This highlights the need to explicate assumptions onthe design context in OEM-supplier contracts. In the lightof an increased sharing of hardware resources by applica-tions developed by multiple suppliers, this contract-basedapproach seems indispensable for resolving liability issuesand allowing applications with different criticality levelsto co-exist (such as ASIL levels [42], [1] in automotive).

2.2.1. Standardization of Design Entities

By agreeing on (domain specific) standard representationsof design entities, different industrial domains have cre-ated their own lingua franca, thus enabling a domain wideshared use of design entities based on their standardizedrepresentation. Examples of these standards in the auto-motive sector include the recently approved requirementinterchange format standard RIF,8 the AUTOSAR9 de-facto standard, the OSEK10 operating system standard,standardized bus-systems such as CAN11 and Flexray,12

standards for “car2X” communication, and standardizedrepresentations of test supported by ASAM.13 Exam-ples in the aerospace domain include ARINC standards14

such as the avionics applications standard interface, IMA,RTCA15 communication standards. In the automationdomain, standards for interconnection of automationdevices such as Profibus16 are complemented by standard-ized design languages for application development suchas Structured Text.

As standardization moves from hardware to operatingsystem to applications, and thus crosses multiple designlayers, the challenge increases to incorporate all facetsof design entities required to optimize the overall product,while at the same time enabling distributed development incomplex supply chains. As an example, to address the dif-ferent viewpoints required to optimize the overall product,

8 http://www.w3.org/2005/rules/wiki/RIF_Working_Group9 http://www.autosar.org/10 http://www.osek-vdx.org/11 http://www.iso.org/iso/search.htm?qt=Controller+Area+Network&

searchSubmit=Search&sort=rel&type=simple&published=true12 http://www.flexray.com/13 http://www.asam.net/14 http://www.aeec-amc-fsemc.com/standards/index.html15 http://www.rtca.org/16 http://www.profibus.com/


AUTOSAR extended in transitioning from release 3.1to 4 its capability to capture timing characteristics ofdesign entities, a key prerequisite for assessing alternatedeployments with respect to their impact on timing. Moregenerally, the need for overall system optimization callsfor the standardization of all non-functional viewpoints ofdesign entities, an objective yet to be achieved in its fullgenerality.

2.2.2. Standardization/Harmonization of Processes

Harmonizing or even standardizing key processes (suchas development processes and safety processes) providesfor a further level of optimization in interactions across thesupply chain. As an example, Airbus Directives and Proce-dures (ADBs) provide requirements for design processesof equipment manufactures. Often, harmonized processesacross the supply chain build on agreed maturity gateswith incremental acceptance testing to monitor progressof supplier development towards final acceptance, oftenbuilding on incremental prototypes. Shared use of Prod-uct Lifcycle Management (PLM) [38] databases acrossthe supply chain offers further potentials for cross-supplychain optimization of development processes. Also, indomains developing safety related systems, domain spe-cific standards clearly define the responsibilities and dutiesof companies across the supply chain to demonstrate func-tional safety, such as in the ISO 2626217 for the automotivedomain, IEC 6150818 for automation, its derivatives Cen-elec EN 50128 and 5012619 for rail, and Do 178 B20 forcivil avionics.

Yet, the challenge in defining standards rests in balanc-ing the need for stability with the need of not blockingprocess innovations. As an example, means for composi-tional construction of safety cases are seen as mandatoryto reduce certification costs in the aerospace and raildomains. Similarly, the potential of using formal verifica-tion techniques to cope with increasing system complexityis considered in the move from DO 178 B to DO 178 Cstandards.

2.3. Getting Initial Requirements Right

Depending on application domains, up to 50% of all errorsresult from imprecise, incomplete, or inconsistent andthus unfeasible requirements. Out of the many approachestaken in industry for getting requirements right, we focus

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

Standards/default.htm20 http://www.do178site.com/

here on those for initial systems requirements, relying onISO 26262 compliant approaches.

To cope with the inherently unstructured problem of(in)completeness of requirements, industry has set updomain- and application-class specific methodologies. Asparticular examples, we mention learning process, suchas employed by Airbus to incorporate the knowledge baseof external hazards from flight incidents, the Code ofPractice proposed by the Prevent Project using guidingquestions to assess the completeness of requirements in theconcept phase of the development of advanced driver assis-tance systems. Use-case analysis methods as advocated forUML based development process follow the same objec-tive. A common theme of these approaches is the intent tosystematically identify those aspects of the environmentof the system under development whose observability isnecessary and sufficient to achieve the system require-ments. Pushing this further again leads to using contracts:based on a determined system boundary, responsibili-ties of achieving requirements are split into those to beestablished by the system-under-development (the “guar-antees” of the contract) and those characterizing admis-sible environments of the system-under-development (the“assumptions” of the contract).

However, the most efficient way of assessing complete-ness of a set of requirements is by executing it. Thisconsists in what David Harel called “playing out” for theparticular case of live sequence charts [20], [21], [22], i.e.,the use of formalized contract specifications to generatetrajectories of interface observations compliant with theconsidered set of contracts. Such simulation capabilitiesturn out to be instrumental in revealing incompleteness:typically, they will exhibit unexpected traces, e.g., due toan insufficient restriction of the environment, or only par-tially specified system reactions. Executing requirementsis only possible if semi-formal or formal specificationlanguages are used, where the particular shape of suchformalizations is viewpoint and domain dependent. Exam-ples include the use of failure propagation models forsafety contracts, the use of probabilistic timed automata tospecify arrival processes, the use of live sequence chartsfor capturing scenarios in the interaction of actors andsystems, or formalized requirement languages such as thePSL standard [34] combining temporal logic and automatabased specifications used in the EDA domain, or thepattern-based contract specification language defined bythe integrated project SPEEDS.

In addition, using contracts resting on logic-basedformalisms comes with the advantage, that “spurious”unwanted behaviors can be excluded by “throwing in”additional contracts, or strengthening assumptions, or byconsidering additional cases for guarantees. A secondadvantage rests in the capability of checking for con-sistency by providing effective tests, whether a set of


contracts is realizable, or whether, in contrast, facets ofthese are inherently conflicting, and thus no implementa-tion is feasible.

2.4. 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 effec-tive way of bringing new products to market in the past,with the increase in demand for new functionality and theadvances of the implementation platforms, this strategyhas yielded more problems than it has fixed. Indeed, thereis a shared consensus that in most of the cases the designsare not optimized in the sense that the full exploitation ofthe new opportunities technology offers is not achievedand that having visibility of the available options and anevaluation framework for design alternatives are a sorelymissing capability.

An ideal scenario for optimization is to have accessto the entire design space at the lowest possible level ofabstraction and then run a global optimization algorithmthat could select these components satisfying constraintsand optimizing multiple criteria involving non-functionalaspects of the design. Unfortunately this approach is obvi-ously out of the question for most designs given the sizeof the design space and the capabilities of optimizationalgorithms.

What is possible is to select solutions in a pre-selected design space where the number of alternativesto choose from is finite and searchable by state-of-the-art optimization programs. Indeed, the platform-baseddesign paradigm offers scaffolding that would support thisapproach. In fact, at any abstraction layer, we need to opti-mize with respect to the components of the platform. Theselection process will have to look only at feasible combi-nations of the components as dictated by the composabilitycontracts.

2.5. 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, ofteninvolving more than one hundred sub-processes. Riskmitigation measures typically cover all phases of designprocesses, ranging from ensuring high quality initialrequirements to early assessments of risks in realizabil-ity of product requirements during the concept phase, toenforcing complete traceability of such requirements withrequirements management tools, to managing consistencyand synchronization across concurrent sub-processesusing PLM tools. A key challenge rests in balancing riskreduction versus development time and effort: completely

eliminating the risks stemming from concurrent engineer-ing essentially requires a complete synchronization alonga fine-grained milestone structure, which would kill anydevelopment project due to the induced delays.

Current practice leads to typically implicit assump-tions about design aspects to be guaranteed by concurrentprocesses—designers are “speculating” on outcomes ofconcurrent engineering sub-processes, based on theirexperiences from previous designs. These assumptionsshould be made explicit—emphasizing once again thehigh methodological value of assumptions—and asso-ciate these with risk-levels, which qualify or quantifythe expected risks in not achieving such assumptions [9].This very same instrument can be put in place during theconcept phase of development processes, where verticalassumptions form the key basis for assessing realizabilityof requirements.

3. Contract Model Overview

In this section we briefly summarize the main conceptsbehind contract-based design by presenting a simplegeneric contract model centered around the notion ofcomponent. A component is a hierarchical entity thatrepresents a unit of design. Components are connectedtogether by sharing and agreeing on the values of cer-tain ports and variables. A component may include bothimplementations and contracts. An implementation M isan instantiation of a component and consists of a set P ofports and variables (in the following, for simplicity, wewill refer only to ports) and of a set of behaviors, or runs,also denoted by M, which assign a history of “values”to ports. Runs are generic and abstract, since we do notneed a predetermined form of behavior for our basic def-initions. The particular structure of the runs is defined byspecific instances of the model. For instance, runs couldbe continuous functions that result from solving differen-tial equations, or sequences of values or events recognizedby an automata model. Our basic definitions will not vary,and only the way operators are implemented is affected.

We build the notion of a contract for a component asa pair of assertions, which express its assumptions andpromises. An assertion E is modeled as a set of behav-iors over ports, precisely as the set of behaviors thatsatisfy it. An implementation M satisfies an assertion Ewhenever they are defined over the same set of ports andall the behaviors of M satisfy the assertion, i.e., whenM ⊆ E. A contract is an assertion on the behaviors ofa component (the promise) subject to certain assump-tions. We therefore represent a contract C as a pair (A, G),where A corresponds to the assumption, and G to thepromise. An implementation of a component satisfiesa contract whenever it satisfies its promise, subject to


the assumption. Formally, M ∩ A ⊆ G, where M and Chave the same ports. We write M = C when M satisfies acontract C.

Intuitively, an implementation can only providepromises on the value of the ports it controls. On portscontrolled by the environment, instead, it may only declareassumptions. Therefore, we will distinguish between twokinds of ports: those that are controlled and those thatare uncontrolled. Uncontrollability can be formalized as anotion of receptiveness: for E an assertion, and P′ ⊆ P asubset of its ports, E is said to be P′-receptive if and onlyif for all runs σ ′ restricted to ports belonging to P′, thereexists a run σ ∈ E such that σ ′ and σ coincide over P′. Inwords, E accepts any history offered to the subset P′ of itsports. This closely resembles the classical notion of inputsand outputs in programs and HDLs; it is more general,however, as it encompasses not only horizontal composi-tions within a same layer, but also cross-layer integrationsuch as the integration between application and executionplatform performed at deployment. Contracts are there-fore enriched with a profile π = (u, c) that partitions itsset of ports.

The combination of contracts associated to differentcomponents can be obtained through the operation of par-allel composition. If C1 = (A1, G1) and C2 = (A2, G2)

are contracts (possibly over different sets of ports), thecomposite must satisfy the guarantees of both, implyingan operation of intersection. The situation is more sub-tle for assumptions. Suppose first that the two contractshave disjoint sets of ports. Intuitively, the assumptionsof the composite should be simply the conjunction ofthe assumptions of each contract, since the environmentshould satisfy all the assumptions. In general, however,part of the assumptions A1 will be already satisfied bycomposing C1 with C2, acting as a partial environment forC1. Therefore, G2 can contribute to relaxing the assump-tions A1. And vice-versa. The assumption and the promiseof the composite contract C = (π , A, G) can therefore becomputed as follows:

A = (A1 ∩ A2) ∪ ¬(G1 ∩ G2), (1)

G = G1 ∩ G2, (2)

which is consistent with similar definitions in other con-texts [12], [14], [29]. For the profiles, we enforce theproperty that each port should be controlled by at mostone contract. Hence, parallel composition is defined onlyif the sets of controlled ports of the contracts are disjoint.

Parallel composition can be used to construct complexcontracts out of simpler ones, and to combine contractsof different components. Despite having to be satisfiedsimultaneously, however, multiple viewpoints associatedto the same component do not generally compose by paral-lel composition. Take, for instance, a functional viewpoint

Cf and an orthogonal timed viewpoint Ct for a compo-nent M. Contract Cf specifies allowed data pattern for theenvironment, and sets forth the corresponding behavioralproperty that can be guaranteed. For instance, if the envi-ronment alternates the values T,F,T, . . . on port a, thenthe value carried by port b never exceeds x. Similarly, Ct

sets timing requirements and guarantees on meeting dead-lines. For example, if the environment provides at least onedata per second on port a (1ds), then the component canissue at least one data every two seconds (.5ds) on port b.Parallel composition fails to capture their combination,because the combined contract must accept environmentsthat satisfy either the functional assumptions, or the timingassumptions, or both. In particular, parallel compositioncomputes assumptions that are too restrictive. We wouldlike, instead, to compute the conjunction � of the con-tracts, so that if M = Cf � Ct , then M = Cf and M = Ct .This can best be achieved by first defining a partial orderon contracts, which formalizes a notion of substitutabil-ity, or refinement. We say that C = (A, G) dominatesC′ = (A′, G′), written C C′, if and only if A ⊇ A′ andG ⊆ G′. Dominance amounts to relaxing assumptions andreinforcing promises, therefore strengthening the contract.Clearly, if M = C and C C′, then M = C′.

Given the ordering of contracts, we can computegreatest lower bounds and least upper bounds, whichcorrespond to taking the conjunction and disjunction ofcontracts, respectively. For contracts C1 = (A1, G1) andC2 = (A2, G2) (in canonical form), we have

C1 � C2 = (A1 ∪ A2, G1 ∩ G2), (3)

C1 � C2 = (A1 ∩ A2, G1 ∪ G2). (4)

Conjunction of contracts amounts to taking the union ofthe assumptions, as required, and can therefore be usedto compute the overall contract for a component startingfrom the contracts related to multiple viewpoints.

Relations between Contracts: We have already discussedtwo relations that can be established between contracts andimplementations. A relation of satisfaction, that denoteswhen an implementation satisfies a contract (i.e., providesthe required promises under the stated assumptions), and arelation of refinement between contracts, that denotes theprocess of concretizing the requirements by strengtheningthe promises and relaxing the assumptions. Contracts canalso be related by a notion of consistency and compati-bility. Technically, these two notions refer to individualcontracts. In practice, however, violations of these prop-erties occur as a result of a parallel composition, so thatwe can refer to the collection of components forming acontract as consistent or compatible.

The notion of receptiveness and the distinction betweencontrolled and uncontrolled ports is at the basis of our


relations of consistency and compatibility between con-tracts. Our first requirement is that an implementations Mwith profile π = (u, c) be u-receptive, formalizing thefact that an implementation has no control over the valuesof ports set by the environment. For a contract C, we saythat C is consistent if G is u-receptive, and compatible ifA if c-receptive.

The sets A and G are not required to be receptive.However, if G is not u-receptive, then the promises con-strain the uncontrolled ports of the contract. In particular,the contract admits no receptive implementation. This isagainst our policy of separation of responsibilities, sincewe stated that uncontrolled ports should remain entirelyunder the responsibility of the environment. Correspond-ing contracts are therefore called inconsistent.

The situation is dual for assumptions. If A is notc-receptive, then there exists a sequence of values onthe controlled ports that are refused by all acceptableenvironments. However, by our definition of satisfaction,implementations are allowed to output such sequence.Unreceptiveness, in this case, implies that a hypothet-ical environment that wished to prevent a violation ofthe assumptions should actually prevent the behavioraltogether, something it cannot do since the port iscontrolled by the contract. Therefore, unreceptive assump-tions denote the existence of an incompatibility internal tothe contract, that cannot be avoided by any environment.

4. Platform-Based and Contract-BasedDesign

In the previous sections, we reviewed a number ofapproaches that tackle the challenges set up in the intro-duction and we introduced the basics of contracts. Weargue here that Platform Based Design (PBD) subsumesmost of the other approaches to system level design andfor this reason, we will use it to develop the concept ofcontract-based design, albeit the extreme flexibility ofcontracts allows their universal use in all methodologies.

Contract-based design can be merged with platform-based design to formulate the design process as a meet-in-the-middle approach, where design requirements areimplemented in a subsequent refinement process using asmuch as possible elements from a library of available com-ponents. Contracts are formalizations of the conditions forcorrectness of element integration (horizontal contracts),for lower level of abstraction to be consistent with thehigher ones, and for abstractions of available componentsto be faithful representations of the actual parts (verticalcontracts). A typical use of contracts in cyber-physical sys-tem design would be to govern the horizontal compositionof the cyber and the physical components and to establishthe conditions for correctness of their composition.

4.1. Platform-Based Design

Platform-based design was introduced in the late 1980s tocapture a design process that could encompass horizontal(component-based design, virtual integration) and vertical(layered and model-based design) decompositions, andmultiple viewpoints and in doing so, support the supplychain 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, andthat would extend it to provide a rigorous frameworkto reason about design. Indeed, the concepts have beenapplied to a variety of very different domains: from auto-motive, to System-on-Chip, from analog circuit design, tobuilding automation to synthetic biology.

The basic tenets of platform-based design are as fol-lows: The design progresses in precisely defined abstrac-tion layers; at each abstraction layer, functionality (whatthe system is supposed to do) is strictly separatedfrom architecture (how the functionality could be imple-mented). This aspect is clearly related to layered designand hence it subsumes it.

Each abstraction layer is defined by a design platform.A design platform consists of

• A set of library components. This library not onlycontains computational blocks that carry out the appro-priate computation but also communication compo-nents that are used to interconnect the computationalcomponents.

• Models of the components that represent a charac-terization in terms of performance and other non-functional parameters together with the functionalityit can support. Not all elements in the library are pre-existing components. Some may be “place holders” toindicate the flexibility of “customizing” a part of thedesign that is offered to the designer. In this case themodels represent estimates of what can be done sincethe components are not available and will have to bedesigned. At times, the characterization is indeed a con-straint for the implementation of the component and it isobtained top-down during the refinement process typ-ical of layered designs. This layering of abstractionsbased on mathematical models is typical of model-based methods and the introduction of non-functionalaspects of the design relates to viewpoints.

• The rules that determine how the components canbe assembled and how the the functional and non-functional characteristics can be computed given theones of the components to form an architecture. Then,a platform represents a family of designs that satis-fies a set of platform-specific constraints. This aspectis related to component-based design enriched withmultiple viewpoints.


This concept of platform encapsulates the notion of re-useas a family of solutions that share a set of common fea-tures (the elements of the platform). Since we associatethe notion of platform to a set of potential solutions to adesign problem, we need to capture the process of map-ping a functionality (what the system is supposed to do)with the platform elements that will be used to build aplatform instance or an “architecture” (how the systemdoes what it is supposed to do). The strict separationbetween function and architecture as well as the mappingprocess have been highly leveraged in AUTOSAR. Thisprocess is the essential step for refinement and provides amechanism to proceed towards implementation in a struc-tured way. Designs on each platform are represented byplatform-specific design models. A design is obtained bya designer’s creating platform instances (architectures) viacomposing platform components (process that is typicalof component-based design), by mapping the functionalityonto the components of the architecture and by propagat-ing the mapped design in the design flow onto subsequentabstraction layers that are dealt with in the same way thuspresenting the design process as an iterative refinement.This last point dictates how to move across abstractionlayers: it is an important part of design space explorationand offers a way of performing optimization across lay-ers. In this respect PBD supports multiple perspectives ina general way.

4.2. Contract-Based Design

In PBD, contracts can play a fundamental role in deter-mining the correct composition rules so that when thearchitecture space is explored, only “legal” compositionsof available components are taken into consideration. Theycan be used to verify whether the system obtained by com-posing the library elements according to the horizontalcontracts satisfies the requirements posed at the higherlevel of abstraction. If these sets of contracts are satisfied,the mapping mechanism of PBD can be used to producedesign refinements that are correct by construction.

To be more precise about these concepts, consider asnapshot in a platform based design process, as shownin Fig. 3, covering adjacent design layers N + 1, N , andN − 1. System S is realized at layer N by the compositionof systems S1, S2, and S3.

Horizontal Contracts: In this setting, contracts serve dif-ferent objectives. As highlighted in the subsection onvirtual integration testing, a key value of contracts is todetect integration errors early. We use the term horizontalcontract related to virtual integration testing, which thusin Fig. 3 define under what conditions the integration ofsubsystems into the composite system S is considered suc-cessful. Specifically, a horizontal contract CH of a system

Fig. 3. Contracts in a PBD flow.

S represents in its assumption AH the constraints it itselfimposes on any possible integration context C[ ], so as tobe able to realize its function F.

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

j , GHj ).

Contract-based virtual integration testing then requires tobe able to demonstrate all assumptions AH

j from the givendesign context. For example, let us consider subsystem S2.Its design context is in part given by subsystem S1, whichthus becomes responsible for establishing those horizontalassumptions relating to S2Â’s in-port p21. Intuitively, then,we expect the guarantee GH

1 of the horizontal contract of S1to be sufficient to demonstrate compliance of any restric-tions S2 was placing on allowed uses of p21. Note alsothe dependency of S2 on the yet undetermined part of thedesign context of S2 reflected by input p3S to the realizationof system S on layer N . In general, then, in contract-basedvirtual integration testing, this yet unknown design con-text is represented by horizontal contracts of the composedsystem S itself; Fig. 3 highlights the horizontal contractCH

N (S) = (AHN (S), GH

N (S)) of S at layer N . This contractwill enforce, that any design context of S will be guar-anteed to be compliant to AH

N (S). Thus, when checkingthe design context of S2 for compliance to its horizon-tal assumptions on uses of port p3S , we expect this to bederivable from AH

N (S). In general, then, in contract-basedvirtual integration testing, we need to demonstrate that allhorizontal assumptions of subsystems can be derived fromthe conjunction of all horizontal guarantees of subsystemsand horizontal assumptions of the composed system.

Circular Reasoning: At the current level of discourse wepoint to the fact, that the above argument typically involvescircular reasoning. For example, in Fig. 3 GH

1 will only beguaranteed for legal design contexts of S1. Thus, only onceAH

1 is established, can we actually rest our argumentation


on GH1 . Establishing, then, AH

1 , we would like to involveGH

3 , which, however, is only sound once AH3 is established.

This, finally, would involve GH2 as witness, but it is exactly

for the purpose of establishing AH2 , that this reasoning

chain is established. The mathematical theory essentiallyjustifies the use of such seemingly circular arguments, forclasses of contracts whose assumptions and guaranteesare expressible in the rich set of safety properties (whichcan always be proven and disproved by finite observa-tions). However, certain restrictions on how assumptionsand guarantees refer to out-ports respectively in-ports ofa system have to be observed.

Vertical Contracts: Each of the subsystems Sj can theneither be further refined, or assumed to be given as designbasis at layer N , as platform library elements. Such com-ponents, as S2 in Fig. 3, could be placeholders, to be thenelaborated in a design process at layer N − 1. Symmetri-cally, Fig. 3 shows the system S at layer N as a realizationof the placeholder S at layer N + 1. To transition acrossdesign layers, we use what we 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 Sat layer N , so as to be able for S to perform its intendedfunction at layer N +1 as expressed by a top-down verticalcontract. This entails, that the correctness of the level N+1design hinges on finding an implementation of S meetingthis bottom-up vertical contract.

When using budgeting, the designer assigns respon-sibilities to the subsystems of S by deriving top-downcontracts for each, which jointly establish SÂ´s bottom-upvertical contract. Alternatively, when using a bottom-upapproach, we assume the top-down vertical contracts of Sj

as given, and establish either directly or passing througha characterization of the functionality realized by S atlayer N (as a top-down contract), that the layer N + 1bottom up contract of S is satisfied. In both the top-downand bottom up approach, the verification of this cross-layerdesign steps would assume that the contract-based virtualintegration test was successful. This allows using the guar-antees of horizontal contracts as additional premise in theverification 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 expressedby its bottom-up vertical contract, the functionality of thecomponent as expressed by its top-down vertical contractcan be achieved. Again, this proof can take horizontalcontracts of the component as additional supportive argu-ments. For composed systems, such as the system S atlayer N in Fig. 3, the bottom-up contracts are given by theset of bottom-up contracts of its leaf components.

Crossing design layers thus asks for verification ofeither refinement (top-down) or aggregation (bottom-up)steps. The presentation given so far ignores extensionsof the framework required in practice to deal with what isoften called interface refinement, e.g., [8], [25]. Due to thevery purpose of abstraction layers of hiding complexity, arepresentation of a design at level N will typically explicateimplementations aspects such as representations of mes-sages and variables, protocols used for communicationand synchronization. In general, both the representationof the system in the data-domain as well as in the timedomain may change, calling for notions of refinementwhich are expressive enough to deal both with re-timingand type conversions. The theory for these notions ofweak simulation relations is well understood for particularclasses of mathematical models (see [19]), which jointlyare rich enough to support a broad spectrum of viewpoints,including safety, real-time, performance, power.

To allow to build on these in the methodology forcontract-based design, we introduce what we call sim-ulation components relating traces, i.e., sequences ofobservations of ports of a level N + 1 component S tosequences of observations of ports of components S atlevel N . Referring to Fig. 3, this component would thushave an interface towards layer N + 1 observing ports p1S

and p2S , and an interface towards layer N observing portsp1S , p2S , and p3S . Simulation components can use con-tracts to characterize the intended inter-relation betweenvaluations of these. These contracts can take the form ofboth logic-based and automata-based formalisms, givingsufficient expressivity in capturing the intended relationsbetween traces of interface objects of S at level N + 1 andlevel N [4].

Strong vs. Weak Assumptions and the Issue of Compati-bility: We close this section by pointing out a subtle, buthighly relevant, difference in the methodological use ofassumptions in horizontal and vertical contracts. Withinhorizontal contracts, assumptions are used to restrict theallowed design context of a component. By enforcingcontract-based virtual integration testing, as discussedabove, we therefore complement each model-based inte-gration steps with verification activities demonstratingthat the currently known design context C[ ] of a compo-nent S actually complies to these restrictions. This is keyto enforcing what has been called composability of sys-tems by [26], a fundamental principle in good architecturedesign ensuring functionality realized by components ofthe architecture are maintained when integrating these intoa compound architecture. It is the purpose of assumptionsto support this composability property. Specifically, ifsystem S realizes function F(S) (e.g., as expressed in a top-down vertical contract), and C[ ] meets the contract-based


virtual integration test for S, then S will be guaranteedto offer its functionality F(S) when being put into thisdesign context C[ ]. We refer to assumptions which mustbe enforced for the component to behave as expected asstrong assumptions.

In contrast, additional assumptions may be added to thestrong assumption to ensure that if these assumptions aremet, then “non essential” but desired properties are guar-anteed. These additional assumptions are called in contrastweak assumptions. In vertical contracts, in particular inbottom-up contracts, weak assumptions represent antici-pations often based on experience or estimation functionson what could be assumed to be realizable by lowerimplementations levels. As the designs refines verticallyacross multiple layers, eventually such assumptions eitherbecome validated based on top-down contracts of com-pleted designs, or invalidated (e.g., due to insufficientprocessing power, non-matching assumptions on failuredistributions, or insufficient signal strength). By main-taining dependency between contracts, it is then possibleto backtrack to the higher-level bottom up assumptionwhich thus became invalidated, and explore possibilitiesof weakening, such as by re-budgeting.

Turning assumptions in vertical contracts to strongassumptions would entail a binding restriction of thedesign space: a failure to meet such strong vertical assump-tions would be considered a contract failure. Strongvertical assumptions can be used to enforce complianceto standards, or within the supply chain hierarchy, toeliminate the likelihood of deep design iterations crossingorganizational boundaries. In a generalized setting, such ascurrently pushed in the context of the German InnovationAlliance for Embedded Systems,21 we thus allow contractsto refer to both strong and weak assumptions, allowingto customize design processes supporting additional usecases of strong assumptions as outlined above.

5. Control Design and Contracts withan Example

In this section we present a simple example of controlof a cyber-physical system design that makes use of thecontract-based design methodology. The example, a WaterFlow Control system, was first proposed by the IsraelAerospace Industries Ltd. (IAI) in the context of theSPEEDS project, and has been analyzed by Parades usinghybrid modeling techniques [5]. Here we present a versionusing a continuous model to highlight the use of contractsin a familiar, equation-based notation. We will discuss how

21 See SPES2020 Architecture Modeling Deliverable of the GermanInnovation Alliance on Embedded Systems SPES 2020,BMBF grantFK 01 IS O8045 W, http://spes2020.informatik.tu-muenchen.de

to model the system requirements, as well as how theseare partitioned in assume/guarantee pairs (contracts) foreach component of the system. Different verification anddesign activities can be carried out using this model.

5.1. The Water Flow Control System

A cylindrical water container is equipped with an inlet pipeat the top, and an outlet pipe at the bottom. The containerhas a diameter D = 5m and a height H = 9m. The inlet andoutlet cross sections are Sin = 0.5m2 and Sout = 0.16m2,respectively. We are to design a system that guarantees acontinuous outlet flow Fout of 1.0 ≤ Fout ≤ 2.0m3/sec,after 10 seconds since startup. In addition, the system mustguarantee that the container will not overflow, and that theenergy consumption is lower than a limit El. The designercan assume a constant inlet pressure P ≥ 5, 000pa, and amaximum evaporation rate ε = 0.25m3/hour.

To formalize the problem, we construct a componentrepresenting the overall Water Flow Control system, withinput, output and parameters corresponding to the abovespecification. To simplify our task, we decide to make statevariables, such as the water level, visible as primary out-puts. The WFC formal specification is therefore composedof the following items:

• Input: Inlet pressure P• Output: Water Level wl, outlet flow rate Fout , energy

consumption E• Parameters: container size D and H, inlet cross sections

Sin and Sout , evaporation rate ε.

To proceed with the system specification we define a con-tract that the implementation must satisfy. The contractdistinguishes between the assumptions and the guaranteesthat must be enforced. Assuming t represents time, theabove conditions can be formally specified as follows:

• Assumptions: P ≥ 5, 000.• Promises:

∀t.(t ≥ 10 =⇒ (1.0 ≤ Fout ≤ 2.0))

∀t.(wl(t) ≤ H)

E ≤ El

5.2. Design Solution

There are many ways to guarantee the required proper-ties given the assumptions. Here we examine a solutionmethod based on the regulation of the water level. From theBernoulli Law, we know that the outlet flow rate dependson the water level according to the formula

Fout = V · Sout = √2g wl · Sout


Fig. 4. Block diagram of the Water Flow Control system.

where V is the velocity. The water level is thereforegiven by

wl =(

Fout

Sout

)2

· 1

2g.

Thus, the promise 1.0 ≤ Fout ≤ 2.0 is equivalent to having

2.0 ≤ wl ≤ 8.0.

We will therefore approach the problem by controlling thewater level in the container through a valve at the inlet. Asa result, the system will be composed of an inlet valve, thewater container, a water level sensor and a controller thatcontrols the opening and closing of the valve based on themeasured water level, as shown in Fig. 4.

Our methodology is the following:

• We define for each component the contract that it mustsatisfy

• We compose the contracts for each component• We finally verify that the composite contract refines the

contract for the system, given above.

Having verified the system at the virtual integration level,the contract theory ensures that a composition of com-ponents, each satisfying its contract, will also satisfy thesystem specification.

5.2.1. Model for the Valve

The inlet flow is controlled by a valve that may get posi-tion commands from the controller. We denote the valveaperture by λ, where 0 ≤ λ ≤ 1. The valve is con-trolled by a signal λcmd , coming from the controller, whoserange is also 0 ≤ λcmd ≤ 1. The position λ of the valvefollows that of the aperture command λcmd at a rate of0.5/sec.

Assume that F is the flow rate at the input of the valve,and call Fin the flow rate at the output of the valve, whichis also the flow rate at the input of the container. We canexpress Fin as a function of the current valve position asfollows:

Fin = F · (0.2λ2 + 0.8λ)

In summary, the sets of inputs and outputs for the valve is

• Input: λcmd , F• Output: λ, Fin

In this simplified model, the valve must satisfy a contractthat makes no assumption. In practice, one can use theassumption to limit the range of validity of the model, forexample by requiring that the flow rate at the input beless than a certain value. This translates, after composi-tion with the rest of the components, in a requirement onthe environment that the pressure P be less than a certainvalue. Obviously, if one such assumption is introduced,the overall contract will not be satisfied, as no constraintis imposed at the system level for the pressure P other thanit be greater than a certain value.

The valve satisfies the following promises.

• Rate of change of valve position

dλ

dt= sgn(λcmd(t) − λ(t)) · 0.5

• Flow rate at the output of the valve

Fin = F · (0.2λ2 + 0.8λ)

• The initial position of the valve is closed

λ(0) = 0.

Sometimes it may appear ambiguous whether a certainrequirement should be guaranteed by a component, orassumed from the environment. For instance, one couldtake the initial position of the valve as an assumption. Theambiguity disappears when one considers which compo-nent is responsible for setting a certain value. Since theposition of the valve is an output of the valve, it is the valveresponsibility to ensure its initial value, and the require-ment is therefore a guarantee. A valve that does not satisfythis condition will simply not satisfy the contract.

5.2.2. Model for the Container and the Outlet

The container is characterized by the following inputs andoutputs:

• Input: the inlet flow rate Fin

• Output: the water level wl and the outlet flow rate Fout .

The water level depends on the inlet and the outlet flowrate, as well as on the evaporation rate ε. We assume thatthe evaporation rate is bounded. In order to model thissituation, we must add ε to the set of inputs. Then, thecontainer must satisfy the following contract.

For the assumptions, we assume that the evaporationrate is bounded:

∀t.ε(t) ≤ 0.25


The container must ensure the following promises:

• The water level is given by the integral of the differencebetween the water coming in and the water going out(including the evaporation), divided by the base are ofthe container. Formally,

∀t, t′. t′ > t =⇒ wl(t′) = wl(t) + 1

π(D/2)2

×∫ t′

t(Fin(t

′′) − Fout(t′′) − ε(t′′))dt′′

• The outlet water flow is given by the Bernoulli law


5.2.3. Model for the Water Level Sensor

The sensor is modeled simply as a transducer that outputsa measured water level wlm as an approximation of thereal water level wl. Thus, the sensor has wl as an input andwlm as an output. The sensor makes no assumption, andmakes the promise:

∀t. 0.95 · wl(t) ≤ wlm(t) ≤ 1.05 · wl(t),

i.e., the sensor has a 5% error.

5.2.4. Model for the Controller

The controller takes as input the measured water level wlm,and controls the position of the valve through the signalλcmd , which is therefore an output of the controller.

We initially experiment with a simple control function.In order to maintain the required output flow rate, andto avoid the container overflow, the valve will be openedwhen the water in the container goes below a certain levelwlmin (so that the container will be filled), and will beclosed when the water goes above a certain level wlmax

(to avoid overflow). The promises of the controller aretherefore as follows:

wlm ≤ wlmin =⇒ λcmd = 1

wlm ≥ wlmax =⇒ λcmd = 0

Note that the specification of the controller makes nopromise when wlm is between wlmin and wlmax . Thus thespecification admits several different possible implemen-tations for the controller.

5.2.5. Determination of Consumed Energy

We assume that the energy consumption is due primarilyto the valve motion. We also assume that the energy is

proportional to the distance traveled by the valve, whichcan be expressed as follows:

�(T) =∫ T

0

∣∣∣∣dλ

dt

∣∣∣∣ dt.

The average distance traveled at time T is therefore

�(T) = �(T)

T.

The energy can be computed using an appropriate con-stant c

E(T) = c · �(T) = c · �(T)

T.

The total energy is therefore given by

E = c · limT→∞

�(T)

T.

We therefore add an output E to the valve, and add the addi-tional promise that expresses the value of E as a functionof λ.

5.3. System Composition

Having defined the contracts for the component of the sys-tem, our aim is to verify that their collective requirementsare consistent with the overall system contract. To do so,we must derive an overall system by taking the composi-tion of all the contracts of the components described above.Composition in the context of this model is simple, andcorresponds to putting all the equations in a system so thatthey are all satisfied simultaneously (i.e., we must takethe intersection of the sets of solutions of the individualequations). One, however, has to take care of separat-ing the assumptions from the guarantees, and make surethat assumptions that are not already discharged by othercomponents of the system are properly propagated to thecomposite.

To give an example, we compose the model of the valveV with the model of the container C. The compositionis defined, since the set of outputs of the two compo-nents is disjoint, and therefore there is no conflict overwhich equation to use to define the value of a variable.The composition has the following interface signals

I = {λcmd , F, ε}O = {λ, Fin, wl, Fout}

which are obtained by taking as output any of the out-puts of the two components, and as inputs the remainingsignals. The composite must satisfy the following assump-tion, which is an assumption of the container which is notdischarged by the valve:

∀t.ε(t) ≤ 0.25


In addition, the composite must satisfy all of the followingpromises:

dλ

dt= sgn(λcmd(t) − λ(t)) · 0.5

Fin = F · (0.2λ2 + 0.8λ)

λ(0) = 0

∀t, t′. t′ > t =⇒ wl(t′) = wl(t) + 1

π(D/2)2

×∫ t′

t(Fin(t

′′) − Fout(t′′) − ε(t′′))dt′′


Note that some of the outputs may now be hidden inthe composition. For instance, the output Fin does notneed to appear explicitly, as long as it is considered inthe promises. That is, we need to replace the guaran-teed expression of Fin in the expression for wl, and thenremove Fin from the set of outputs. Likewise, we couldremove λ from the set of outputs. However, since λ is notdefined explicitly as a function (but rather as the solutionto a differential equation) the substitution is problematicfrom a formal point of view. From a theoretical stand-point, however, if the constraint on λ were to be expressedfor example as an extended state machine, the usual pro-cedure of taking the product can be used to compute thefinal result.

Note also that the assumption coming from the containeris also an assumption of the composite. This is because theother component in the composition does not dischargethe assumption, which must therefore be maintained andpropagated to the environment of the composition.

The parallel composition can then be extended toinclude the water level sensor and the controller. The finalset of inputs and outputs (without hiding) is the following:

I = {F, ε}O = {λ, λcmd , Fin, wl, wlm, Fout}

with the additional promises

∀t. 0.95 · wl(t) ≤ wlm(t) ≤ 1.05 · wl(t)

wlm ≤ wlmin =⇒ λcmd = 1

wlm ≥ wlmax =⇒ λcmd = 0

In addition to that, we can add the output E for the energyconsumption and the corresponding promise to computethe energy consumption as a function of the position ofthe valve. The total set of inputs and outputs is therefore:

I = {F, ε}O = {λ, λcmd , Fin, wl, wlm, Fout , E}

5.4. Contract Verification

Contract verification consists now in checking whetherthe contract for the composition that we have derivedin the previous section refines the contract for the sys-tem, outlined in Section 5-A. Refinement, as discussed inSection 3, amounts to checking that the guarantees offeredby the collection of components are stronger than theguarantees required by the overall specification (the imple-mentation promises at least the same, or more), under aweaker set of assumptions (the implementation assumesthe same from the environment, or less). These conditions,in turn, can be verified by comparing the set of solutions ofthe equations. Stronger guarantees mean a smaller set ofsolutions for the promises (a more constrained behavior),while weaker assumptions imply a larger set. Formally, ifwe take A and G as the sets of solutions, the contracts mustsatisfy the usual relation

A′ ⊆ A

G ⊆ G′

where C′ = (A′, G′) is the system contract, while C =(A, G) is the contract obtained by taking the compositionof the contracts for each component. This formulation,however, is effective only when comparing contracts thathave the same set of inputs and outputs. This is not thecase here, since the overall system contract specificationand the system composite are defined on slightly differentalphabets of signals. Hence, the set of inputs and outputsmust somehow be equalized. One solution is to extendthe system specification to include the ports of the com-position, such as λ, λcmd , Fin and wlm. The promises ofthe system specification do not change, so that in practicethe system specification allows any value on those ports.Alternatively, we may hide the extra outputs, and keeponly the relevant ones, i.e., wl, Fout and E.

The situation is different for the inputs. First, the com-position depends on F rather than on P. Thus, we mustadd to the composition a component PF that translates thevalue of P into the corresponding value of F, by applyingagain the Bernoulli law. That is, PF has P as an input andF as an output. After the composition, the overall com-posite will have P as an input (since it is an input of PFand it is not an output of any other component), and F asan output (since it is an output of PF and an input of thevalve). Obviously, at this point, the port F must be hidden,since it is not an output in the system specification.

To equalize on ε, we may add it as an input to the systemspecification. The equations do not change, so that thesystem specification is effectively independent of the valueof ε.

After equalization, we can check containment of thesolution sets. It is apparent that the condition on the


assumptions is not satisfied: in fact, A requires that ε bebounded, which is a condition that is not specified by thesystem specification A′. The problem can be solved bychanging the way we modeled the container. There, wemade the assumption that the evaporation rate is bounded.Thus, we had to take ε as an input of the specification.A closer look, however, reveals that the evaporation rateis a function of the shape of the container. Hence, therate of evaporation can actually be guaranteed by the con-tainer itself. Thus, ε should actually be an output of thecontainer, and the assumption on boundedness is changedinto a guarantee.

Checking the guarantees is more complex, and requiressolving the system of equations that characterize the com-posite and deriving the expression of wl, Fout and Eexplicitly. After that, we need to check the containmentrelation. In our specific case, we can solve the equationfor the valve under some hypothesis on the value of thecommand λcmd . However, the equation for the water levelrequires a numerical solution. One way to address thisproblem is to construct hybrid models of the system, asdescribed in our previous work [5]. Questions of scalabil-ity do arise, and abstractions must be typically employedto make the solution practical.

Note that we made no assumption on P in the imple-mentation. Therefore, A admits more solutions than A′.We can take advantage of this fact, and only check that

A′ ⊆ A

G ∪ ¬A ⊆ G′ ∪ ¬A′

since a promise is effective only if the correspondingassumptions are satisfied. Because ¬A is smaller than¬A′, satisfying the condition on the guarantees is easier,as the formulation applies the assumptions for the systemspecification to the implementation.

The model that we have developed still allows severalpossible implementations. In particular, nothing is saidabout the behavior of the controller when the water levelis between wlmin and wlmax . That is, the controller mayarbitrarily switch between open and close valve while inthat range. While all choices may actually be such thatthe guarantee on Fout is satisfied, some choices may leadto a violation of the guarantee of the energy consump-tion. This would be detected during verification, if thetools used for refinement checking are powerful enoughto handle the continuous time specification. The ability toformalize and check non-functional requirements, underthe assumptions, is a critical advantage of a contract-baseddesign methodology in which different viewpoints can bemixed in the specification. Observe also how the energyconsumption depends on the actual behavior of the imple-mentation, so that the two viewpoints must be integratedto obtain significant results.

Besides verification, controller synthesis can be appliedto derive automatically a controller that satisfies the sys-tem contract. In this case, we take the composition of allthe components, except for the controller itself. The prob-lem consists of deriving a contract for the controller, suchthat when the controller is composed with the rest of thesystem, the composition satisfies the system specification.This problem is subject of current research, and typicallysuffers from high computational complexity, especially inthe case of timed systems. The synthesis problem has beenaddressed and solved in certain circumstances through anoperator of quotient [40], [39].

5.5. Vertical Contracts in Control

Contracts are most naturally established between entitiesor components that operate at the same level of abstraction.By sharing a common understanding of the system, twocomponents rely on each other’s guarantees to fulfil thesystem requirements, while assumptions formalize thisinterdependence thereby enabling their separate and inde-pendent implementation. Of potentially greater interest,however, is the use of contracts across different levelsof abstraction, as described in Section 4-B. When usedthis way, a vertical contract defines a relation betweenthe properties of a system and those of its implementa-tion platform. In other words, the system requirementscan be satisfied by operating not only at the level of theapplication, but also by configuring execution parame-ters and by taking advantage of the expected behavior,as described by the assumptions, of both the applicationand the platform. Co-design and multi-layer techniquesare therefore fully supported by the contract models, andare well incorporated and extended by the Platform-BasedDesign paradigm discussed in the previous sections.

These aspects are of increasing importance in thecontext of control design. Martin Törngren describes con-trollers as “bound by contracts to the plant”, in the sensethat the controller parameters must refer to closed loop sys-tem dynamics, which are in turn determined by the plantdynamics [44]. Likewise, timing constraints refer to bothopen and closed loop systems, as the controller param-eters depend on the chosen sampling period and on theparticular techniques (such as delay compensation) usedin designing the control loop. These contracts, therefore,extend to the implementation platform. Indeed, in con-trol design there are three entities that interact in differentways, as illustrated in Fig. 5.

The controller implements the control law in a tight loopwith the plant. At the same time, the implementation plat-form executes the controller and physically interfaces withthe plant, defining the critical non-functional parameters(delay, jitter and throughput) that concur in establishingthe system properties.


Fig. 5. Typical interactions between controller, plant and implementa-tion platform.

Fig. 6. Block diagram of a stability control application.

In this setting, we focus in particular on the interac-tion between the controller and the platform. Here thecontroller defines requirements in terms of several aspectsthat include the timing behavior of the control tasks andof the communication between tasks, their jitter, theaccuracy and resolution of the computation, and more gen-erally requirements on power and resource consumption.These requirements are taken as assumptions by the con-troller, which in turn provides guarantees in terms of theamount of requested computation, activation times anddata dependencies.

Examples of this kind of interaction abound, and high-light the need for a theory that can integrate verticalas well as horizontal contracts. A typical application,shown in Fig. 6 and inspired by the cited presentation ofMartin Törngren, is the implementation of a vehicle sta-bility control system, in which three different controllersrelated to the yaw, the brakes and the engine must interacttogether with the wheel, the engine and the overall vehicledynamics.

Different implementation platforms can be used tosupport the functionality, guaranteeing different qualitylevels. In this application, the control systems dependsupon several subsystems, each integrated on a separateplatform, and connected through often heterogeneous

communication fabric. Horizontal contracts at the levelof the platform can be used to understand the interactionsbetween the subsystems, and between the system and theplant with respect to non-functional properties. Similarly,at the level of the application horizontal contracts definethe global properties and the interaction between the con-trol algorithm and the plant with respect to the functionalcontrol specification. Vertical contracts fit across these twolevels as bridges that relate the performance of the differentimplementation platforms to their mapped applications.

The relations between contracts outlined in Section 3can be applied to vertical contracts, as well. The relationof satisfaction is unchanged, since it involves the com-parison between an implementation and its contract. Inthe case of an execution platform, this typically requiresshowing that the guaranteed timing constraints are metunder the load conditions assumed by the contract. Com-patibility is more interesting. In the context of a platform,the “environment” in a vertical contract refers to the otherpossible applications running on the same execution plat-form. Consequently, the composition (mapping) of anapplication on its platform defines the conditions (assumedand promised) under which other tasks can be run with-out breaking the original contract. Quantitative notionsof robustness could be introduced [15] to provide a mea-sure of the possible violations, and therefore instruct thedesigners or an automatic mapping tool on the steps to betaken to optimize the architecture.

6. Moving Forward: the Importance ofContracts

We argued that contracts in their most elementary formmay just take the form of informal textual requirements,yet with the key distinguishing feature of explicating theseparation of concerns: what must be guaranteed by thesystem itself, and what are the constraints on environ-ments, which are fundamentally required so as to allowthe system—based on such assumptions—to enforce itsguarantees. We have then seen how this core paradigmmatches well with the orthogonal notion of viewpoints:contracts can thus be flagged as to the viewpoint theyrelate to. Clearly, the number of viewpoints to be sup-ported may vary from application to application—thus itis up to the customization of contract-based design withina company’s development process, to determine the set ofviewpoints that must be supported. For sure, this will gobeyond capturing the functionality, with safety viewpointsand real-time viewpoints being a necessity in safety rel-evant embedded systems development. Business relatedviewpoints such as the ones reflecting costs, constraintsfrom manufacturing, maintainability are natural choices,as are those related to resource consumption.


Orthogonal to this discussion is the degree of formal-ization used in contracts. As highlighted above, there isalready high methodological value when using informalcontracts. A natural next step is to restrict the vocabu-lary of contracts to (domain specific) ontologies. Furthersteps towards formalization are viewpoint dependent: theycan, for example, take the form of automata-based spec-ifications, employ suitable logics, build on a library ofpatterns, and capitalize on sequence charts. The addi-tional effort in providing a degree of formalization istypically well invested due to the additional benefitswe have outlined above, such as testing consistency ofrequirements, identifying complex integration errors earlythrough virtual integration testing, boosting re-use thoughcomponent-based design, and allowing cross-layer designoptimizations based on performing platform-based design.The key point we raise is that this formalization can bedone incrementally and on a case-by-case basis. Thus,there is a clear migration strategy from using contractsinformally, to incorporating domain ontologies, to gradu-ally enriching the number of covered viewpoints, and togradually increase the degree of formalization. No matterin which order such steps are taken, each of these comeswith significant potentials for process improvements.

It is the objective of this paper to let designers capitalizeon this so-far largely unexploited tool. The value proposi-tion of adding contracts to system companies developmentprocesses is now on the table—the ultimate test rests in themarket take up. Strong indications of market acceptanceare the anchoring of the contract-based approach withinthe CESAR22 Reference Technology Platform (RTP),where 25 European global players in the systems mar-ket team up with leading vendors, research institutes,and SMEs, to create an innovation ecosystem around theemerging standard meta-model of the CESAR RTP.

Acknowledgements

This work was supported in part by the EU projectCOMBEST grant n. 215543, the EU NoE ArtistDesigngrant n. 214373, the EU DANSE IP, the European projectCESAR of the ARTEMIS Joint Undertaking, and bythe Multiscale Systems Center, one of six research cen-ters funded under the Focus Center Research Program, aSemiconductor Research Corporation program.

References

1. Road vehicles—functional safety. Standard ISO 26262.

22 www.cesarproject.eu

2. Balarin F, Hsieh H, Lavagno L, Passerone C, Sangiovanni-Vincentelli AL, Watanabe Y. Metropolis: an integrated elec-tronic system design environment. IEEE Computer, 2003;36(4): 45–52.

3. Balarin F, Davare A, D’Angelo M, Densmore D, MeyerowitzT, Passerone R, Pinto A, Sangiovanni-Vincentelli A,Simalatsar A, Watanabe Y, Yang G, Zhu Q. Platform-baseddesign and frameworks: Metropolis and metro ii. InNicolescu G, Mosterman PJ, editors, Model-Based Designfor Embedded Systems, chapter 10, page 259. CRC Press,Taylor and Francis Group, Boca Raton, London, New York,November 2009.

4. Balarin F, Passerone R. Specification, synthesis and simula-tion of transactor processes. IEEE Trans. Computer-AidedDesign Integrated Circuits Syst., 2007; 26(10): 1749–1762.

5. Benvenuti L, Ferrari A, Mangeruca L, Mazzi E, PasseroneR, Sofronis C. A contract-based formalism for the specifica-tion of heterogeneous systems. In Proceedings of the Forumon Specification and Design Languages (FDL08), 142–147,Stuttgart, Germany, September 23–25, 2008.

6. Berry G. The effectiveness of synchronous languages for thedevelopment of safety-critical systems. White paper, EsterelTechnologies, 2003.

7. Booch G, Rumbaugh J, Jacobson I. Unified Modeling Lan-guage User Guide, The (2nd Edition) (Addison-WesleyObject Technology Series). Addison-Wesley Professional,2005.

8. Broy M. Compositional refinement of interactive systems.J. ACM, 1997; 44(6): 555–600.

9. Damm W. Controlling speculative design processes usingrich component models. In Proceedings of 5th InternationalConference on Application of Concurrency to System Design(ACSD), 2005.

10. Damm W, Votintseva A, Metzner A, Josko B, PeikenkampT, Böde E. Boosting reuse of embedded automotive applica-tions through rich components. In Proceedings of Founda-tions of Interface Technologies (FIT05), San Francisco, CA,August 21, 2005.

11. Davare A, Densmore D, Meyerowitz T, Pinto A,Sangiovanni-Vincentelli A, Yang G, Zhu Q. A next-generation design framework for platform-based design.In Design Verification Conference (DVCon), San Jose’,California, 2007.

12. de Alfaro L, Henzinger TA. Interface automata. In Pro-ceedings of the Ninth Annual Symposium on Foundationsof Software Engineering, pages 109–120. ACM Press, 2001.

13. Derler P, Lee EA, Sangiovanni Vincentelli A. Modelingcyber-physical systems. Proc. IEEE, 2012; 100(1): 13–28.

14. Dill DL. Trace Theory for Automatic Hierarchical Verifi-cation of Speed-Independent Circuits. ACM DistinguishedDissertations. MIT Press, 1989.

15. Doyen L, Henzinger T, Legay A, Nickovic D. Robustness ofsequential circuits. In Proceedings of the 10th InternationalConference on Application of Concurrency to System Design(ACSD 2010), Braga, Portugal, June 21–25, 2010.

16. Eker J, Janneck JW, Lee EA, Liu J, Liu X, Ludvig J,Neuendorffer S, Sachs S, Xiong Y. Taming heterogeneity- the ptolemy approach. Proc IEEE, 2003; 91(1): 127–144.

17. Fleurey F, Muller PA, Jzquel JM. Weaving executabilityinto object-oriented meta-languages. In Proceedgins of the8th International Conference on Model Driven EngineeringLanguages and Systems (MODELS05), October 2005.

18. Fritzson P. Principles of Object-Oriented Modeling andSimulation with Modelica 2.1. Wiley, 2003.


19. Glabbeek R, Weijland WP. Branching time and abstractionin bisimulation semantics. J ACM, 1996; 43(3): 555–600.

20. Harel D, Kugler H, Marelly R, Pnueli A. Smart play-out ofbehavioral requirements. In FMCAD, 378–398, 2002.

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

22. Harel D, Segall I. Planned and traversable play-out: A flexiblemethod for executing scenario-based programs’. In TACAS,485–499, 2007.

23. Karris S. Introduction to Simulink with Engineering Appli-cations. Orchard Publications, 2006.

24. Karsai G, Sztipanovits J, Ledeczi A, Bapty T. Model-integrated development of embedded software. Proc IEEE,2003; 91(1): 145–164.

25. Kesten Y, Piterman N, Pnueli A. Bridging the gap betweenfair simulation and trace inclusion. Information and Com-puting, 2005; 200(1): 35–61.

26. Kopetz H. Composability in the time-triggered architecture.SAE International Congress and Exhibition (2000-01-1382),Detroit, MI, USA, 6–9 March 2000, March 2000.

27. Larman C, Basili VR. Iterative and incremental develop-ments: a brief history. Computer, 2003; 36(6): 47–56.

28. Lee EA. Cyber physical systems: Design challenges.In Proceedings of the 11th IEEE International Sympo-sium on Object Oriented Real-Time Distributed Computing(ISORC08), 363–369, May 2008.

29. Negulescu R. Process spaces. In CONCUR, volume 1877 ofLecture Notes in Computer Science. Springer-Verlag, 2000.

30. Object Management Group (OMG). Model driven architec-ture (MDA) FAQ. [online], http://www.omg.org/mda/.

31. Object Management Group (OMG). Unified Modeling Lan-guage (UML) specification. [online], http://www.omg.org/spec/UML/.

32. Object Management Group (OMG). A UML profile forMARTE, beta 1. OMG Adopted Specification ptc/07-08-04,OMG, August 2007.

33. Object Management Group (OMG). System modeling lan-guage specification v1.1. Technical report, OMG, 2008.

34. The Design Automation Standards Committee of the IEEEComputer Society, editor. 1850–2010—IEEE Standard for

Property Specification Language (PSL). IEEE ComputerSociety, 2010.

35. Hudak J, Feiler P, Gluch D. The Architecture Analysisand Design Language (AADL): An Introduction. SoftwareEngineering Institute (SEI) Technical Note, CMU/SEI-2006-TN-011, February 2006.

36. Passerone R, de Alfaro L, Henzinger TA, Sangiovanni-Vincentelli A. Convertibility verification and convertersynthesis: Two faces of the same coin. In Proceedingsof International Conference on Computer Aided Design,San Jose, CA., 2002.

37. Passerone R, Hafaiedh IB, Graf S, Benveniste A, Cancila D,Cuccuru A, Gérard S, Terrier F, Damm W, Ferrari A,Mangeruca L, Josko B, Peikenkamp T, Sangiovanni-Vincentelli A. Metamodels in Europe: Languages, tools, andapplications. IEEE Design Test Computers, 2009; 26(3):38–53.

38. Sudarsan R, Fenves SJ, Sriram RD, Wang F. A productinformation modeling framework for product lifecycle man-agement. Computer-Aided Design, 2005; 37: 1399–1411.

39. Raclet J-B, Badouel E, Benveniste A, Caillaud B, Legay A,Passerone R. Modal interfaces: Unifying interface automataand modal specifications. In Proceedings of the Ninth Inter-national Conference on Embedded Software (EMSOFT09),87–96, Grenoble, France, October 12–16, 2009.

40. Raclet J-B, Badouel E, Benveniste A, Caillaud B, Legay A,Passerone R. A modal interface theory for component-baseddesign. Fundamenta Informaticae, 2011; 108(1–2): 119–149.

41. Sangiovanni-Vincentelli A, Shukla S, Sztipanovits J, Yang G,Mathaikutty D. Metamodeling: An emerging representationparadigm for system-level design". Special Section on Meta-Modeling, IEEE Design and Test, 2009; 26(3): 54–69.

42. Functional safety of electrical/electronic/programmableelectronic safety-related systems. Standard IEC 61508.

43. Sztipanovits J. Composition of cyber-physical systems. InProceedings of the 14th Annual IEEE International Confer-ence and Workshops on the Engineering of Computer-BasedSystems (ECBS07), 3–6, March 2007.

44. Törngren M. Timing problems and opportunities for embed-ded control systems modeling and co-design, September 16,2011. Seminar at the University of California, Berkeley.

Documents

Taming Dr. Frankenstein: Contract-Based Design for …disi.unitn.it/~roby/pdfs/ASVDammPasserone12EJC.pdf · Taming Dr. Frankenstein: Contract-Based Design for Cyber-Physical Systems