Taming Dr. Frankenstein: Contract-Based Designfor Cyber-physical Systems

Alberto Sangiovanni-Vincentelli‖, Werner Damm∗∗,and Roberto Passerone‡,

‡University of Trento ‖University of California at Berkeley and University of Trento ∗∗Offis and University of Oldenburg

Abstract—Cyber-physical systems combine a cyber side (com-puting and networking) with a physical side (mechanical, electri-cal, and chemical processes). In many cases, the cyber componentcontrols the physical side using sensors and actuators thatobserve the physical system and actuate the controls. Suchsystems present the biggest challenges as well as the biggestopportunities in several large industries, including electronics,energy, automotive, defense and aerospace, telecommunications,instrumentation, industrial automation.

Engineers today do successfully design cyber-physical systemsin a variety of industries. Unfortunately, the development ofsystems is costly, and development schedules are difficult to stickto. The complexity of cyber-physical systems, and particularlythe increased performance that is offered from interconnectingwhat in the past have been separate systems, increases the designand verification challenges. As the complexity of these systems in-creases, our inability to rigorously model the interactions betweenthe physical and the cyber sides creates serious vulnerabilities.Systems become unsafe, with disastrous inexplicable failures thatcould not have been predicted. Distributed control of multi-scalecomplex systems is largely an unsolved problem.

A common view that is emerging in research programs inEurope and the US is “enabling contract-based design (CBD),”which formulates a broad and aggressive scope to address urgentneeds in the systems industry. We present a design methodologyand a few examples in controller design whereby contract-based design can be merged with platform-based design toformulate the design process as a meet-in-the-middle approach,where design requirements are implemented in a subsequentrefinement process using as much as possible elements from alibrary of available components. Contracts are formalizations ofthe conditions for correctness of element integration (horizontalcontracts), for lower level of abstraction to be consistent with thehigher ones, and for abstractions of available components to befaithful representations of the actual parts (vertical contracts).

I. INTRODUCTION

System industry that includes automotive, avionics and con-sumer electronics companies are facing significant difficultiesdue to the exponentially rising complexity of their productscoupled with increasingly tight demands on functionality,correctness, and time-to-market. The cost due to being late tomarket or due to imperfections in the products is staggering aswitnessed by the recent recalls and delivery delays that system

This work was supported in part by the EU project COMBEST grant n.215543, the EU NoE ArtistDesign grant n. 214373, the EU DANSE IP, theEuropean project CESAR of the ARTEMIS Joint Undertaking, and by theMultiscale Systems Center, one of six research centers funded under the FocusCenter Research Program, a Semiconductor Research Corporation program.

industries had to bear. There are examples of the devastatingeffects that design problems may cause.

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

In addition, there is a widespread consensus in the industrythat there is much to gain by optimizing the implementationphase that today is only considering a very small subset of thedesign space. Some attempts at a more efficient design spaceexploration have been afoot but there is a need to formalizethe problem better and to involve in major ways the differentplayers of the supply chain. Information about the capabilitiesof the subsystems in terms of timing, power consumption, size,weight and other physical aspects transmitted to the systemassemblers during design time would go a long way in pro-viding a better opportunity to design space exploration. In thislandscape, a wrong turn in a system design project could causean important economic, social and organizational upheavalthat may imperil the life of an entire company. No wonderthat there is much interest in risk management approaches toassess risks associated to design errors, delays, recalls andliabilities. Finding appropriate countermeasures to lower risksand to develop contingency plans is then a mainstay of the waylarge projects are managed today. The overarching issue is theneed of a substantive evolution of the design methodologyin use today in system companies. The issue to address is theunderstanding of the principles of system design, the necessarychange to design methodologies, and the dynamics of thesupply chain. Developing this understanding is necessary todefine a sound approach to the needs of the system companiesas they try to serve their customers better, to develop theirproducts faster and with higher quality.

The focus of this paper is on cyber-physical systems(CPS) [13], [43], [28]. Cyber-physical systems are integrationsof computation with physical processes. Embedded computers

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

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

1

and networks monitor and control the physical processes,usually with feedback loops where physical processes affectcomputations and vice versa.

The emerging applications of cyber-physical systems aredestined to run in distributed form on a platform that mesheshigh performance compute clusters (the infrastructure core)with broad classes of mobiles in turn surrounded by even largerswarms of sensors (from the very large to the microscopic).The broad majority of these new applications can be classifiedas “distributed sense and control systems” that go substantiallybeyond the “compute” or “communicate” functions, tradition-ally associated with information technology. These applica-tions have the potential to radically influence how we deal witha broad range of crucial problems facing our society today: forexample, national security and safety, including surveillance,energy management and distribution, environment control,efficient and reliable transportation and mobility, and effectiveand affordable health care. A recurring property of theseapplications is that they engage all the platform componentssimultaneously — from data and computing services on thecloud of large-scale servers, data gathering from the sensoryswarm, and data access on the mobiles. Another propertyis that the resulting systems span many scales — in space(from the very large to the very small), in time (from thevery fast to the very slow), in function (consisting of complexhierarchies of heterogeneous functionalities), and in technol-ogy (integrating a broad range of diverse technologies). Eachof the components of this distributed platform (compute anddata clusters, mobiles/portables, and sensory systems) forms amulti-scale system on its own, and offers some unique designchallenges.

Engineers today do successfully design cyber-physical sys-tems in a variety of industries. Unfortunately, the developmentof systems is costly, and development schedules are difficultto stick to. The complexity of cyber-physical systems, andparticularly the increased performance that is offered frominterconnecting what in the past have been separate systems,increases the design and verification challenges. As the com-plexity of these systems increases, our inability to rigorouslymodel the interactions between the physical and the cybersides creates serious vulnerabilities. Systems become unsafe,with disastrous inexplicable failures that could not have beenpredicted.

The challenges in the realization and operation of thesemulti-scale systems are manifold, and cover a broad range oflargely unsolved design and run-time problems. These include:modeling and abstraction, verification, validation and test,reliability and resiliency, multi-scale technology integrationand mapping, power and energy, security, diagnostics, andrun-time management. Failure to address these challengesin a cohesive and comprehensive way will most certainlydelay if not prohibit the widespread adoption of these newtechnologies.

We believe the most promising means to address the chal-lenges in systems engineering of cyber-physical systems isto employ structured and formal design methodologies that

seamlessly and coherently combine the various dimensionsof the multi-scale design space (be it behavior, space ortime), that provide the appropriate abstractions to managethe inherent complexity, and that can provide correct-by-construction implementations.

The following technology issues must be addressed whendeveloping new approaches to system design:

• The overall design flows for heterogeneous systems —meant here both in a technical and also an organizationalsense — and the associated use of models across tradi-tional boundaries are not well developed and understood.

• The verification of “complex systems,” particularly atthe system integration phase, where any interactions arecomplicated and extremely costly to address, is a commonneed in defense, automotive, and other industries.

• Dealing with variability, uncertainty, and life-cycle issues,such as extensibility of a product family, are not well-addressed using available systems engineering methodol-ogy and tools.

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

• Design-space exploration is rarely performed adequately,yielding suboptimal designs where the architecture se-lection phase does not consider extensibility, re-usability,and fault tolerance to the extent that is needed to reducecost, failure rates, and time-to-market.

The design technology challenge is to address the entireprocess and not to consider only point solutions of methodol-ogy, tools, and models that ease part of the design. Addressingthis challenge calls for new modeling approaches that can mixdifferent physical systems, control logic, and implementationarchitectures. In doing so, existing approaches, models, andtools must be subsumed and not eliminated to ensure thatdesigners can evolve smoothly their design methods and do notreject the proposed design innovations. In particular, a designplatform has to be developed to host the new techniques andto integrate a set of today’s poorly interconnected tools.

A common view that is emerging in research programs inEurope and the US is “enabling contract-based design,” whichformulates a broad and aggressive scope to address urgentneeds in the systems industry. Contracts in the layman useof the term are established when an OEM must agree withits suppliers on the subsystem or component to be delivered.Contracts involve a legal part binding the different partiesand a technical annex that serves as a reference regarding theentity to be delivered by the supplier. Contracts can also beused through their technical annex in concurrent engineering,when different teams develop different subsystems or differentaspects of a system within a same company. In our view ofthe term, contracts can be actually used everywhere and at

2

all stages of system design, from early requirements capture,to embedded computing infrastructure and detailed designinvolving circuits and other hardware. In particular, contractsexplicitly handle pairs of properties, respectively representingthe assumptions on the environment and the promises of thesystem under these assumptions. More formally, a contract isa pair C = (A,G) of {Assumptions, Promises}, where bothA and G are properties satisfied by the set of all inputs andall outputs of a design.

Assume/Guarantee reasoning has been known for quitesome time, but it has been used mostly as verification mean forthe design of software. Our purpose is much more ambitious:contract based design with explicit assumptions is a designphilosophy that should be followed all along the design, withall kinds of models, whenever necessary. Here, the modelswe mean are rich — not only profiles, types, or taxonomy ofdata, but also models describing the functions, performancesof various kinds (time and energy), and safety.

To make contract-based design a technique of choice forsystem engineers, we must develop:• Mathematical foundations for contract representation and

requirement engineering that enable the design of frame-works and tools;

• A system engineering framework and associated method-ologies and tool sets that focus on system require-ment modeling, contract specification, and verification forcyber-physical systems at multiple abstraction layers.

• A systems engineering framework focusing on cross-boundary design flows that include addressing the organi-zational impacts of contract design and the evolution overtime of systems, including configuration management.

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

In the following sections, we will review methods to copewith the challenges posed in the introduction. It is indeed ourtake that the concept of contract is a unifying view on how toformalize requirements and rules that appear at all steps of thedesign process. Then, we will provide a short formalization ofthe notion of contract. Armed with this notion, we show how tocombine contracts with platform-based design to encompassall other methods. We present a simple control problem todemonstrate the use of the proposed methodology and we closethe paper presenting potential developments that could makethe use of contracts pervasive in industry.

II. ADDRESSING THE SYSTEM DESIGN CHALLENGES: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, as theyare hitting a wall in the development of the next generationsystems, this situation is rapidly changing. Major productivitygains are needed and better verification and validation is anecessity as the safety and reliability requirements becomemore stringent and complexity is hitting an all-time high.Our experience is that many of the design chain problems

are typical of very diverse verticals, the difference betweenthem being in the importance given to time-to-market and tothe customer appeal of the products versus safety and hard-time constraints. This consideration motivates the view that aunified methodology and framework could be used in many(if not all) industrial vertical domains.

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

A. Coping with complexity of systems

Multiple lines of attack have been developed by researchinstitutions and industry to cope with the exponential growthin systems complexity, starting from the iterative and incre-mental development several decades ago [27]. Among them, ofparticular interest to the development of embedded controllersare: Layered design, Component-based design, the V-modelprocess, Model-based development, Virtual integration andPlatform-Based Design. We review them next.

1) Layered design: Layered design copes with complexityby focusing on those aspects of the system pertinent to supportthe design activities at the corresponding level of abstraction.This approach is particularly powerful if the details of alower layer of abstraction are encapsulated when the designis carried out at the higher layer. Layered approaches are wellunderstood and standard in many application domains. As anexample, consider the AUTOSAR standard,3. This standarddefines several abstraction layers. Moving from “bottom”to “top”, the micro-controller abstraction layer encapsulatescompletely the specifics of underlying micro-controllers, thesecond layer abstracts from the concrete configuration of theElectronic Control Unit (ECU), the employed communicationservices and the underlying operating system, whereas the(highest) application layer is not aware of any aspect of

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

3

http://www.autosar.org/

possible target architectures, and relies on purely virtual com-munication concepts in specifying communication betweenapplication components. Similar abstraction levels are definedby the ARINC standard in the avionic domains.

The benefits of using layered design are manifold. Usingthe AUTOSAR layer structure as example, the completeseparation of the logical architecture of an application (asrepresented by a set of components interconnected using theso-called virtual function bus) and target hardware is a keyaspect of AUTOSAR, in that it supports complete decouplingof the number of automotive functions from the number ofhardware components. In particular, it is flexible enough tomix components from different applications on one and thesame ECU. This illustrates the double role of abstractionlayers, in allowing designers to focus completely in thiscase on the logic of the application and abstracting fromthe underlying hardware, while at the same time imposing aminimal (or even no) constraint on the design space of possiblehardware architectures. In particular, these abstractions allowthe application design to be re-used across multiple platforms,varying in number of bus-systems and/or number and class ofECUs. These design layers can, in addition, be used to matchthe boundaries of either organizational units within a company,or to define interfaces between different organizations in thesupply chain.

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

Using what we call vertical assumptions as abstractions ofthe underlying target hardware can solve this dilemma. Re-turning to the above example, such vertical assumptions couldexplicate the failure hypothesis of either execution platforms orcommunication platforms, and thus decorate either (individualRunnables4) components or entities of the virtual function bus.In more general terms, any logical communication must beseen as a (fictitious) component itself, which, at deploymenttime, will be mapped to communication services of the oper-

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

ating system.2) Component-based design: Whereas layered designs de-

compose complexity of systems “vertically”, component-basedapproaches reduce complexity “horizontally” whereby designsare obtained by assembling strongly encapsulated design enti-ties called “components” equipped with concise and rigorousinterface specifications. Re-use can be maximized by findingthe weakest assumptions on the environment sufficient to es-tablish the guarantees on a given component implementation.While these interface specifications are key and relevant forany system, the “quality attribute” of perceiving a subsystemas a component is typically related to two orthogonal criteria,that of “small interfaces”, and that of minimally constrainingthe deployment context, so as to maximize the potential forre-use. “Small interfaces”, i.e., interfaces which are both smallin terms of number of interface variables or ports, as well as“logically small”, in that protocols governing the invocation ofcomponent services have compact specifications not requiringdeep levels of synchronization, constitute evidence of the suc-cess of encapsulation. The second quality attribute is naturallyexpressible in terms of interface specifications, where re-usecan be maximized by finding the weakest assumptions on theenvironment sufficient to establish the guarantees on a givencomponent implementation.

One challenge, then, for component-based design of em-bedded systems, is to provide interface specifications that arerich enough to cover all phases of the design cycle. Thiscalls for including non-functional characteristics as part ofthe component interface specifications, which is best achievedby using multiple viewpoints. Current component interfacemodels, in contrast, are typically restricted to purely functionalcharacterization of components, and thus cannot capitalize onthe benefits of virtual integration testing, as outlined above.

The second challenge is related to product line design,which allows for the joint design of a family of variants of aproduct. The aim is to balance the contradicting goals of striv-ing for generality versus achieving efficient component im-plementations. Methods for systematically deriving “quotient”specifications to compensate for “minor” differences betweenrequired and offered component guarantees by composing acomponent with a wrapper component (compensating for suchdifferences as characterized by quotient specifications) existsfor restricted classes of component models [36].

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

Its characteristic V-shape splits the product developmentprocess into a design and an integration phase. Specifically,following product level requirement analysis, subsequent stepswould first evolve a functional architecture supporting productlevel requirements. Sub-functions are then re-grouped taking

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

4

http://www.v-model-xt.de

Safety A

ssesment P

rocess

e.g. Maintainability A

ssessment P

rocess

Softw

areM

echanical

Digital H

ardware

Electrical

e.g. Cost A

ssessment P

rocess

Development of Technology

oriented Architecture

Development of

Logical Architecture

Subsystem

Integration

Development

of ECU

Architecture

Development of

Functional Architecture

Analysis of Product

Level Reqiuirements

Integration

Product

Integration

System

Cer

tific

atio

n

Figure 1. The V Model.

into account re-use and product line requirements into a logicalarchitecture, whose modules can be developed independently,e.g., by different subsystem suppliers. The realization of suchmodules often involves mechatronic design. The top-levelof the technology-oriented architecture would then show themechatronic architecture of the module, defining interfacesbetween the different domains of mechanical, hydraulic, elec-trical, and electronic system design, such as exemplified belowfor the mechatronic architecture of a simplified aircraft brakingsystem. Subsequent phases would then unfold the detaileddesign for each of these domains, such as the design of theelectronic subsystem involving among others the design ofelectronic control units. These design phases are paralleledby integration phases along the right-hand part of the V,such as integrating basic- and application software on theECU hardware to actually construct the electronic control unit,integrating the complete electronic subsystems, integrating themechatronic subsystem to build the module, and integratingmultiple modules to build the complete product. Not shown,but forming an integral part of V-based development processesare testing activities, where at each integration level test-suites developed during the design phases are used to verifycompliance of the integrated entity to their specification.

This presentation is overly simplistic in many ways. Thedesign of electronic components in complex systems suchas aircrafts inherently involves multi-site, multi-domain andcross-organizational design teams, reflecting, e.g., a parti-tioning of the aircraft into different subsystems (such asprimary and secondary flight systems, cabin, fuel, and wing),different domains such as the interface of the electronicsubsystem to hydraulic and/or mechanical subsystems, control-law design, telecommunications, software design, hardwaredesign, diagnostics, and development-depth separated designactivities carried out at the OEM and supplier companies.This partitioning of the design space (along perspectives andabstraction layers) naturally lends itself to a parallelization ofdesign activities, a must in order to achieve timely delivery ofthe overall product, leading often into the order of hundredsof concurrent design processes.

Secondly, each of these sub-processes will have its own

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

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

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

Monitor

2

Command

2

Command

1

Monitor

1

Braking System Control Unit

(BSCU)

AccumulatorReserve

Mechanical

Pedal Position

Wheel

Pow

er 1

Pow

er 2

Ped

al

Pos

ition

1

Ped

al

Pos

ition

2Green

Pump

Blue

Pump

Isolation

Valve

Shut Off

Selector

Valve

Meter

Valve

Meter

Valve

Anti Skid

Shut Off

Valve

Selector ValveNor

mal

Alte

rnat

e

Anti Skid (AS)

Command (CMD) /

Anti Skid

CD

M /

AS

1

AS

1

AS

2CDM

/ AS

2

1 In

valid

2 In

valid

HYDRAULICELECTRICAL

CO

MP

UT

ER

/ D

IG

IT

AL

MECHANICAL

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

4) Model-Based Development: Model-based development(MBD) is today generally accepted as a key enabler tocope with complex system design due to its capabilitiesto support early requirement validation and virtual systemintegration. MBD-inspired design languages and tools suchas SysML6 [33] and/or AADL [35] for system level model-ing, Catia and Modelica [18] for physical system modeling,

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

5

http://www.omg.org/spec/SysML/

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, simula-tion coupled with requirement monitoring, co-simulation ofheterogeneous models such as UML and Matlab-Simulink,model-based analysis including verification of complianceof requirements and specification models, model-based test-generation, rapid prototyping, and virtual integration testingas further elaborated below.

In MBD today non-functional aspects such as performance,timing, power or safety analysis are typically addressed indedicated specialized tools using tool-specific models, withthe entailed risk of incoherency between the correspond-ing models, which generally interact. To counteract theserisks, meta-models encompassing multiple views of designentities, enabling co-modeling and co-analysis of typicallyheterogeneous viewpoint specific models have been developed.Examples include the MARTE UML [32] profile for real-time system analysis, the SPEEDS HRC metamodel [37] andthe Metropolis semantic meta-model [2], [11], [3], [41]. InMetropolis multiple views are accommodated via the conceptof “quantities” that annotate the functional view of a designand can be composed along with subsystems. Quantities areequipped with an “algebra” that allows quantities associatedto compositions of subsystems to be computed from thequantities of each of the subsystems. Multiple quantities suchas timing and power can be handled simultaneously. Alongthe same lines, the need to enable integration of point-toolsfor multiple viewpoints with industry standard developmenttools has been the driving force in providing the SPEEDSmeta-model building on and extending SysML, which hasbeen demonstrated to support co-simulation and co-analysisof system models for transportation applications allowing co-assessment of functional, real-time and safety requirements,and forms an integral part of the meta-model-based inter-operability concepts of the CESAR (see www.cesarproject.eu) reference technology platform. The SPEEDS meta-modelbuilding on and extending SysML has been demonstrated tosupport co-simulation and co-analysis of system models fortransportation applications allowing co-assessment of func-tional, real-time and safety requirements. It forms an integralpart of the meta-model-based inter-operability concepts of theCESAR reference technology platform.

Meta-modeling is also at the center of the model driven(software) development (MDD) methodology. MDD is basedon the concept of the model-driven architecture (MDA), whichconsists of a Platform-Independent Model (PIM) of the ap-plication plus one or more Platform-Specific Models (PSMs)and sets of interface definitions. MDA tools then support themapping of the PIM to the PSMs as new technologies becomeavailable or implementation decisions change [30]. This issimilar to Platform-Based Design, however the definition ofplatform is not fully described in MDD nor are the semantics

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

to be used for embedded software design. The VanderbiltUniversity group [24] has evolved an embedded softwaredesign methodology and a set of tools based on MDD.In their approach, models explicitly represent the embeddedsoftware and the environment it operates in and capture therequirements and the design of the application, simultane-ously, using domain-specific languages (DSL). The genericmodeling environment (GME) [24] provides a framework formodel transformations enabling easy exchange of models be-tween tools and offers sophisticated ways to support syntactic(but not semantic) heterogeneity. The KerMeta metamodelingworkbench [17] is similar in scope.

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

Virtual system integration is often a source of heteroge-neous system models, such as when realizing an aircraftfunction through the combination of mechanical, hydraulic,and electronic systems — virtual system integration thenrests on well defined principles allowing the integration ofsuch heterogeneous models. Heterogeneous composition ofmodels with different semantics was originally addressedin Ptolemy [16] and Metropolis [2], [11], [3] albeit withdifferent approaches. These approaches have then been furtherelaborated in the SPEEDS meta-model of heterogeneous richcomponents [10]. Virtual integration involves models of thefunctions, the computer architecture with its extra-functionalcharacteristics (timing and other resources), and the physicalsystem for control. Some existing frameworks offer significantsupport for virtual integration: Ptolemy II, Metropolis, andRT-Builder. Developments around Catia and Modelica as wellas the new offer SimScape by Simulink provide support forvirtual integration of the physical part at an advanced level.

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

Instances of virtual integration tests revealing failed integra-tion early in the V include:

• The lack of a component to provide complete fault isola-tion (a property presumed by a neighboring subsystem);

6

www.cesarproject.euwww.cesarproject.euhttp://www.omg.org/spec/UML/

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

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

erty presumed by a neighboring subsystem).First, the above approach to virtual integration testing is

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

This entails that, at any level of the supplier hierarchy, thehigher-level organization can — prior to contracting suppliers— analyze whether the subsystems contracts pass the virtualintegration test and are sufficient to establish the systemrequirements. By then basing the contracts to suppliers on thesubsystem contracts, and requiring subsystem suppliers to giveevidence (such as through testing or through formal analysismethods) that their implementation complies to their contract,the final integration of subsystems to the complete system willbe free of all classes of integration errors covered by contractsin the virtual integration test.

B. Coping with the complexity of the supply chain

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

applications with different criticality levels to co-exist (suchas ASIL levels[42], [1] in automotive).

1) Standardization of design entities: By agreeing on (do-main specific) standard representations of design entities,different industrial domains have created their own linguafranca, thus enabling a domain wide shared use of designentities based on their standardized representation. Exam-ples of these standards in the automotive sector include therecently approved requirement interchange format standardRIF8, the AUTOSAR9 de-facto standard, the OSEK10 operat-ing system standard, standardized bus-systems such as CAN11

and Flexray12, standards for “car2X” communication, andstandardized representations of test supported by ASAM13.Examples in the aerospace domain include ARINC stan-dards14 such as the avionics applications standard interface,IMA, RTCA15 communication standards. In the automationdomain, standards for interconnection of automation devicessuch as Profibus16 are complemented by standardized designlanguages for application development such as Structured Text.

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

2) Standardization/harmonization of processes: Harmoniz-ing or even standardizing key processes (such as developmentprocesses and safety processes) provides for a further levelof optimization in interactions across the supply chain. As anexample, Airbus Directives and Procedures (ADBs) providerequirements for design processes of equipment manufactures.Often, harmonized processes across the supply chain buildon agreed maturity gates with incremental acceptance testingto monitor progress of supplier development towards finalacceptance, often building on incremental prototypes. Shareduse of Product Lifcycle Management (PLM) [38] databasesacross the supply chain offers further potentials for cross-supply chain optimization of development processes. Also, in

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

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

7

http://www.w3.org/2005/rules/wiki/RIF_Working_Grouphttp://www.autosar.org/http://www.osek-vdx.org/http://www.iso.org/iso/search.htm?qt=Controller+Area+Network&searchSubmit=Search&sort=rel&type=simple&published=truehttp://www.iso.org/iso/search.htm?qt=Controller+Area+Network&searchSubmit=Search&sort=rel&type=simple&published=truehttp://www.flexray.com/http://www.asam.net/http://www.aeec-amc-fsemc.com/standards/index.htmlhttp://www.rtca.org/http://www.profibus.com/

domains developing safety related systems, domain specificstandards clearly define the responsibilities and duties ofcompanies across the supply chain to demonstrate functionalsafety, such as in the ISO 2626217 for the automotive domain,IEC 6150818 for automation, its derivatives Cenelec EN 50128and 5012619 for rail, and Do 178 B20 for civil avionics.

Yet, the challenge in defining standards rests in balancingthe need for stability with the need of not blocking processinnovations. As an example, means for compositional con-struction of safety cases are seen as mandatory to reducecertification costs in the aerospace and rail domains. Similarly,the potential of using formal verification techniques to copewith increasing system complexity is considered in the movefrom DO 178 B to DO 178 C standards.

C. Getting initial requirements right

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

To cope with the inherently unstructured problem of(in)completeness of requirements, industry has set up domain-and application-class specific methodologies. As particularexamples, we mention learning process, such as employedby Airbus to incorporate the knowledge base of externalhazards from flight incidents, the Code of Practice proposedby the Prevent Project using guiding questions to assess thecompleteness of requirements in the concept phase of thedevelopment of advanced driver assistance systems. Use-caseanalysis methods as advocated for UML based developmentprocess follow the same objective. A common theme of theseapproaches is the intent to systematically identify those aspectsof the environment of the system under development whoseobservability is necessary and sufficient to achieve the systemrequirements. Pushing this further again leads to using con-tracts: based on a determined system boundary, responsibilitiesof achieving requirements are split into those to be establishedby the system-under-development (the “guarantees” of thecontract) and those characterizing admissible environmentsof the system-under-development (the “assumptions” of thecontract).

However, the most efficient way of assessing completenessof a set of requirements is by executing it. This consistsin what David Harel called “playing out” for the particularcase of live sequence charts [20], [21], [22], i.e., the use offormalized contract specifications to generate trajectories ofinterface observations compliant with the considered set ofcontracts. Such simulation capabilities turn out to be instru-mental in revealing incompleteness: typically, they will exhibit

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

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

unexpected traces, e.g., due to an insufficient restriction ofthe environment, or only partially specified system reactions.Executing requirements is only possible if semi-formal orformal specification languages are used, where the particu-lar shape of such formalizations is viewpoint and domaindependent. Examples include the use of failure propagationmodels for safety contracts, the use of probabilistic timedautomata to specify arrival processes, the use of live sequencecharts for capturing scenarios in the interaction of actors andsystems, or formalized requirement languages such as thePSL standard [34] combining temporal logic and automatabased specifications used in the EDA domain, or the pattern-based contract specification language defined by the integratedproject SPEEDS.

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

D. Coping with multi-layer design optimization

System designs are often the result of modifications ofprevious designs with the attempt of minimizing risks andreducing delays and design costs. While this was an effectiveway of bringing new products to market in the past, with theincrease in demand for new functionality and the advances ofthe implementation platforms, this strategy has yielded moreproblems than it has fixed. Indeed, there is a shared consensusthat in most of the cases the designs are not optimized inthe sense that the full exploitation of the new opportunitiestechnology offers is not achieved and that having visibility ofthe available options and an evaluation framework for designalternatives are a sorely missing capability.

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

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

8

http://www.iso.org/iso/catalogue_detail.htm?csnumber=43464http://www.iec.ch/functionalsafety/http://www.cenelec.eu/Cenelec/CENELEC+in+action/Web+Store/Standards/default.htmhttp://www.cenelec.eu/Cenelec/CENELEC+in+action/Web+Store/Standards/default.htmhttp://www.do178site.com/

E. Managing risk across the development process

The realization of complex systems calls for design pro-cesses that mitigate risks in highly concurrent, distributed,and typically multi-domain engineering processes, often in-volving more than one hundred sub-processes. Risk mitigationmeasures typically cover all phases of design processes, rang-ing from ensuring high quality initial requirements to earlyassessments of risks in realizability of product requirementsduring the concept phase, to enforcing complete traceabilityof such requirements with requirements management tools, tomanaging consistency and synchronization across concurrentsub-processes using PLM tools. A key challenge rests inbalancing risk reduction versus development time and effort:completely eliminating the risks stemming from concurrentengineering essentially requires a complete synchronizationalong a fine-grained milestone structure, which would kill anydevelopment project due to the induced delays.

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

III. CONTRACT MODEL OVERVIEWIn this section we briefly summarize the main concepts

behind contract-based design by presenting a simple genericcontract model centered around the notion of component.A component is a hierarchical entity that represents a unitof design. Components are connected together by sharingand agreeing on the values of certain ports and variables. Acomponent may include both implementations and contracts.An implementation M is an instantiation of a component andconsists of a set P of ports and variables (in the following,for simplicity, we will refer only to ports) and of a set ofbehaviors, or runs, also denoted by M , which assign a historyof “values” to ports. Runs are generic and abstract, sincewe do not need a predetermined form of behavior for ourbasic definitions. The particular structure of the runs is definedby specific instances of the model. For instance, runs couldbe continuous functions that result from solving differentialequations, or sequences of values or events recognized by anautomata model. Our basic definitions will not vary, and onlythe way operators are implemented is affected.

We build the notion of a contract for a component as apair of assertions, which express its assumptions and promises.An assertion E is modeled as a set of behaviors over ports,precisely as the set of behaviors that satisfy it. An implemen-tation M satisfies an assertion E whenever they are definedover the same set of ports and all the behaviors of M satisfy

the assertion, i.e., when M ⊆ E. A contract is an assertionon the behaviors of a component (the promise) subject tocertain assumptions. We therefore represent a contract C asa pair (A,G), where A corresponds to the assumption, and Gto the promise. An implementation of a component satisfiesa contract whenever it satisfies its promise, subject to theassumption. Formally, M ∩ A ⊆ G, where M and C havethe same ports. We write M |= C when M satisfies a contractC.

Intuitively, an implementation can only provide promiseson the value of the ports it controls. On ports controlled bythe environment, instead, it may only declare assumptions.Therefore, we will distinguish between two kinds of ports:those that are controlled and those that are uncontrolled. Un-controllability can be formalized as a notion of receptiveness:for E an assertion, and P ′ ⊆ P a subset of its ports, E issaid to be P ′-receptive if and only if for all runs σ′ restrictedto ports belonging to P ′, there exists a run σ ∈ E such thatσ′ and σ coincide over P ′. In words, E accepts any historyoffered to the subset P ′ of its ports. This closely resemblesthe classical notion of inputs and outputs in programs andHDLs; it is more general, however, as it encompasses not onlyhorizontal compositions within a same layer, but also cross-layer integration such as the integration between applicationand execution platform performed at deployment. Contractsare therefore enriched with a profile π = (u, c) that partitionsits set of ports.

The combination of contracts associated to different com-ponents can be obtained through the operation of parallelcomposition. If C1 = (A1, G1) and C2 = (A2, G2) arecontracts (possibly over different sets of ports), the compositemust satisfy the guarantees of both, implying an operationof intersection. The situation is more subtle for assumptions.Suppose first that the two contracts have disjoint sets of ports.Intuitively, the assumptions of the composite should be simplythe conjunction of the assumptions of each contract, since theenvironment should satisfy all the assumptions. In general,however, part of the assumptions A1 will be already satisfiedby composing C1 with C2, acting as a partial environment forC1. Therefore, G2 can contribute to relaxing the assumptionsA1. And vice-versa. The assumption and the promise of thecomposite contract C = (π,A, G) can therefore be computedas 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 the propertythat each port should be controlled by at most one contract.Hence, parallel composition is defined only if the sets ofcontrolled ports of the contracts are disjoint.

Parallel composition can be used to construct complex con-tracts out of simpler ones, and to combine contracts of differentcomponents. Despite having to be satisfied simultaneously,however, multiple viewpoints associated to the same compo-nent do not generally compose by parallel composition. Take,

9

for instance, a functional viewpoint Cf and an orthogonaltimed viewpoint Ct for a component M . Contract Cf specifiesallowed data pattern for the environment, and sets forth thecorresponding behavioral property that can be guaranteed. Forinstance, if the environment alternates the values T,F,T, . . .on port a, then the value carried by port b never exceedsx. Similarly, Ct sets timing requirements and guarantees onmeeting deadlines. For example, if the environment provides atleast one data per second on port a (1ds), then the componentcan issue at least one data every two seconds (.5ds) on portb. Parallel composition fails to capture their combination,because the combined contract must accept environments thatsatisfy either the functional assumptions, or the timing assump-tions, or both. In particular, parallel composition computesassumptions that are too restrictive. We would like, instead,to compute the conjunction u of the contracts, so that ifM |= Cf uCt, then M |= Cf and M |= Ct. This can best beachieved by first defining a partial order on contracts, whichformalizes a notion of substitutability, or refinement. We saythat C = (A,G) dominates C ′ = (A′, G′), written C � C ′,if and only if A ⊇ A′ and G ⊆ G′. Dominance amountsto relaxing assumptions and reinforcing promises, thereforestrengthening the contract. Clearly, if M |= C and C � C ′,then M |= C ′.

Given the ordering of contracts, we can compute greatestlower bounds and least upper bounds, which correspond totaking the conjunction and disjunction of contracts, respec-tively. For contracts C1 = (A1, G1) and C2 = (A2, G2) (incanonical form), we have

C1 u C2 = (A1 ∪A2, G1 ∩G2), (3)C1 t C2 = (A1 ∩A2, G1 ∪G2). (4)

Conjunction of contracts amounts to taking the union of theassumptions, as required, and can therefore be used to computethe overall contract for a component starting from the contractsrelated to multiple viewpoints.

Relations between contracts: We have already discussedtwo relations that can be established between contracts andimplementations. A relation of satisfaction, that denotes whenan implementation satisfies a contract (i.e., provides the re-quired promises under the stated assumptions), and a relationof refinement between contracts, that denotes the process ofconcretizing the requirements by strengthening the promisesand relaxing the assumptions. Contracts can also be relatedby a notion of consistency and compatibility. Technically,these two notions refer to individual contracts. In practice,however, violations of these properties occur as a result of aparallel composition, so that we can refer to the collection ofcomponents forming a contract as consistent or compatible.

The notion of receptiveness and the distinction betweencontrolled and uncontrolled ports is at the basis of our re-lations of consistency and compatibility between contracts.Our first requirement is that an implementations M withprofile π = (u, c) be u-receptive, formalizing the fact that animplementation has no control over the values of ports set by

the environment. For a contract C, we say that C is consistentif G is u-receptive, and compatible if A if c-receptive.

The sets A and G are not required to be receptive. However,if G is not u-receptive, then the promises constrain theuncontrolled ports of the contract. In particular, the contractadmits no receptive implementation. This is against our policyof separation of responsibilities, since we stated that uncon-trolled ports should remain entirely under the responsibility ofthe environment. Corresponding contracts are therefore calledinconsistent.

The situation is dual for assumptions. If A is not c-receptive,then there exists a sequence of values on the controlled portsthat are refused by all acceptable environments. However, byour definition of satisfaction, implementations are allowed tooutput such sequence. Unreceptiveness, in this case, impliesthat a hypothetical environment that wished to prevent a vio-lation of the assumptions should actually prevent the behavioraltogether, something it cannot do since the port is controlledby the contract. Therefore, unreceptive assumptions denote theexistence of an incompatibility internal to the contract, thatcannot be avoided by any environment.

IV. PLATFORM-BASED AND CONTRACT-BASED DESIGN

In the previous sections, we reviewed a number of ap-proaches that tackle the challenges set up in the introductionand we introduced the basics of contracts. We argue here thatPlatform Based Design (PBD) subsumes most of the otherapproaches to system level design and for this reason, we willuse it to develop the concept of contract-based design, albeitthe extreme flexibility of contracts allows their universal usein all methodologies.

Contract-based design can be merged with platform-baseddesign to formulate the design process as a meet-in-the-middleapproach, where design requirements are implemented in asubsequent refinement process using as much as possibleelements from a library of available components. Contractsare formalizations of the conditions for correctness of elementintegration (horizontal contracts), for lower level of abstractionto be consistent with the higher ones, and for abstractionsof available components to be faithful representations of theactual parts (vertical contracts). A typical use of contracts incyber-physical system design would be to govern the horizon-tal composition of the cyber and the physical components andto establish the conditions for correctness of their composition.

A. Platform-Based Design

Platform-based design was introduced in the late 1980sto capture a design process that could encompass horizon-tal (component-based design, virtual integration) and vertical(layered and model-based design) decompositions, and multi-ple viewpoints and in doing so, support the supply chain aswell as multi-layer optimization.

The idea was to introduce a general approach that couldbe shared across industrial domain boundaries, that wouldsubsume the various definition and design concepts, and thatwould extend it to provide a rigorous framework to reason

10

about design. Indeed, the concepts have been applied to avariety of very different domains: from automotive, to System-on-Chip, from analog circuit design, to building automation tosynthetic biology.

The basic tenets of platform-based design are as follows:The design progresses in precisely defined abstraction layers;at each abstraction layer, functionality (what the system issupposed to do) is strictly separated from architecture (howthe functionality could be implemented). This aspect is clearlyrelated to layered design and hence it subsumes it.

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

• A set of library components. This library not only con-tains computational blocks that carry out the appropriatecomputation but also communication components that areused to interconnect the computational components.

• Models of the components that represent a characteri-zation in terms of performance and other non-functionalparameters together with the functionality it can support.Not all elements in the library are pre-existing com-ponents. Some may be “place holders” to indicate theflexibility of “customizing” a part of the design that isoffered to the designer. In this case the models representestimates of what can be done since the components arenot available and will have to be designed. At times, thecharacterization is indeed a constraint for the implementa-tion of the component and it is obtained top-down duringthe refinement process typical of layered designs. Thislayering of abstractions based on mathematical models istypical of model-based methods and the introduction ofnon-functional aspects of the design relates to viewpoints.

• The rules that determine how the components can beassembled and how the the functional and non-functionalcharacteristics can be computed given the ones of thecomponents to form an architecture.Then, a platform rep-resents a family of designs that satisfies a set of platform-specific constraints. This aspect is related to component-based design enriched with multiple viewpoints.

This concept of platform encapsulates the notion of re-use asa family of solutions that share a set of common features (theelements of the platform). Since we associate the notion ofplatform to a set of potential solutions to a design problem, weneed to capture the process of mapping a functionality (whatthe system is supposed to do) with the platform elements thatwill be used to build a platform instance or an “architecture”(how the system does what it is supposed to do). The strictseparation between function and architecture as well as themapping process have been highly leveraged in AUTOSAR.This process is the essential step for refinement and provides amechanism to proceed towards implementation in a structuredway. Designs on each platform are represented by platform-specific design models. A design is obtained by a designer’screating platform instances (architectures) via composing plat-form components (process that is typical of component-baseddesign), by mapping the functionality onto the components of

the architecture and by propagating the mapped design in thedesign flow onto subsequent abstraction layers that are dealtwith in the same way thus presenting the design process asan iterative refinement. This last point dictates how to moveacross abstraction layers: it is an important part of design spaceexploration and offers a way of performing optimization acrosslayers. In this respect PBD supports multiple perspectives ina general way.

B. Contract-based Design

In PBD, contracts can play a fundamental role in determin-ing the correct composition rules so that when the architecturespace is explored, only “legal” compositions of availablecomponents are taken into consideration. They can be used toverify whether the system obtained by composing the libraryelements according to the horizontal contracts satisfies therequirements posed at the higher level of abstraction. If thesesets of contracts are satisfied, the mapping mechanism of PBDcan be used to produce design refinements that are correct byconstruction.

To be more precise about these concepts, consider a snap-shot in a platform based design process, as shown in Figure 3,covering adjacent design layers N +1, N , and N −1. SystemS is realized at layer N by the composition of systems S1,S2, and S3.

Figure 3. Contracts in a PBD flow.

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

11

As an example of this contract-based virtual integrationtesting, consider Figure 3. Each of the subsystems Sj areequipped with horizontal contracts CH(Sj) = (AHj , GHj ).Contract-based virtual integration testing then requires to beable to demonstrate all assumptions AHj 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, weexpect the guarantee GH1 of the horizontal contract of S1 tobe sufficient to demonstrate compliance of any restrictions S2was placing on allowed uses of p21. Note also the dependencyof S2 on the yet undetermined part of the design context ofS2 reflected by input p3S to the realization of system S onlayer N . In general, then, in contract-based virtual integrationtesting, this yet unknown design context is represented byhorizontal contracts of the composed system S itself; Figure 3highlights the horizontal contract CHN (S) = (AHN (S), GHN (S))of S at layer N . This contract will enforce, that any designcontext of S will be guaranteed to be compliant to AHN (S).Thus, when checking the design context of S2 for complianceto its horizontal assumptions on uses of port p3S , we expectthis to be derivable from AHN (S). In general, then, in contract-based virtual integration testing, we need to demonstrate thatall horizontal assumptions of subsystems can be derived fromthe conjunction of all horizontal guarantees of subsystems andhorizontal assumptions of the composed system.

Circular reasoning: At the current level of discourse wepoint to the fact, that the above argument typically involvescircular reasoning. For example, in Figure 3 GH1 will only beguaranteed for legal design contexts of S1. Thus, only onceAH1 is established, can we actually rest our argumentationon GH1 . Establishing, then, A

H1 , we would like to involve

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

This, finally, would involve GH2 as witness, but it is exactlyfor the purpose of establishing AH2 , that this reasoning chainis established. The mathematical theory essentially justifiesthe use of such seemingly circular arguments, for classes ofcontracts whose assumptions and guarantees are expressiblein the rich set of safety properties (which can always beproven and disproved by finite observations). However, certainrestrictions on how assumptions and guarantees refer to out-ports respectively in-ports of a system have to be observed.

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

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

This entails, that the correctness of the level N + 1 designhinges on finding an implementation of S meeting this bottom-up vertical contract.

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

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

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

To allow to build on these in the methodology for contract-based design, we introduce what we call simulation compo-nents relating traces, i.e. sequences of observations of ports ofa level N + 1 component S to sequences of observations ofports of components S at level N . Referring to Figure 3, thiscomponent would thus have an interface towards layer N + 1observing ports p1S and p2S , and an interface towards layerN observing ports p1S , p2S , and p3S . Simulation componentscan use contracts to characterize the intended inter-relationbetween valuations of these. These contracts can take the formof both logic-based and automata-based formalisms, givingsufficient expressivity in capturing the intended relations be-tween traces of interface objects of S at level N +1 and level

12

N [4].Strong vs. weak assumptions and the issue of compatibil-

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

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

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

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

V. CONTROL DESIGN AND CONTRACTS WITH ANEXAMPLE

In this section we present a simple example of control of acyber-physical system design that makes use of the contract-based design methodology. The example, a Water Flow Con-trol system, was first proposed by the Israel Aerospace Indus-tries Ltd. (IAI) in the context of the SPEEDS project, and hasbeen analyzed using hybrid modeling techniques [5]. Here wepresent a version using a continuous model to highlight theuse of contracts in a familiar, equation-based notation. Wewill discuss how to model the system requirements, as well ashow these are partitioned in assume/guarantee pairs (contracts)for each component of the system. Different verification anddesign activities can be carried out using this model.

A. 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 container hasa 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 component rep-resenting the overall Water Flow Control system, with input,output and parameters corresponding to the above specifica-tion. To simplify our task, we decide to make state variables,such as the water level, visible as primary outputs. The WFCformal specification is therefore composed of the followingitems:• 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 contractthat the implementation must satisfy. The contract distin-guishes between the assumptions and the guarantees that mustbe enforced. Assuming t represents time, the above conditionscan be formally specified as follows:• Assumptions: P ≥ 5, 000.• Promises:

∀t.(t ≥ 10 =⇒ (1.0 ≤ Fout ≤ 2.0))∀t.(wl(t) ≤ H)E ≤ El

B. Design Solution

There are many ways to guarantee the required propertiesgiven the assumptions. Here we examine a solution methodbased on the regulation of the water level. From the Bernoulli

13

http://spes2020.informatik.tu-muenchen.de

Law, we know that the outlet flow rate depends on the waterlevel according to the formula

Fout = V · Sout =√

2g wl · Sout

where V is the velocity. The water level is therefore given by

wl =(

FoutSout

)2· 12g

.

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. As aresult, the system will be composed of an inlet valve, the watercontainer, a water level sensor and a controller that controlsthe opening and closing of the valve based on the measuredwater level, as shown in Figure 4. Our methodology is the

λ

cmd

outF

inF

wlm

valve container

sensorcontroller

F

wlλ

Figure 4. Block diagram of the Water Flow Control system

following:• We define for each component the contract that it must

satisfy• 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, thecontract theory ensures that a composition of components,each satisfying its contract, will also satisfy the system spec-ification.

1) Model for the valve: The inlet flow is controlled by avalve that may get position commands from the controller. Wedenote the valve aperture by λ, where 0 ≤ λ ≤ 1. The valveis controlled by a signal λcmd, coming from the controller,whose range is also 0 ≤ λcmd ≤ 1. The position λ of thevalve follows 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, which isalso the flow rate at the input of the container. We can expressFin as a function of the current valve position as follows:

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 contract thatmakes no assumption. In practice, one can use the assumptionto limit the range of validity of the model, for example byrequiring that the flow rate at the input be less than a certainvalue. This translates, after composition with the rest of thecomponents, in a requirement on the environment that thepressure P be less than a certain value. Obviously, if onesuch assumption is introduced, the overall contract will not besatisfied, as no constraint is imposed at the system level forthe pressure P other than it 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 certain re-quirement should be guaranteed by a component, or assumedfrom the environment. For instance, one could take the initialposition of the valve as an assumption. The ambiguity dis-appears when one considers which component is responsiblefor setting a certain value. Since the position of the valve isan output of the valve, it is the valve responsibility to ensureits initial value, and the requirement is therefore a guarantee.A valve that does not satisfy this condition will simply notsatisfy the contract.

2) Model for the container and the outlet: The containeris characterized by the following inputs and outputs:• 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 flow rate,as well as on the evaporation rate ε. We assume that theevaporation rate is bounded. In order to model this situation,we must add ε to the set of inputs. Then, the container mustsatisfy the following contract.

For the assumptions, we assume that the evaporation rate isbounded:

∀t.ε(t) ≤ 0.25

The container must ensure the following promises:• The water level is given by the integral of the difference

between 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

Fout = V · Sout =√

2g wl · Sout

14

3) Model for the water level sensor: The sensor is modeledsimply as a transducer that outputs a measured water levelwlm as an approximation of the real water level wl. Thus, thesensor has wl as an input and wlm as an output. The sensormakes no assumption, and makes the promise:

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

i.e., the sensor has a 5% error.4) Model for the controller: The controller takes as input

the measured water level wlm, and controls the position of thevalve through the signal λcmd, which is therefore an outputof the controller.

We initially experiment with a simple control function. Inorder to maintain the required output flow rate, and to avoidthe container overflow, the valve will be opened when thewater in the container goes below a certain level wlmin (sothat the container will be filled), and will be closed when thewater goes above a certain level wlmax (to avoid overflow).The promises of the controller are therefore as follows:

wlm ≤ wlmin =⇒ λcmd = 1wlm ≥ wlmax =⇒ λcmd = 0

Note that the specification of the controller makes no promisewhen wlm is between wlmin and wlmax. Thus the specifica-tion admits several different possible implementations for thecontroller.

5) Determination of consumed energy: We assume that theenergy consumption is due primarily to the valve motion. Wealso assume that the energy is proportional to the distancetraveled by the valve, which can 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 constant 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 theadditional promise that expresses the value of E as a functionof λ.

C. System composition

Having defined the contracts for the component of thesystem, our aim is to verify that their collective requirementsare consistent with the overall system contract. To do so, wemust derive an overall system by taking the composition of allthe contracts of the components described above. Compositionin the context of this model is simple, and corresponds toputting all the equations in a system so that they are all

satisfied simultaneously (i.e., we must take the intersectionof the sets of solutions of the individual equations). One,however, has to take care of separating the assumptions fromthe guarantees, and make sure that assumptions that are notalready discharged by other components of the system areproperly propagated to the composite.

To give an example, we compose the model of the valve Vwith the model of the container C. The composition is defined,since the set of outputs of the two components is disjoint,and therefore there is no conflict over which equation to useto define the value of a variable. The composition has thefollowing interface signals

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

which are obtained by taking as output any of the outputs ofthe two components, and as inputs the remaining signals. Thecomposite must satisfy the following assumption, which is anassumption of the container which is not discharged by thevalve:

∀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′′

Fout = V · Sout =√

2g wl · Sout

Note that some of the outputs may now be hidden in thecomposition. For instance, the output Fin does not need toappear explicitly, as long as it is considered in the promises.That is, we need to replace the guaranteed expression ofFin in the expression for wl, and then remove Fin from theset of outputs. Likewise, we could remove λ from the setof outputs. However, since λ is not defined explicitly as afunction (but rather as the solution to a differential equation)the substitution is problematic from a formal point of view.From a t