Contracts for the Design of Embedded Systems Part I: Methodology and Use Cases Albert Benveniste† , Werner Damm∗∗ , Alberto Sangiovanni-Vincentellik , Dejan Nickovic§ , Roberto Passerone‡ , and Philipp Reinkemeier∗∗ † INRIA/IRISA, k University
Rennes, France. corresponding author:
[email protected] of California at Berkeley and University of Trento ∗∗ Offis and University of Oldenburg
Abstract—This is Part I of a sequence of two papers on Contract-Based Design (CBD). It is intended to: • Introduce the concepts underlying CBD; • Present the challenges facing facing designers of large-scale complex systems today; • Review the design methodologies so far used to address these challenges and show how contracts can be used in all these approaches to enhance their applicability and the quality of the final result, and • Present three examples of the use of contracts: one simple example to underline the key steps of contract-based design, one about the use of contracts in enhancing and extending the AUTOSAR automotive standard and one related to analog-mixed signal integrated circuit design. Part II covers the theoretical foundations for contracts that are essential to make the methodology robust and well supported by tools and software frameworks. We believe contract-based design is going to be a key part of the future of system design and for this reason, this contribution is important for the design community.
II-C
II-D II-E II-F II-G
II-H
C ONTENTS I
II
Introduction and Challenges I-A Managing Complexity . . . . . . . . . . I-B Managing the Industrial Supply Chain . I-C Capturing and Managing Requirements I-D Product optimization . . . . . . . . . . I-E Risk Management . . . . . . . . . . . . I-F Moving Forward . . . . . . . . . . . . .
3 3 4 6 6 6 6
Addressing the Challenges II-A Contracts in embedded system design: once over lightly . . . . . . . . . . . . . II-B Coping with complexity of systems . . II-B1 Viewpoints . . . . . . . . . . II-B2 Layered design . . . . . . . . II-B3 Component-based design . . II-B4 The V-model of the design process . . . . . . . . . . . . II-B5 Model-Based Development .
7
II-B6 Virtual Integration . . . . . . Coping with the complexity of the supply chain . . . . . . . . . . . . . . . . . II-C1 Standardization of design entities . . . . . . . . . . . . II-C2 Standardization/harmonization of processes . . . . . . . . . Getting initial requirements right . . . . Coping with multi-layer design optimization . . . . . . . . . . . . . . . . . Managing risk across the development process . . . . . . . . . . . . . . . . . . Platform-Based Design and Contracts . II-G1 Platform-based design . . . . II-G2 Contract-based design: Contracts in PBD . . . . . . . . Moving forward: the importance of contracts . . . . . . . . . . . . . . . . . . .
III Contracts in Requirement Engineering: the Parking Garage Example III-A Top-level specification of the example . III-B Domain specific ontology . . . . . . . . III-C Defining and firming up requirements . III-D Executing requirements . . . . . . . . . III-E Identifying responsibilities . . . . . . . III-F Partitioning and allocating requirements to subsystems . . . . . . . . . . . . . . III-G Further Refining Requirements . . . . . III-H More on Fundamental Properties . . . . III-I Requirements and system architecture .
7 7 7 9 9
IV
10 11
This work was funded in part by the European STREP-COMBEST project number 215543, the European project CESAR of the ARTEMIS Joint Undertaking, the Artist Design Network of Excellence number 214373, the MARCO FCRP MuSyC and GSRC grants, the DARPA METAII Project, the VKR Center of Excellence MT-LAB, and the German Innovation Alliance on Embedded Systems SPES2020.
1
AUTOSAR and Contracts IV-A Today - Offering a Smooth Integration of Contract-Based System Engineering with AUTOSAR . . . . . . . . . . . . . IV-B The Future - Integrating Contracts in AUTOSAR . . . . . . . . . . . . . . . . IV-C An Approach for Integrating Contracts in AUTOSAR . . . . . . . . . . . . . . IV-D AUTOSAR Model of an Adaptive Cruise Control Enriched by Contracts .
11 12 12 13 13 13 14 14 14 15 17
18 18 18 19 19 19 19 20 21 21 22
22 23 23 23
IV-D1
. . . . . . on . . . IV-D4 on AssemblySwConnectors . Using Contracts for Safety Specification Summary and discussion . . . . . . . . IV-D2 IV-D3
IV-E IV-F V sign
CrsCtrlAndAcc . . . Sub-contracting . . . . Vertical Assumptions Software Components . Vertical Assumptions
23 24 24 25 26 27
Contracts and Analog Mixed-Signal Circuit De27 V-A V-B V-C
VI
SW-composition
Analog Circuit Design: Why Are Contracts Important? . . . . . . . . . . . . . Analog Platform-Based Design and Contracts . . . . . . . . . . . . . . . . . Contract-Based Design Flow . . . . . .
Concluding Remarks
References *
27 28 29 29 30
2
I. I NTRODUCTION AND C HALLENGES
weight and other physical aspects transmitted to the system assemblers during design time would go a long way in providing a better opportunity to design space exploration. In this landscape, a wrong turn in a system design project could cause so much economic, social and organizational upheaval that it may imperil the life of an entire company. No wonder that there is much interest in risk management approaches to assess risks associated to design errors, delays, recalls and liabilities. Finding appropriate countermeasures to lower risks and to develop contingency plans is then a mainstay of the way large projects are managed today. The overarching issue is the need of a substantive evolution of the design methodology in use today in system companies. The issue to address is the understanding of the principles of system design, the necessary change to design methodologies, and the dynamics of the supply chain. Developing this understanding is necessary to define a sound approach to the needs of the system companies as they try to serve their customers better, to develop their products faster and with higher quality. This paper describes the notion of “contracts”, which can be used in conjunction with the most popular design methodologies to yield a novel framework where the problems listed above can be addressed effectively. As argued above, we need to address how to deal with the design chain in a more effective way, how to manage complexity and integration, how to improve the creation and management of the requirements of the design, and how to make design space exploration more effective in product quality.
System companies such as automotive, avionics and consumer electronics companies are facing significant difficulties due to the exponentially raising complexity of their products coupled with increasingly tight demands on functionality, correctness, and time-to-market. The cost of being late to market or of imperfections in the products is staggering as witnessed by the recent recalls and delivery delays that system industries had to bear. In 2010, Toyota had to recall 10 Million cars worldwide for reasons that ranged from the infamous sticky accelerator pedals to steering and engine problems. The last recall at the end of August 2010 was for the engine control module. Toyota is not alone in this situation. Most of the automotive makers had one or more major recalls in the recent past (see e.g., http://www.autorecalls.us) involving electronics as well as mechanical parts. Boeing and Airbus Industrie had significant delays in the delivery of their latest planes (787 and A380). For the A380, underlying causes were cited as issues in the cabling system, configuration management and design process. In particular, the complexity of the cabin wiring (100,000 wires and 40,300 connectors) was considered a major issue (see http://en.wikipedia.org/wiki/Airbus_A380). The delays caused the departure of both the EADS and Airbus CEOs and of the program manager for the A380 and caused an overall earning short fall of 4.8 Billion Euros. Boeing originally planned the first flight of the 787 for August 2007 (see http://en.wikipedia.org/wiki/Boeing_787), but after a stream of delay announcements, the actual first flight occurred on December 15, 2009. The delays were caused by a number of unfortunate events and design errors and caused at least a 2.3 Billion USD write-off not counting the claim of Air India of 1 Billion USD damages for delayed delivery and the revenue short falls. These are examples of the devastating effects that design problems may cause. Problems also come from the disconnect between the sales and marketing department and engineering when contracts are signed that are based on limited evidence of their feasibility. The specific root causes of these problems are complex and relate to a number of issues ranging from design processes and relationships with different departments of the same company and with suppliers1 to incomplete requirement specification and testing.2 Further, there is a widespread consensus in the industry that there is much to gain by optimizing the implementation phase that today is only considering a very small subset of the design space. Some attempts at a more efficient design space exploration have been afoot but there is a need to formalize the problem better and to involve in major ways the different players of the supply chain. Information about the capabilities of the subsystems in terms of timing, power consumed, size,
A. Managing Complexity The ability to integrate an exponentially rising number of transistors within a chip, the ever-expanding use of electronic embedded systems to control increasingly many aspects of the real world, and the trend to interconnect more and more such systems (often from different manufacturers) into a global network are creating a challenging scenario for system designers. In this scenario, the three challenges that are taking center stage are as follows. The Hardware Platform Complexity: The present integration capabilities make it possible to build a real complex system on a chip including analog and RF components, general purpose processors (GPP) and Application-Specific Instruction-set Processors (ASIP). The decision of what goes on a chip is no longer dictated by the amount of circuitry that can be placed there, but by reliability, yield, power consumption, performance, and ultimately cost (it is well known that analog and RF components force the use of more conservative manufacturing lines with more processing steps than pure digital ICs). The cost of designing semiconductors has risen to a level that makes it impractical for system companies to develop application specific solutions. Hence, most system companies rely on COTS and programmability to implement their applications. For companies who build “physically large” systems such as avionics and automotive companies, the complexity of the
1 Toyota sticky accelerator problem came in part from components provided by two contractors whose interaction was not verified appropriately, Airbus delay problems were in part due to contractors who had different versions of the CAD software 2 Boeing stated that a structural problem was discovered late in the design process
3
hardware platform is reflected in the number of Electronic Control Units and in their interconnections. For a top-of-theline automobile, the number of processors to manage and interconnect is above 50. The layout of the cables that connect these processing elements with sensors and actuators is a serious concern. Initial production of the Airbus A380 was troubled by delays in part attributed to the 530 km (330 mi) of wiring in each aircraft.
The Integration Complexity: A standard technique to deal with complexity is decomposing top-down the system into subsystems. This approach, which has been customarily adopted by the semiconductor industry for years, has a limitation as a designer or a group of designers has to fully comprehend the entire system and to partition appropriately its various parts, a difficult task given the enormous complexity of today’s systems. Hence, the future is one of developing systems by composing pieces that all or in part have already been predesigned or designed independently by other design groups or even companies. This has been done routinely in vertical design chains for example in the avionics and automotive verticals, albeit in a heuristic and ad hoc way. The resulting lack of an overall understanding of the interplay of the subsystems and of the difficulties encountered in integrating very complex parts cause system integration to become a nightmare in the system industry, as demonstrated by Table I.3 The source of these problems is clearly the increase in complexity, but also the difficulty of the OEMs in managing the integration and maintenance process with subsystems that come from different suppliers who use different design methods, different software architecture, different hardware platforms, and different (and often proprietary) real-time operating systems. Therefore, there is a need for standards, methods and tools in the software and hardware domains that will allow plugand-play of subsystems and their implementation. The ability to integrate subsystems will then become a commodity item, available to all OEMs. The competitive advantage of an OEM will increasingly reside on novel and compelling functionalities. There is also the need for improving the interaction among all the players in the supply chain to improve the integration challenges in a substantial way.
The Embedded Software Complexity: Given the cost and risks associated to developing hardware solutions, system companies are selecting hardware platforms that can be customized by reconfiguration and/or by software programmability. In particular, software is taking the lion’s share of the implementation budgets and cost. In cell phones, more than 1 million lines of code is standard today, while in automobiles the estimated number of lines by 2010 is in the order of hundreds of millions and in the Boeing 787 is in the order of 20 million lines. However, as this happens, the complexity explosion of the software component causes serious concerns for the final quality of the products and the productivity of the engineering teams. In transportation, the productivity of embedded software programmers using the traditional methods of software development ranges in the few tens of lines per day. The reasons for such a low productivity are in the time needed for verification of the system and long redesign cycles that come from the need for developing full system prototypes for the lack of appropriate virtual engineering methods and tools for embedded software. Embedded software is substantially different from traditional software for commercial and corporate applications. By virtue of being embedded in a surrounding system, the software must be able to continuously react to stimuli in the desired way, i.e., within bounds on timing, power consumed, and cost. Verifying the correctness of the system requires that the model of the software be transformed to include information that involves physical quantities to retain only what is relevant to the task at hand. In contrast, in traditional software systems, the abstraction process leaves out all the physical aspects of the systems as only the functional aspects of the code matter.
B. Managing the Industrial Supply Chain The design and supply chains are the backbone for any industrial sector. Their health and efficiency are essential for economic viability. While tools for supply chain management have been around for quite some time, support for the design chain has not been pursued nearly as vigorously. There are great opportunities for improving the situation substantially at least in the safety-driven industrial sector, which includes the transportation as well as industrial automation domain, with a combination of tools and methodologies. We are just at the beginning. Integration of electronic and mechanical design tools and frameworks will be essential in the near future. Integration of chemical, electronic, and biology tools will also be essential in the further future for nanosystems. Data integration and information flow among the companies forming the chain have to be supported. In other words, it is essential that the fundamental steps of system design (functional partitioning, allocation on computational resources, integration, and verification) be supported across the entire design development cycle.
Given the impact that embedded software has on the safety of embedded system devices and on the quality of the final artifact, there is an increasingly strong interest in having high assurance that embedded software is correct. There is a risk that certification will enter into new safety-critical domains and will create an additional, serious burden on the embedded software design process for an increasingly large number of companies worldwide. We believe it will be of extreme importance to link the certification process with the content of the software and not only with the development process, as already enforced today in advocating requirement based testing. We expect evolutions of these standards to further push this view by enforcing the use of formal verification methods for highest safety integrity levels, such as in the forthcoming safety standard for airborne software development DO 178-C.
3 VDC research, Track 3: Embedded Systems Market Statistics Exhibit II-13 from volumes on automotive/industrial automation/medical, 2008
4
Design task
System integration test, and verification System architecture design and specification Software application and/or middleware development and test Project management and planning
Tasks delayed automotive 63.0%
Tasks delayed automation 56.5%
Tasks delayed medical 66.7%
Tasks causing delay automotive 42.3%
Tasks causing delay automation 19.0%
Tasks causing delay medical 37.5%
29.6%
26.1%
33.3%
38.5%
42.9%
31.3%
44.4%
30.4%
75.0%
26.9%
31.0%
25.0%
37.0%
28.3%
16.7%
53.8%
38.1%
37.5%
Table I D IFFICULTIES RELATED TO SYSTEM INTEGRATION
Thus, whether the integrations pertains to SW-SW integration on a distributed network, HW-SW integration on a single electronic control unit (ECU), or electronics and mechanical integration for a subsystem, tools and models have to be integrated seamlessly from a static point of view (e.g., data dictionaries and off-line model transformations) and dynamic point of view (e.g., co-simulation, HW-in-theloop simulations and emulation). The dynamics in the system industry is similar across the vertical domains but certainly there are important differences. For example, for embedded controllers in industrial engineering applications, automotive, avionics, energy production, and health related equipment, safety considerations, and hence hard real-time constraints, are of paramount importance. In the case of consumer electronics, including entertainment subsystems in cars and airplanes, cell phones, cameras, and games, the concerns are on sound, video, and recording quality and on the look and feel of the devices in presence of severe cost constraints. The need for integrating widely different subsystems such as safety, propulsion, communication, and entertainment makes the Automotive Design Chain very interesting for our purposes and as such, it is an interesting example to expose the challenges in supporting a complex design chain. The Automotive supply chain includes:
suppliers is increasingly considered for outsourcing. Car makers express the desire of gaining a stronger grip on the integration process and on the critical parts of the electronics subsystems. At the same time, there is evidence that sharing IPs among car makers and Tier 1 suppliers could improve substantially time-to-market, development, and maintenance costs. The essential technical problem to solve for this vision is the establishment of standards for interoperability among IPs and tools. AUTOSAR http://www.autosar.org/, a world-wide consortium of almost all players in the automotive domain electronics supply chain, has this goal very clear in mind. However, there are technical and business challenges to overcome. In particular, from the technical point of view, while sharing algorithms and functional designs seems feasible at this time, the sharing of hard real-time software is difficult even assuming substantial improvements in design methods and technology, if run-time efficiency has to be retained. The issues are related to the interplay that different tasks can have at the RTOS level. The timing of the software tasks depend on the presence or absence of other tasks. A scheduling policy that could prevent timing variability in the presence of dynamical changing task characteristics can be conceived (for example, timing isolation or resource reservation policies) but it will carry overhead, albeit potentially not prohibitive; further, this kind of policy is not supported by any of the commercially available RTOS. This situation is the standard tradeoff between efficiency and reliability but it has more important business implications than usual. In fact, if software from different sources has to be integrated on a common hardware platform, in the absence of composition rules and formal verification of the properties of composed systems, who will be responsible for the correct functioning of the final product? Whoever will take on this responsibility would need a very strong methodology and an iron fist to make suppliers and partners comply with it. This may not be enough, in the sense that software characteristics are hard to pin down and with the best intentions of this world, one may not be able to guarantee functional and timing behavior in the presence of foreign components. An additional benefit from a real plug-and-play environment will be the acceleration of the rate of innovation. For example, if
1) Car manufacturers (OEMs) such as Audi, BMW, GM, Ford, Daimler, Renault, PSA, Toyota, and VW, who provide the final product to the consumer market. 2) Tier 1 suppliers such as Bosch, Continental, Delphi, Magneti-Marelli, and Nippon-Denso, who provide subsystems such as powertrain management, suspension control, and brake-by-wire devices to OEMs. 3) Tier 2 suppliers, e.g., chip manufacturers such as Freescale, Infineon, ST, and Renesas, IP provider e.g., ARM and RTOS suppliers such as WindRiver and ETAS, who serve OEMs and more likely Tier 1 suppliers. 4) Manufacturing suppliers such as Flextronics and TSMC who provide manufacturing services. Opposite to verticals that are not safety critical, liability issues make the recourse to outside manufacturing not as common. However, there are signs that manufacturing for Tier 1 5
a well-oiled mechanism existed to migrate from one hardware platform to another, the optimal solutions would be selected instead of the ones that have been traditionally used. In this case, the Tier 2 market place will also be rationalized and the rate of innovation will likely be increased. As a final consequence, the introduction of new functionalities will be a matter of algorithm and architecture rather than detailed software and hardware selection. The trend in electronics for the automotive industry (but for other verticals as well) is clear: less customization, more standardization. For a subsystem supplier, the choice will be richer in terms of platforms but it will not require heavy investment in IC design or RTOS development. For car manufacturers, the granularity of the choices will be also richer because of interoperability. They will have the choice of selecting entire macro systems or components that could be integrated in a large automotive platform. The choice will be guided by cost, quality, and product innovation. The final goal of the strategy is rather clear. The way of getting there is not as clear and the road has many bumps and turns that are difficult to negotiate. A positive outcome will have to come from a process of deep business and technical cooperation among all players in the design chain as well as the research community. It is a unique opportunity and a great challenge.
improving the customer-provider relationships, it would allow better integration and consequently better product quality and time to market.
C. Capturing and Managing Requirements
The complexity of the entire design process and of the relationships between players in the supply chain creates the need to elaborate risk management plans because of the potential enormity of the impact that design errors and supplier solidity may have on the economics of a company. Risk management has become a requirement of most of public companies in the Western world where financial, social and political risks are analyzed and appropriate countermeasures have to be prepared as a requirement from the regulatory bodies. In our discussion, risks to be considered are related to the engineering process and countermeasures require the modification of the processes themselves. These processes are highly concurrent, distributed, and typically multi-domain engineering processes, often involving more than one hundred sub-processes. Risk mitigation measures typically cover all phases of design processes, ranging from assuring high quality initial requirements to early assessments of risks in meeting product requirements during the concept phase, to enforcing complete traceability of such requirements with requirements management tools, to managing consistency and synchronization across concurrent sub-processes using PLM tools. If we will be able to change the design process along the lines of more formal approaches, better complexity handling, better requirement engineering, then risks will be substantially lower than they are today. Indeed, the nature of the risks and potential countermeasures could be factored in the requirement development phase as well as in detailed product implementation.
D. Product optimization We believe that since the design process is fragmented, product optimization is rarely carried out across more than one company boundary and even then, it is limited due to • The lack of appropriate internal and external models that include both functional and non-functional aspects which are crucial to evaluate the quality of the design; • Time pressure to meet the product deadlines; • The functional description that is over-constrained by architectural considerations which de facto eliminate potentially interesting implementation alternatives. If the design process were carried out as in a unique virtual company including all the players shown above, the overall ecosystem would greatly benefit. The issue here is to allow a reasonably efficient design space exploration by providing a framework where different architectures could be quickly assembled and evaluated at each layer of abstraction corresponding to the design task being considered in the chain. E. Risk Management
We argued that the design chains should connect seamlessly to minimize design errors and time-to-market delays. Yet, the boundaries among companies are often not as clean as needed and design specs move from one company to the next in non-executable and often imprecise forms, thus yielding misinterpretations and consequent design errors. In addition, errors are often caught only at the final integration step as the specifications were not complete and imprecise; further, nonfunctional specifications (e.g., timing, power consumption, size) are difficult to trace. Requirement engineering is a discipline that aims at improving this situation by paying close attention to the management of the requirement descriptions (commercial tools such as DOORS are available to carry out this task) and by inserting whenever possible precise formulation and analysis methods and tools. Research in this area is active but we believe more needs to be done to make this essential step a first class citizen in system design. Indeed, if the specification quality is low, then the entire design process is marred since the very beginning! The overall system product specification is somewhat of an art today since to verify its completeness and its correctness there is little that it can be used to compare with. However, we believe that principles can be stated so that the initial specification process could be guided in a fairly precise way and properties related to its “quality” could be assessed using appropriate tools. On the other hand, when the specifications are for a subsystem and are derived from previous design steps, then the formalization of the specifications is definitely feasible with the appropriate efforts and it would go a long way in
F. Moving Forward System companies had not perceived as yet design methodology or tools to be on their critical path; hence they had 6
not been willing to invest in expensive tools. Clearly, as they are hitting a wall in the development of the next generation systems, this situation is rapidly changing. Major productivity gains are needed and better verification and validation is a necessity as the safety and reliability requirements become more 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 between them being in the importance given to time-to-market and to the customer appeal of the products versus safety and hardtime constraints. This consideration motivates the view that a unified methodology and framework could be used in many (if not all) industrial vertical domains. Our view, shared by the research community, is that a new design science must then be developed to address the challenges listed above where the physical is married to the abstract, where the world of analog signals is coupled with the one of digital processing, and where ubiquitous sensing and actuation make our entire environment safer and more responsive to our needs. System design should be based on the new design science to address the industry and society needs in a fundamental way. However, the present directions are not completely clear as the new paradigm has not yet fully emerged in the design community with the strength necessary to change the design technology landscape, albeit researchers have chartered the field with increasing clarity. We do believe that system design needs to be concerned about the entire industrial supply chain that spans from customer-facing companies to subsystem and component suppliers, since the health of an industrial sector depends on the smooth interaction among the players of the chain as if they were part of the same company. In this paper, it is our goal to offer a new approach to the system design problem that is rigorous and effective in dealing with the problems and challenges described before and at the same time, it does not require a radical change in the way industrial designers carry out their task as it cuts across design flows of different type: contract-based design. The way the approach can be shared in a variety of common design methodologies is explained in the following section.
A. Contracts in embedded system design: once over lightly Contracts in the layman use of the term are established when an OEM must agree with its suppliers on the subsystem or component to be delivered. Contracts involve a legal part binding the different parties and a technical annex that serves as a reference regarding the entity to be delivered by the supplier. Contracts can also be used through their technical annex in concurrent engineering, when different teams develop different subsystems or different aspects of a system within a same company. In our view of the term, contracts can be actually used everywhere and at all stages of system design, from early requirements capture, to embedded computing infrastructure and detailed design involving circuits and other hardware. In particular, contracts explicitly handle pairs of properties, respectively representing the assumptions on the environment and the promises of the system under these assumptions. More formally, a contract is a pair C = (A, G) of {Assumptions, Promises}, where both A and G are properties satisfied by the set of all inputs and all outputs of a design. Assume/Guarantee reasoning has been known for a long time, but it has been used as verification mean for the design of software. Our purpose is much more ambitious: contract based design with explicit assumptions is a design philosophy that should be followed all along the design, with all kinds of models, whenever necessary. Here, the models we mean are rich — not only profiles, types, or taxonomy of data, but also models describing the functions, performances of various kinds (time and energy), and safety. In the following sections, we will review methods to cope with the challenges posed in the introduction underlying the roles of contracts in every approach. It is indeed our take that the concept of contract is a unifying view on how to formalize requirements and rules that appear at all steps of the design process. B. Coping with complexity of systems Multiple lines of attack have been developed by research institutions and industry to cope with the exponential growth in systems complexity. These are: Viewpoints, Model-based development, Virtual integration, Layered design, Componentbased design, and Platform-based design. We review them next. 1) Viewpoints: The key need to view one and the same architecture from the perspective of multiple stake-holders is reflected in the IEEE 1471 recommended practices of organizing architecture descriptions along views which cover one or more concerns of the stake-holders. A stake-holder could be an individual, a team, or organization (or collections thereof) with interests in, or concerns relative to, the system under development. Concerns are seen to be those stake-holder interests which pertain to the development, operation, or other key characteristics of the system (e.g., performance, reliability, security, evolvability, and distribution). Each view, then, gives a complete representation of the system with respect to the set of concerns covered by the view, hence allowing one
II. A DDRESSING THE C HALLENGES In this section we revisit the key design challenges facing systems companies as presented in the introduction, we present solutions in place to cope with the challenges and how the concept of contract can significantly strengthen these solutions. The goals of this section are: • •
•
identifying weaknesses of current industrial practices, and pointing out how conservative extensions of current processes exploiting contracts could tackle these weaknesses, and demonstrating that contracts are usable in every design methodology proposed so far for system design strengthening it. 7
to demonstrate that the given architecture fully meets stakeholder requirements of the supported class of concerns. We shall use the term viewpoint to refer to views in the sequel. Based on an assessment by the system companies processes in the CESAR project4 and the German Embedded Systems Innovation alliance5 , and building on the finding of the Integrated Project SPEEDS6 , viewpoints can be categorized into perspectives and aspects. Perspectives are viewpoints relevant to architecture modeling, as carried out by different stake-holders during the development process. While the number of perspectives employed might differ from company to company, the following ones have been found relevant in the transportation sector: • The operational perspective models the operational context of the system, i.e., the different activities performed by actors with the system. • The functional perspective models the functional needs of the system and its breakdown into sub-functions, that hence together realize the top-level system functionality. • The logical perspective constitutes the grouping of the functions identified in the functional perspective into reusable components. Thus, the logical perspective provides the application architecture as a network of reusable function components. Resources or properties of the target platform are not considered at this point. • The technical perspective specifies the architecture in terms of resources, where the (logical) components shall be allocated to. In contrast to the logical perspective, in the technical perspective resource limitations come into play. Some resources, such as ECUs, will be shared by multiple logical components. The actual behavior of these components will thus also depend on the properties of these resources. 7 • The geometrical perspective models the physical layout of the system. While in the technical perspective some resource is modeled in terms of its properties, its interfaces and its behavior, in the geometrical perspective its spatial dimensions and physical are modeled. The geometrical perspective deals for example with cable lengths, space limitations, mechanical behavior, thermodynamical behavior, and so on. All these viewpoints share an emphasis on structure, yet from the perspectives of different stakeholders/roles in the design process, typically from different disciplines, such as • structural engineers being responsible for the structural design of an aircraft (within the geometric perspective); • the partitioning of mechatronic systems into hydraulic, mechanical, and EE subsystems, and the refinement of their structure and interfaces within the technical perspective, requiring interdisciplinary teams from mechanical and electrical engineering;
• • •
requirement engineering supporting stakeholder analysis within the operational perspective; function design supporting the identified requirements within the functional perspective by systems engineers component design supporting product line development and distributed development across the supply chain by grouping functions into re-usable components by systems engineers.
To account for this, the meta-model underlying the CESAR RTP is able to maintain links such as the satisfy, derive, verify, refine and allocate relationships between design artifacts of different perspectives and across abstraction layers. Aspects are viewpoints that are orthogonal to the system structure. Aspects are used to demonstrate compliance of the architecture to end-user concerns. Example of aspects are safety, cost, maintainability, performance, and weight. •
•
•
The safety aspect is commonly considered today in the transportation sector. Safety is concerned with the risk of primary faults and failures, how they could propagate throughout the system, and what the consequences for the resilience of the overall system would be. For some companies, safety often also comprises the functions in charge of on-line monitoring and off-line inspections for maintenance. For other companies, these are duties collected within the maintainability aspect. Depending on the sector, the performance aspect comprises system performance in terms of overall service, plus environmental footprint and energy costs. It is considered in tradeoff with the cost aspect.
The determination of these extra-functional system characteristics is complex, and can ultimately be done precisely once all perspectives of a system are fully evolved. As an example, the safety aspect is dependent on an assessment of the criticality of aircraft functions based on a functional hazard analysis (using the functional perspective of the aircraft), its refinement during preliminary system-level hazard analysis and systemlevel hazard analysis is based on the logical and technical perspective and their interdependency, i.e. the mapping of functions to components, and components to resources. Only by assessing the concrete placement and routing of computation and communication resources is it possible to identify common-cause failures resulting from physical intrusion into the body of the aircraft. In spite of this interdependency, industrial practice shows the efficiency of separating concerns of the analysis of aspects, such as safety above, to one or neighboring perspectives. Indeed, the use of contract-based aspect specifications allows explicating assumptions which are otherwise often only established in later phases of the design. It is under these assumptions that a demonstration of the compliance of an architecture to meet aspect-specific requirements is based. As an example, results of a systemlevel fault tree analysis may be made subject to assuming independence of root-causes. These assumptions must then be explicitly validated by taking into account allocation of computing and communication resources in the geometric
4 www.cesarproject.eu 5 http://spes2020.informatik.tu-muenchen.de 6 http://www.speeds.eu.com 7 From its definition, the reader should notice that a more appropriate naming would rather be physical perspective.
8
perspective. However, carrying out contract-based aspect analysis early in the design process comes with the risk of deep iterations in the design process, where e.g. the fact that safety objectives cannot be realized becomes only evident by taking into account the actual placement of functions on Integrated Modular Avionics (IMA) [7] modules, and their allocation to a particular bay of the aircraft. To mitigate this risk while retaining the capability of carrying out aspect analysis early in the design flow (an essential part of the design methodology we support), estimation of the aspects in the final implementation can be used so that albeit not with 100% confidence, we can explore effectively the design options minimizing the chances of discovering late that our early design choices lead to an unfeasible solution. Indeed, the bottom-up characterization of components in the library of reusable parts advocated by Platform Based Design is an example of how aspect analysis can be done early in the design process with appropriate accuracy guarantees.
hardware, while at the same time imposing a minimal (or even no) constraint on the design space of possible hardware architectures. In particular, these abstractions allow re-using the application design across multiple platforms, varying in number of bus-systems and/or number and class of ECUs. These design layers can, in addition, be used to match the boundaries of either organizational units within a company, or to define interfaces between different organizations in the supply chain. The challenge, then, rests in providing the proper abstractions of lower-level design entities. which must meet the double criteria of, on one hand, being sufficiently detailed to support virtual integration testing even with respect to non-functional viewpoints on the next higher level, while at the same time not overly restricting the space of possible lower-level implementations. As a concrete example, consider the AUTOSAR application layer and an application requiring guaranteed service under a given failure hypothesis. Such failure hypothesis would typically relate both to failures observable on the application layer itself (such as a component sending an incorrect value, a component flushing its neighbors with unwanted messages), as well as to failures depending on the underlying (unknown!) target hardware. This points to an inherent dilemma: on one side, the desire of completely abstracting from the underlying hardware, while at the same time wishing to perform analysis of properties which inherently depend on it. Using what we call vertical assumptions as abstractions of the underlying target hardware can solve this dilemma. Returning to the above example, such vertical assumptions could explicate the failure hypothesis of either execution platforms or communication platforms, and thus decorate either (individual Runnables9 ) components or entities of the virtual function bus. More general, any logical communication must be seen as a (fictitious) component itself, which, at deployment time, will be mapped to communication services of the operating system.
2) Layered design: Layered design copes with complexity by focusing on those aspects of the system pertinent to support the design activities at the corresponding level of abstraction. This approach is particularly powerful if the details of a lower layer of abstraction are encapsulated when the design is carried out at the higher layer. Layered approaches are well understood and standard in many application domains. As an example, consider the AUTomotive Open System ARchitecture (AUTOSAR), an open and standardized automotive software architecture, jointly developed by automobile manufacturers, suppliers and tool developers,8 which we will use throughout the paper as an industrial reference to discuss contracts and their use. This standard defines several abstraction layers. Moving from “bottom” to “top”, the micro-controller abstraction layer encapsulates completely the specifics of underlying micro-controllers, the second layer abstracts from the concrete configuration of the Electronic Control Unit (ECU), the employed communication services and the underlying operating system, whereas the (highest) application layer is not aware of any aspect of possible target architectures, and relies on purely virtual communication concepts in specifying communication between application components. Similar abstraction levels are defined by the ARINC standard in the avionic domains. The benefits of using layered design are manifold. Using the AUTOSAR layer structure as example, the complete separation of the logical architecture of an application (as represented by a set of components interconnected using the so-called virtual function bus) and target hardware is a key aspect of AUTOSAR, in that it supports complete decoupling of the number of automotive functions from the number of hardware components. In particular, it is flexible enough to mix components from different applications on one and the same ECU. This illustrates the double role of abstraction layers, in allowing designers to focus completely in this case on the logic of the application and abstracting from the underlying 8 See
3) Component-based design: Whereas layered designs decompose complexity of systems “vertically”, component-based approaches reduce complexity “horizontally” whereby designs are obtained by assembling strongly encapsulated design entities called “components” equipped with concise and rigorous interface specifications. Re-use can be maximized by finding the weakest assumptions on the environment sufficient to establish the guarantees on a given component implementation. While these interface specifications are key and relevant for any system, the “quality attribute” of perceiving a subsystem as a component is typically related to two orthogonal criteria, that of “small interfaces”, and that of minimally constraining the deployment context, so as to maximize the potential for reuse. “Small interfaces”, i.e., interfaces which are both small in terms of number of interface variables or ports, as well 9 Runnables are defined in the virtual bus function specifications of AUTOSAR. Runnable entities are the smallest code-fragments that are provided by the component and are (at least indirectly) a subject for scheduling by the operating system.
http://www.autosar.org/
9
as “logically small”, in that protocols governing the invocation of component services have compact specifications not requiring deep levels of synchronization, constitute evidence of the success of encapsulation. The second quality attribute is naturally expressible in terms of contract-based interface specifications, where re-use can be maximized by finding the weakest assumptions on the environment sufficient to establish the guarantees on a given component implementation. One challenge, then, for component-based design of embedded systems, is to provide interface specifications that are rich enough to cover all phases of the design cycle. This calls for including non-functional characteristics as part of the component interface specifications, which is best achieved by using multiple viewpoints. Current component interface models, in contrast, are typically restricted to purely functional characterization of components, and thus cannot capitalize on the benefits of contract-based 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 a product. The aim is to balance the contradicting goals of striving for generality versus achieving efficient component implementations. Methods for systematically deriving “quotient” specifications to compensate for “minor” differences between required and offered component guarantees by composing a component with a wrapper component compensating for such differences as characterized by quotient specifications exists for restricted classes of contracts and restricted classes of component models [29].
with perspectives, as discussed in Subsection II-B1. Specifically, following product level requirement analysis, subsequent steps would first evolve a functional architecture supporting product level requirements. Sub-functions are then re-grouped taking into account re-use and product line requirements into a logical architecture, whose modules can be developed independently, e.g., by different subsystem suppliers. The realization of such modules often involves mechatronic design. The toplevel of the technology-oriented architecture would then show the mechatronic architecture of the module, defining interfaces between the different domains of mechanical, hydraulic, electrical, and electronic system design, such as exemplified below for the mechatronic architecture of a simplified aircraft braking system. Subsequent phases would then unfold the detailed design for each of these domains, such as the design of the electronic subsystem involving among others the design of electronic control units. These design phases are paralleled by integration phases along the right-hand part of the V, such as integrating basic- and application software on the ECU hardware to actually construct the electronic control unit, integrating the complete electronic subsystems, integrating the mechatronic subsystem to build the module, and integrating multiple modules to build the complete product. Not shown, but forming an integral part of V-based development processes are testing activities, where at each integration level testsuites developed during the design phases are used to verify compliance of the integrated entity to their specification. This presentation is overly simplistic in many ways. The design of electronic components in complex systems such as aircrafts inherently involves multi-site, multi-domain and cross-organizational design teams, reflecting, e.g., a partitioning of the aircraft into different subsystems (such as primary and secondary flight systems, cabin, fuel, and wing), different domains such as the interface of the electronic subsystem to hydraulic and/or mechanical subsystems, controllaw design, telecommunications, software design, hardware design, diagnostics, and development-depth separated design activities carried out at the OEM and supplier companies. This partitioning of the design space (along perspectives and abstraction layers) naturally lends itself to a parallelization of design activities, a must in order to achieve timely delivery of the overall product, leading often into the order of hundreds of concurrent design processes. We elaborate on the role of contract-based design to mitigate the risks from concurrent engineering in the section on risk-based design below. Secondly, each of these sub-processes will have its own design basis, as determined by the role of an organization in the supplier chain. As previously pointed out in the section of layered design, abstraction levels define, then, what is seen as basic 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 development processes, where tier 1 suppliers were providing a complete ECU implementing a single new vehicle function), or the microprocessor layer. This approach is further elaborated in the section on platform-based design below.
4) The V-model of the design process: A widely accepted approach to deal with complexity of systems in the defense and transportation domain is to structure product development processes along variations of the V diagram shown in Figure 1, originally developed for defense applications by the German DoD.10
s
Ce
s s es roce P roc t P ent en m sm sess es ss y As tA it os abil .C in e.g ainta .M
e.g
Product Integration
Development of Functional Architecture
rtif ica
tio
n
Analysis of Product Level Reqiuirements
Development of Logical Architecture Development of Technology oriented Architecture Development of ECU Architecture
System Integration
al
m es
ss
yA
git
Di
fet Sa
l ica l an a ch tric Me Elec ware re d wa r s Ha Soft es roc tP en
Subsystem Integration
Figure 1.
The V Model.
Its characteristic V-shape splits the product development process into a design and an integration phase. Annotations of sub-phases of the design-phase were chosen to be consistent 10 See
e.g. http://www.v-model-xt.de
10
Third, and tightly linked to the previous item, is the observation, that re-use strategies such as component-based design and product line design lead to separate design activities, which then short-cut or significantly reduce the effort both in design and integration steps in the individual sub-processes for an individual product. Finally, Figure 2 indicates the need of supporting processes for key viewpoints, such as for safety, where domain standards prescribe activities to be carried out during product development, which are often anchored with separate roles in the organization, e.g. Airbus Recommended Practices 4754 prescribes the activities in a safety assessment process as well as its interface to the aircraft development process, ultimately yielding a safety case to be approved by certification authorities.
AS 1
Command 1
CDM / AS 1
Green Pump Shut Off Selector Valve Normal
Command 2 CDM / AS 2
AS 2
Anti Skid (AS) Command (CMD) / Anti Skid
Braking System Control Unit (BSCU)
Blue Pump
Selector Valve
Anti Skid Shut Off Valve Meter Valve Meter Valve
Isolation Valve Alternate
Pedal Position 2
Power 2
HYDRAULIC
Monitor 2
2 Invalid
COMPUTER / DIGITAL
Monitor 1
1 Invalid
Power 1
Pedal Position 1
ELECTRICAL
In MBD today non-functional aspects such as performance, timing, power or safety analysis are typically addressed in dedicated specialized tools using tool-specific models, with the entailed risk of incoherency between the corresponding models, which generally interact. To counteract these risks, metamodels encompassing multiple views of design entities, enabling co-modeling and co-analysis of typically heterogeneous viewpoint specific models have been developed. Examples include the MARTE UML [25] profile for real-time system analysis and the Metropolis semantic meta-model [2], [10], [31]. In Metropolis multiple views are accommodated via the concept of “quantities” that annotate the functional view of a design and can be composed along with subsystems. Quantities are equipped with an “algebra” that allows quantities associated to compositions of subsystems to be computed from the quantities of each of the subsystems. Multiple quantities such as timing and power can be handled simultaneously. Along the same lines, the need to enable integration of point-tools for multiple viewpoints with industry standard development tools has been the driving force in providing the SPEEDS meta-model building on and extending SysML, which has been demonstrated to support co-simulation and co-analysis of system models for transportation applications allowing coassessment of functional, real-time and safety requirements, and forms an integral part of the meta-model-based interoperability concepts of the CESAR (see www.cesarproject. eu) reference technology platform. The SPEEDS meta-model building on and extending SysML has been demonstrated to support co-simulation and co-analysis of system models for transportation applications allowing co-assessment of functional, real-time and safety requirements. It forms an integral part of the meta-model-based inter-operability concepts of the CESAR reference technology platform.
Reserve
Accumulator
Mechanical Pedal Position
Wheel MECHANICAL
Figure 2.
6) Virtual Integration: Rather than “physically” integrating a system from subsystems at a particular level of the righthand side of the V, model-based design allows systems to be virtually integrated based on the models of their subsystem and the architecture specification of the system. Such virtual integration thus allows detecting potential integration problems up front, in the early phases of the V. Virtual system integration is often a source of heterogeneous system models, such as when realizing an aircraft function through the combination of mechanical, hydraulic, and electronic systems — virtual system integration then rests on well defined principles allowing the integration of such heterogeneous models. Heterogeneous composition of models with different semantics was originally addressed in Ptolemy [14] and Metropolis [2], [10] albeit with different approaches. These approaches have then been further elaborated in the SPEEDS meta-model of heterogeneous rich components [9]. Virtual integration involves models of the functions, the computer architecture with its extra-functional characteristics (timing and other resources), and the physical system for control. Some existing frameworks offer significant support for virtual integration: Ptolemy II, Metropolis, and
The technical architecture of an airplane braking system.
Subsequent sections will focus on particular aspects in the general setting of V-based development processes and elaborate on the role of contract-based design in these. 5) Model-Based Development: Model-based development (MBD) is today generally accepted as a key enabler to cope with complex system design due to its capabilities to support early requirement validation and virtual system integration. MBD-inspired design languages and tools such as SysML [26] or AADL [28] for system level modeling, Catia and Modelica [15] for physical system modeling, Matlab-Simulink [22] for control-law design, and UML [5], Scade [4] 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 Matlab-Simulink, model-based analysis including verification of compliance of requirements and specification models, model-based test-generation, rapid prototyping, and virtual integration testing as further elaborated below. 11
RT-Builder. Developments around Catia and Modelica as well as the new offer SimScape by Simulink provide support for virtual integration of the physical part at an advanced level. While virtual integration is already well anchored in many system companies development processes, the challenge rests in lifting this from the current level of simulation-based analysis of functional system requirements to rich virtual integration testing catering as well for non-functional requirements. An approach to do so is contract-based virtual integration testing, where both subsystems and the complete system are equipped with multi-viewpoint contracts. Since subsystems now characterize their legal environments, we can flag situations, where a subsystem is used out of specification, i.e., in a design context, for which no guarantees on the subsystems reaction can be given. Our experience from a rich set of industrial applications shows that such virtual integration tests drastically reduce the number of late integration errors. Instances of virtual integration tests revealing failed integration early in the V thanks to the use of contracts include: • The lack of a component to provide complete fault isolation (a property presumed by a neighboring subsystem); • The lack of a subsystem to stay within the failure hypothesis assumed by a neighboring subsystem; • The lack of a subsystem to provide a response within an expected time-window (a property presumed by a neighboring subsystem); • The unavailability of a shared resource such as a bussystem 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). Multi-viewpoint contracts in virtual integration testing thus drastically extend the potential of uncovering integration errors early. Additionally, using such rich contracts in system specification comes with two key benefits, which help dealing with the complexity in the OEM-supplier relationship. First, the above approach to virtual integration testing is purely based on the subsystems contract specifications. In other words, if virtual integration testing is successful, any implementation of a subsystem compliant to this contract specification will not invalidate the outcome of virtual integration testing. Note that using this method the IP of subsystem suppliers is protected — the only evidence required is the confirmation that their implementation meets the subsystem contract specification. Second, assuming that the virtual integration test was passed successfully, we can verify whether the system itself meets its contract purely based on the knowledge of the subsystems contract and the systems architecture (and evidence that the subsystem implementation is compliant with this contract). This entails that, at any level of the supplier hierarchy, the higher-level organization can — prior to contracting suppliers — analyze whether the subsystems contracts pass the virtual integration test and are sufficient to establish the system
requirements. By then basing the contracts to suppliers on the subsystem contracts, and requiring subsystem suppliers to give evidence (such as through testing or through formal analysis methods) that their implementation complies to their contract, the final integration of subsystems to the complete system will be free of all classes of integration errors covered by contracts in the virtual integration test. C. Coping with the complexity of the supply chain To ensure coherent product development across complex supply chains, standardization of design entities, and harmonization/standardization of processes are key trends. There are multiple challenges in defining technical annexes to contracts between OEM and suppliers. Specifications used for procurement should be precise, unambiguous, and complete. However, a recurrent reason for failures causing deep iterations across supply chain boundaries rests in incomplete characterizations of the environment of the system to be developed by the supplier, such as missing information about failure modes and failure rates, missing information on possible sources for interferences through shared resources, and missing boundary conditions. This highlights the need to explicate assumptions on the design context in OEM-supplier contracts. In the light of an increased sharing of hardware resources by applications developed by multiple suppliers, this contract-based approach seems indispensable for resolving liability issues and allowing applications with different criticality levels to co-exist (such as ASIL levels [] in automotive). 1) Standardization of design entities: By agreeing on (domain specific) standard representations of design entities, different industrial domains have created their own lingua franca, thus enabling a domain wide shared use of design entities based on their standardized representation. Examples of these standards in the automotive sector include the recently approved requirement interchange format standard RIF11 , the AUTOSAR12 de-facto standard, the OSEK13 operating system standard, standardized bus-systems such as CAN14 and Flexray15 , standards for “car2X” communication, and standardized representations of test supported by ASAM16 . Examples in the aerospace domain include ARINC standards17 such as the avionics applications standard interface, IMA, RTCA18 communication standards. In the automation domain, standards for interconnection of automation devices such as Profibus19 are complemented by standardized design languages for application development such as Structured Text. As standardization moves from hardware to operating system to applications, and thus crosses multiple design layers, 11 http://www.w3.org/2005/rules/wiki/RIF_Working_Group 12 http://www.autosar.org/ 13 http://www.osek-vdx.org/ 14 http://www.iso.org/iso/search.htm?qt=Controller+Area+ Network&searchSubmit=Search&sort=rel&type=simple&published=true 15 http://www.flexray.com/ 16 http://www.asam.net/ 17 http://www.aeec-amc-fsemc.com/standards/index.html 18 http://www.rtca.org/ 19 http://www.profibus.com/
12
the challenge increases to incorporate all facets of design entities required to optimize the overall product, while at the same time enabling distributed development in complex supply chains. As an example, to address the different viewpoints required to optimize the overall product, AUTOSAR extended in transitioning from release 3.1 to 4 its capability to capture timing characteristics of design entities, a key prerequisite for assessing alternate deployments with respect to their impact on timing. More generally, the need for overall system optimization calls for the standardization of all non-functional viewpoints of design entities, an objective yet to be achieved in its full generality.
by Airbus to incorporate the knowledge base of external hazards from flight incidents, the Code of Practice proposed by the Prevent Project using guiding questions to assess the completeness of requirements in the concept phase of the development of advanced driver assistance systems. Use-case analysis methods as advocated for UML based development process follow the same objective. A common theme of these approaches is the intent to systematically identify those aspects of the environment of the system under development whose observability is necessary and sufficient to achieve the system requirements. Pushing this further again leads to using contracts: based on a determined system boundary, responsibilities of achieving requirements are split into those to be established by the system-under-development (the “guarantees” of the contract) and those characterizing admissible environments of the system-under-development (the “assumptions” of the contract). However, the most efficient way of assessing completeness of a set of requirements is by executing it. This consists in what David Harel called “playing out” for the particular case of live sequence charts [18], [19], [20], i.e., the use of formalized contract specifications to generate trajectories of interface observations compliant with the considered set of contracts. Such simulation capabilities turn out to be instrumental in revealing incompleteness: typically, they will exhibit unexpected traces, e.g., due to an insufficient restriction of the environment, or only partially specified system reactions. Executing requirements is only possible if semi-formal or formal specification languages are used, where the particular shape of such formalizations is viewpoint and domain dependent. Examples include the use of failure propagation models for safety contracts, the use of probabilistic timed automata to specify arrival processes, the use of live sequence charts for capturing scenarios in the interaction of actors and systems, or formalized requirement languages such as the PSL standard [27] combining temporal logic and automata based specifications used in the EDA domain, or the patternbased contract specification language defined by the integrated project SPEEDS. In addition, using contracts resting on logic-based formalisms comes with the advantage, that “spurious” unwanted behaviors can be excluded by “throwing in” additional contracts, or strengthening assumptions, or by considering additional cases for guarantees. A second advantage rests in the capability of checking for consistency by providing effective tests, whether a set of contracts is realizable, or whether, in contrast, facets of these are inherently conflicting, and thus no implementation is feasible.
2) Standardization/harmonization of processes: Harmonizing or even standardizing key processes (such as development processes and safety processes) provides for a further level of optimization in interactions across the supply chain. As an example, Airbus Directives and Procedures (ADBs) provide requirements for design processes of equipment manufactures. Often, harmonized processes across the supply chain build on agreed maturity gates with incremental acceptance testing to monitor progress of supplier development towards final acceptance, often building on incremental prototypes. Shared use of Product Lifcycle Management (PLM) [30] databases across the supply chain offers further potentials for crosssupply chain optimization of development processes. Also, in domains developing safety related systems, domain specific standards clearly define the responsibilities and duties of companies across the supply chain to demonstrate functional safety, such as in the ISO 2626220 for the automotive domain, IEC 6150821 for automation, its derivatives Cenelec EN 50128 and 5012622 for rail, and Do 178 B23 for civil avionics. Yet, the challenge in defining standards rests in balancing the need for stability with the need of not blocking process innovations. As an example, means for compositional construction of safety cases are seen as mandatory to reduce certification costs in the aerospace and rail domains. Similarly, the potential of using formal verification techniques to cope with increasing system complexity is considered in the move from DO 178 B to DO 178 C standards. D. Getting initial requirements right Depending on application domains, up to 50% of all errors result from imprecise, incomplete, or inconsistent and thus unfeasible requirements. Out of the many approaches taken in industry for getting requirements right, we focus here on those for initial systems requirements, relying on ISO 26262 compliant approaches. To cope with the inherently unstructured problem of (in)completeness of requirements, industry has set up domainand application-class specific methodologies. As particular examples, we mention learning process, such as employed
E. Coping with multi-layer design optimization System designs are often the result of modifications of previous designs with the attempt of minimizing risks and reducing delays and design costs. While this was an effective way of bringing new products to market in the past, with the increase in demand for new functionality and the advances of the implementation platforms, this strategy has yielded more
20 http://www.iso.org/iso/catalogue_detail.htm?csnumber=43464 21 http://www.iec.ch/functionalsafety/ 22 http://www.cenelec.eu/Cenelec/CENELEC+in+action/Web+Store/ Standards/default.htm 23 http://www.do178site.com/
13
problems than it has fixed. Indeed, there is a shared consensus that in most of the cases the designs are not optimized in the sense that the full exploitation of the new opportunities technology offers is not achieved and that having visibility of the available options and an evaluation framework for design alternatives are a sorely missing capability. An ideal scenario for optimization is to have access to the entire design space at the lowest possible level of abstraction and then run a global optimization algorithm that could select these components satisfying constraints and optimizing multiple criteria involving non-functional aspects of the design. Unfortunately this approach is obviously out of the question for most designs given the size of the design space and the capabilities of optimization algorithms. What is possible is to select solutions in a pre-selected design space where the number of alternatives to choose from is finite and searchable by state-of-the-art optimization programs. Indeed, the platform-based design paradigm offers scaffolding that would support this approach. In fact, at any abstraction layer, we need to optimize with respect to the components of the platform. The selection process will have to look only at feasible combinations of the components as dictated by the composability contracts.
•
•
•
F. Managing risk across the development process The realization of complex systems calls for design processes that mitigate risks in highly concurrent, distributed, and typically multi-domain engineering processes, often involving more than one hundred sub-processes. Risk mitigation measures typically cover all phases of design processes, ranging from ensuring high quality initial requirements to early assessments of risks in realizability of product requirements during the concept phase, to enforcing complete traceability of such requirements with requirements management tools, to managing consistency and synchronization across concurrent sub-processes using PLM tools. A key challenge rests in balancing risk reduction version development time and effort: completely eliminating the risks stemming from concurrent engineering essentially requires a complete synchronization along a fine-grained milestone structure, which would kill any development project due to the induced delays. Current practice leads to typically implicit assumptions about design aspects to be guaranteed by concurrent processes — designers are “speculating” on outcomes of concurrent engineering sub-processes, based on their experiences from previous designs. These assumptions should be made explicit — emphasizing once again the high methodological value of assumptions — and associate these with risk-levels, which qualify or quantify the expected risks in not achieving such assumptions [8]. This very same instrument can be put in place during the concept phase of development processes, where vertical assumptions form the key basis for assessing realizability of requirements. We see the following key usecases for exploiting risk-level labeled assumptions within riskmitigation strategies, assuming a setting with multi-viewpoint contracts.
We extend requirements management tool in exploiting the structure of contracts to maintain a full dependency graph between guarantees and their supporting assumptions including risk levels. Prototype implementations of this based on the Reqtify product of Geensys (now a Dassault company) have been developed in the context of the integrated project SPEEDS. This goes beyond current practice in its capability to quantify the risk level for the parts of the design which must be modified. By monitoring the criticality of risk-levels of assumptions within individual sub-processes to achieve this subprocesses objectives we can trigger synchronization with processes responsible for establishing such assumptions to reduce their risk-level. Within the integrated projects SPEEDS, we have developed a process advisor [17] for on-line monitoring the risk-level of assumptions as basis for advices on such risk-reducing measures. We can assess the effect of replacing parts of the design basis by computing the cumulative risk induced from partially invalidated assumptions induced by the change, if any. Ideally, the effect of the change can be completely encapsulated by re-establishing the contracts of the original design base. If this is not achievable, one can exactly identify the violated assumptions and quantify the resulting risk.
G. Platform-Based Design and Contracts In the previous sections, we have reviewed a number of approaches that tackle the challenges set up in the Introduction. We outlined briefly the use of contracts in each context and their relevance. The extreme flexibility of contracts allows their universal use in all methodologies. It is therefore appealing to anchor the discussion introducing a design methodology that encompasses all the methods described in the previous sections and exemplify the use of contracts in this framework. This combination will be used in the rest of the paper as the reference design approach. 1) Platform-based design: Platform-based design was introduced in the late 1980s to capture a design process that could encompass horizontal (component-based design, virtual integration) and vertical (layered and model-based design) decompositions, and multiple viewpoints and in doing so, support the supply chain as well as multi-layer optimization. The idea was to introduce a general approach that could be shared across industrial domain boundaries, that would subsume the various definition and design concepts, and that would extend it to provide a rigorous framework to reason about design. Indeed, the concepts have been applied to a variety of very different domains: from automotive, to Systemon-Chip, from analog circuit design, to building automation to synthetic 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 is supposed to do) is strictly separated from architecture (how 14
the functionality could be implemented). This aspect is clearly related to layered design and hence it subsumes it. Each abstraction layer is defined by a design platform. A design platform consists of •
•
•
section II-B1 on viewpoints are indeed special cases of this general approach. 2) Contract-based design: Contracts in PBD: In PBD, contracts can play a fundamental role in determining the correct composition rules so that when the architecture space is explored, only “legal” compositions of available components are taken into consideration. They can be used to verify whether the system obtained by composing the library elements according to the horizontal contracts satisfies the requirements posed at the higher level of abstraction. If these sets of contracts are satisfied, the mapping mechanism of PBD can be used to produce design refinements that are correct by construction. To be more precise about these concepts that are key for the rest of the paper, consider a snapshot in a platform based design process, as shown in Figure 3, covering adjacent design layers N + 1, N , and N − 1. System S is realized at layer N by the composition of systems S1 , S2 , and S3 .
A set of library components. This library not only contains computational blocks that carry out the appropriate computation but also communication components that are used to interconnect the computational components. Models of the components that represent a characterization in terms of performance and other non-functional parameters together with the functionality it can support. Not all elements in the library are pre-existing components. Some may be “place holders” to indicate the flexibility of “customizing” a part of the design that is offered to the designer. In this case the models represent estimates of what can be done since the components are not available and will have to be designed. At times, the characterization is indeed a constraint for the implementation of the component and it is obtained top-down during the refinement process typical of layered designs. This layering of abstractions based on mathematical models is typical of model-based methods and the introduction of non-functional aspects of the design relates to viewpoints. The rules that determine how the components can be assembled and how the the functional and non-functional characteristics can be computed given the ones of the components to form an architecture.Then, a platform represents a family of designs that satisfies a set of platformspecific constraints. This aspect is related to componentbased design enriched with multiple viewpoints.
This concept of platform encapsulates the notion of re-use as a family of solutions that share a set of common features (the elements of the platform). Since we associate the notion of platform to a set of potential solutions to a design problem, we need to capture the process of mapping a functionality (what the system is supposed to do) with the platform elements that will be used to build a platform instance or an “architecture” (how the system does what it is supposed to do). The strict separation between function and architecture as well as the mapping process have been highly leveraged in AUTOSAR. This process is the essential step for refinement and provides a mechanism to proceed towards implementation in a structured way. Designs on each platform are represented by platformspecific design models. A design is obtained by a designer’s creating platform instances (architectures) via composing platform components (process that is typical of component-based design), by mapping the functionality onto the components of the architecture and by propagating the mapped design in the design flow onto subsequent abstraction layers that are dealt with in the same way thus presenting the design process as an iterative refinement. This last point dictates how to move across abstraction layers: it is an important part of design space exploration and offers a way of performing optimization across layers. In this respect PBD supports multiple perspectives in a general way. The five perspectives presented in the
Figure 3.
Contracts in a PBD flow.
Horizontal contracts: In this setting, contracts serve different objectives. As highlighted in the subsection on virtual integration testing, a key value of contracts is to detect integration errors early. We use the term horizontal contract related to virtual integration testing, which thus in Figure 3 define under what conditions the integration of subsystems into the composite system S is considered successful. Specifically, a horizontal contract C H of a system S represents in its assumption AH the constraints it itself imposes on any possible integration context C[ ], so as to be able to realize its function F . As an example of this contract-based virtual integration testing, consider Figure 3. Each of the subsystems Sj are H equipped with horizontal contracts C H (Sj ) = (AH j , Gj ). To simplify, we restrict assumptions to be carried by input ports and guarantees to be carried by output ports. The theory developed in companion paper [3] covers the general case but explanations would be less intuitive. Contract-based virtual 15
hinges on finding an implementation of S meeting this bottomup vertical contract. When using budgeting, the designer assigns responsibilities to the subsystems of S by deriving top-down contracts for each, which jointly establish S´s bottom-up vertical contract. Alternatively, when using a bottom-up approach, we assume the top-down vertical contracts of Sj as given, and establish either directly or passing through a characterization of the functionality realized by S at layer N (as a top-down contract), that the layer N + 1 bottom up contract of S is satisfied. In both the top-down and bottom up approach, the verification of this cross-layer design steps would assume that the contractbased virtual integration test was successful. This allows using the guarantees of horizontal contracts as additional premise in the verification of refinement steps. We finally point out that additional verification steps are required for each component to demonstrate that, based on the expected capabilities of its realization, as expressed by its bottom-up vertical contract, the functionality of the component as expressed by its top-down vertical contract can be achieved. Again, this proof can take horizontal contracts of the component as additional supportive arguments. For composed systems, such as the system S at layer N in Figure 3, the bottom-up contracts are given by the set of bottom-up contracts of its leaf components. Crossing design layers thus asks for verification of either refinement (top-down) or aggregation (bottom-up) steps. The presentation given so far ignores extensions of the framework required in practice to deal with what is often called interface refinement, e.g., [6], [23]. Due to the very purpose of abstraction layers of hiding complexity, a representation of a design at level N will typically explicate implementations aspects such as representations of messages and variables, protocols used for communication and synchronization. In general, both the representation of the system in the data-domain as well as in the time domain may change, calling for notions of refinement which are expressive enough to deal both with re-timing and type conversions. The theory for these notions of weak simulation relations is well understood for particular classes of mathematical models (see [16]), which jointly are rich enough to support a broad spectrum of viewpoints, including safety, real-time, performance, power. To allow to build on these in the methodology for contractbased design, we introduce what we call simulation components relating traces, i.e. sequences of observations of ports of a level N + 1 component S to sequences of observations of ports of components S at level N . Referring to Figure 3, this component would thus have an interface towards layer N + 1 observing ports p1S and p2S , and an interface towards layer N observing ports p1S , p2S , and p3S . Simulation components can use contracts to characterize the intended inter-relation between valuations of these. As discussed in later sections, these contracts can take the form of both logic-based and automata-based formalisms, giving sufficient expressivity in capturing the intended relations between traces of interface objects of S at level N + 1 and level N .
integration testing then requires to be able to demonstrate all assumptions AH j from the given design context. For example, let us consider subsystem S2 . Its design context is in part given by subsystem S1 , which thus becomes responsible for establishing those horizontal assumptions relating to S2 ´s inport p21 . Intuitively, then, we expect the guarantee GH 1 of the horizontal contract of S1 to be sufficient to demonstrate compliance of any restrictions S2 was placing on allowed uses of p21 . Note also the dependency of S2 on the yet undetermined part of the design context of S2 reflected by input p3S to the realization of system S on layer N . In general, then, in contract-based virtual integration testing, this yet unknown design context is represented by horizontal contracts of the composed system S itself; Figure 3 highlights H H the horizontal contract CN (S) = (AH N (S), GN (S)) of S at layer N . This contract will enforce, that any design context of S will be guaranteed to be compliant to AH N (S). Thus, when checking the design context of S2 for compliance to its horizontal assumptions on uses of port p3S , we expect this to be derivable from AH N (S). In general, then, in contractbased virtual integration testing, we need to demonstrate that all horizontal assumptions of subsystems can be derived from the conjunction of all horizontal guarantees of subsystems and horizontal assumptions of the composed system. Circular reasoning: The detailed mathematical formulation of this will be discussed in companion paper [3]. However, already at the current level of discourse we point to the fact, that the above argument typically involves circular reasoning. For example, in Figure 3 GH 1 will only be guaranteed for legal design contexts of S1 . Thus, only once AH 1 is established, can we actually rest our argumentation on GH 1 . Establishing, H then, AH 1 , we would like to involve G3 , which, however, is only sound once AH 3 is established. This, finally, would involve GH 2 as witness, but it is exactly for the purpose of establishing AH 2 , that this reasoning chain is established. The mathematical theory essentially justifies the use of such seemingly circular arguments, for classes of contracts whose assumptions and guarantees are expressible in the rich set of safety properties (which can always be proven and disproven by finite observations). However, certain restrictions on how assumptions and guarantees refer to out-ports respectively inports of a system have to be observed. Vertical contracts: Each of the subsystems Sj can then either be further refined, or assumed to be given as design basis at layer N , as platform library elements. Such components, as S2 in Figure 3, could be placeholders, to be then elaborated in a design process at layer N −1. Symmetrically, Figure 3 shows the system S at layer N as a realization of the placeholder S at layer N + 1. To transition across design 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 is expected to be offered by possible implementations of S at layer N , so as to be able for S to perform its intended function at layer N + 1 as expressed by a top-down vertical contract. This entails, that the correctness of the level N + 1 design 16
Strong vs. weak assumptions and the issue of compatibility: We close this section by pointing out a subtle, but highly relevant, difference in the methodological use of assumptions in horizontal and vertical contracts. Within horizontal contracts, assumptions are used to restrict the allowed design context of a component. By enforcing contract-based virtual integration testing, as discussed above, we therefore complement each model-based integration steps with verification activities demonstrating that the currently known design context C[ ] of a component S actually complies to these restrictions. This is key to enforcing what has been called composability of systems by [24], a fundamental principle in good architecture design ensuring functionality realized by components of the architecture are maintained when integrating these into a compound architecture. It is the purpose of assumptions to support this composability property. Specifically, if system 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 guaranteed to offer its functionality F (S) when being put into this design context C[ ]. We refer to assumptions which must be enforced for the component to behave as expected as strong assumptions. In contrast, additional assumptions may be added to the strong assumption to ensure that if these assumptions are met, then “non essential” but desired properties are guaranteed. These additional assumptions are called in contrast weak assumptions. In vertical contracts, in particular in bottomup contracts, weak assumptions represent anticipations often based on experience or estimation functions on what could be assumed to be realizable by lower implementations levels. As the designs refines vertically across multiple layers, eventually such assumptions either become validated based on top-down contracts of completed designs, or invalidated (e.g. due to insufficient processing power, non-matching assumptions on failure distributions, or insufficient signal strength). By maintaining dependency between contracts, it is then possible to backtrack to the higher-level bottom up assumption which thus became invalidated, and explore possibilities of weakening, such as by re-budgeting. Turning assumptions in vertical contracts to strong assumptions would entail a binding restriction of the design space: a failure to meet such strong vertical assumptions would be considered a contract failure. Strong vertical assumptions can be used to enforce compliance to standards, or within the supply chain hierarchy, to eliminate the likelihood of deep design iterations crossing organizational boundaries. In a generalized setting, such as currently pushed in the context of the German Innovation Alliance for Embedded Systems,24 we thus allow contracts to refer to both strong and weak assumptions, allowing to customize design processes supporting additional use cases of strong assumptions as outlined above.
H. Moving forward: the importance of contracts Contracts in their most elementary form may just take the form of informal textual requirements, yet with the key distinguishing feature of explicating the separation of concerns: what must be guaranteed by the system itself, and what are the constraints on environments, which are fundamentally required so as to allow the system — based on such assumptions — to enforce its guarantees. We have then seen how this core paradigm matches well with the orthogonal notion of viewpoints: contracts can thus be flagged as to the viewpoint they relate to. Clearly, the number of viewpoints to be supported may vary from application to application — thus it is up to the customization of contract-based design within a company’s development process, to determine the set of viewpoints that must be supported. For sure, this will go beyond capturing the functionality, with safety viewpoints and real-time viewpoints being a necessity in safety relevant embedded systems development. Business related viewpoints such as the ones reflecting costs, constraints from manufacturing, maintainability are natural choices, as are those related to resource consumption. Orthogonal to this discussion is the degree of formalization used in contracts. As highlighted above, there is already high methodological value when using informal contracts. A natural next step is to restrict the vocabulary of contracts to (domain specific) ontologies. Further steps towards formalization are viewpoint dependent: as elaborated in subsequent sections, they can, for example, take the form of automata-based specifications, employ suitable logics, build on a library of patterns, and capitalize on sequence charts. The additional effort in providing a degree of formalization is typically well invested due to the additional benefits we have outlined above, such as testing consistency of requirements, identifying complex integration errors early through virtual integration testing, boosting re-use though component-based design, and allowing cross-layer design optimizations based on performing platform-based design. The key point we raise is that this formalization can be done incrementally and on a case-bycase basis. Thus, there is a clear migration strategy from using contracts informally, to incorporating domain ontologies, to gradually enriching the number of covered viewpoints, and to gradually increase the degree of formalization. No matter in which order such steps are taken, each of these comes with significant potentials for process improvements. It is the objective of this paper to let designers capitalize on this so-far largely unexploited tool. The value proposition of adding contracts to system companies deveLopment processes is now on the table — the ultimate test rests in the market take up. Strong indications of market acceptance are the anchoring of the contract-based approach within the CESAR 25 Reference Technology Platform (RTP), where 25 European global players in the systems market team up with leading vendors, research institutes, and SMEs, to create an innovation ecosystem around the emerging standard meta-model of the CESAR RTP.
24 See SPES2020 Architecture Modeling Deliverable of the German Innovation Alliance on Embedded Systems SPES 2020,BMBF grant FK 01 IS O8045 W, http://spes2020.informatik.tu-muenchen.de
25 www.cesarproject.eu
17
The next section is intended to make examples of contractbased design more concrete by going through the various steps of contract-based systems engineering with a simple but sufficiently representative design example.
number of payment stations can be substantially reduced with the respect to the previous option and so that the gates and the payment machines could be designed separately. The second option was chosen to yield the system architecture of Figure 4. To prepare the contracts with the suppliers, the following set
III. C ONTRACTS IN R EQUIREMENT E NGINEERING : THE PARKING G ARAGE E XAMPLE
Parking functional viewpoint
In this section we discuss the use of contract-based design as defined in the previous section in a simple example to expose the issues related to contracts in the early design phases. Using the example, we also outline the need for requirement engineering as a prerequisite for using contracts effectively (and for ANY well-structured design methodology). This example deals with the design of a parking system. This example was chosen to be simple but rich enough to cover many issues related to contracts and pinpoint problems raised by the current practice and pitfalls that may result.
System Payment User
safety viewpoint
Figure 4. Parking system top-level architecture. See Section III-I regarding functional and safety viewpoints for the Parking.
of requirements is derived by the system designers:
A. Top-level specification of the example
Specification 2 (System level derived requirements): 1) A user may enter only if the entry gate is open; 2) The entry gate may open only if the parking is not full; 3) If the user presses the button, then the entry gate may open and must return a ticket marked with the time of entrance; 4) The cost of parking is a monotonic function of the time spent in the garage; 5) Parking is not allowed for more than 3 days; 6) The user may pay only after having introduced her ticket; 7) [blank] 8) The user can pay only with coins; 9) The payment machine only accepts coins or credit cards; 10) If the payment is correct, a clearance ticket is returned; 11) [blank] 12) The clearance ticket is valid for 5 minutes; 13) Upon entering a valid clearance ticket, the exit gate opens; 14) A user may exit only if the exit gate is open.
A parking lot offers a certain amount of physical resources to its users (the parking slots). These resources are granted upon availability. For parking garages that are operated commercially, the resource is granted subject to payment that is intended to create a revenue stream to the operator and at the same time, to regulate the use of the resource. A top-level specification for the parking garage with its users can be stated as follows: Specification 1 (Top-level specification): 1) The parking garage shall offer 500 locations and shall support a ratio of 10% of entry/exit with respect to the total number of locations; 2) Access shall be granted if the parking is not full; 3) Fairness shall be enforced in using the resource, i.e., no user can occupy a parking slot for an indefinite time; 4) This is a commercial service, subject to payment. The top-level specification involves the closed system consisting of the parking together with its users. In the early phase of the design, this specification should state only very high-level objectives and should not preclude any particular technical solution to allow maximal freedom for effective implementation. Given this top-level specification, the system designer must: 1) Explore its feasibility, draw solutions, and derive a system architecture, and 2) Partition the system into subsystems, define requirements for the subsystems and establish contracts with the suppliers. For our design, we rely on gates for the mechanism of granting access. This step can be considered as a refinement of the original system since additional details are offered for the implementation of the various processes. A further refinement to define the architecture of the system is related to the payment process. We can consider two solutions: one where the payment is connected to the exit gates, the other where payment machines are located in a centralized zone so that the
The [blank] are place holders for additional requirements that will be discussed in the sequel. Specification 2 must then be allocated to two suppliers—one in charge of the gates and one the payment machines, respectively stipulated as usage rules for users. Beforehand, several tasks must be performed to validate Specification 2, i.e., to demonstrate that they provide a valid solution to the top-level specification, which must be achieved even if the latter is not stated in formal terms. We review these tasks now. The consideration of requirements 8 and 9 may seem strange; it is, however, motivated by the discussion on Section III-H. B. Domain specific ontology It is essential that all members of different design teams agree on a common and unambiguous structured vocabulary for their specific domain or application area. This is referred to as the domain specific ontology. In our example, see Figure 4, 18
we first identify the different subsystems related to the system architecture: the parking garage, with its entry gates and exit gates; the payment machine; and, finally, the users. Then, we must identify, in Specification 2, which other entities are meaningful for the system and its subsystems and how they are structured: interaction between user and parking involves the entry gates and exit gates; interaction between the user and the payment machine involves the ticket and payment; interaction between the user, the payment machine, and the exit gate involves the clearance ticket. Observe that “parking” has a dual meaning, namely the parking with its gate seen as a subsystem, and the action of parking (in Specification 2.4 and 2.5). If requirements are to be formalized, then these two different meanings must be assigned two different terms. We propose to use the term staying-in-parking for the latter meaning. For large documents involving thousands of requirements, building the ontology must be done concurrently with the action of writing the requirements. This is by no means trivial, but is out of the scope of this paper.
imposed by the requirements. This process helps the designer assess the quality of her specification. It is also useful for the designer to interact with the customer to assess whether the requirements reflect her expectations. Executing requirements is, of course, not possible for every type of requirement even if they are expressed in mathematical terms; for instance, requirements involving physical characteristics of the system cannot be executed until an implementation is proposed. In the context of our running example, it may be asked that the gates shall be soft enough not to hurt a pedestrian neither to damage a car. Clearly this kind of requirement cannot be executed—until the material used in the construction of the gate and its dynamics behavior (hence, its implementation) are available. Still, a large part of requirements can generally be executed—all of the requirements in Specification 2 can once expressed in mathematical form. E. Identifying responsibilities Identifying responsibilities in the requirements, i.e., which actor is supposed to guarantee that the requirements are met and which actor impacts and is impacted by the requirement, allows identifying some implicit assumptions that may become a source of faulty design. Referring to our running example, analyzing Specification 2, we note that this specification assumes that the user will not cheat by producing falsified tickets that reuse the Id of other tickets—this could allow leaving the parking by paying for 5min while having spent one day; alternatively, a user could use several times a ticket that has been cleared after payment. Thus, the [blank] place holders must indeed be filled with the following additional requirements to prevent malicious behaviors of the users:
C. Defining and firming up requirements Since the top-level specification is often informal, gathering system level requirements typically represent the first step of the design flow. Requirements may not faithfully represent the designer’s intent and thus cannot be taken as “the right definition of the system”, they must be validated. They are subject to errors—erroneous requirements are indeed a serious source of problems in system design. Therefore, a deep scenario analysis with a variety of tests should be performed with the goal of answering a fundamental question: How good are the stated requirements in reflecting the designer’s (and users’) intent? In particular, the process of requirement capture and of writing requirement documents are important matters for discussions with certification bodies. These bodies would typically assess a number of quality criteria for example, selecting them from the following list elaborated by INCOSE [21]: Accuracy, Affordability, Boundedness, Class, Complexity, Completeness, Conciseness, Conformance, Consistency, Correctness, Criticality, Level, Orthogonality, Priority, Risk, Unambiguousness, and Verifiability. There are several specific means that can be used to evaluate these criteria.
Corrections to Specification 2: 7) Only tickets issued by the parking can be inserted in the payment machine and tickets can be inserted at most once; 11) Only clearance tickets issued by the payment machine can be inserted in the exit gate and clearance tickets can be inserted at most once. The pilot trials performed within the SPEEDS EU-project (see http://www.speeds.eu.com) highlighted the central role of identifying responsibilities and making assumptions explicit in achieving a higher degree of completeness in system specification. Note that identifying responsibilities is purely a methodological step and has its value regardless of any formalization. Table II identifies, for each requirement, which subsystem is responsible for satisfying it and which ones are affected and affect the requirement. The subsystems involved in the table are ”user”, ”payment” and ”parking”.
D. Executing requirements We insist that analyzing the requirements and verifying their consistency and coverage is essential in any well-formed design process, albeit in practice, this step is missing in many industrial flows. To do so, the informal textual description should be converted into a mathematical representation. Simulation and formal verification then can be used to perform these tasks. A mathematical representation allows executing the requirements. Requirements constrain events, actions, and parameters of the system under design. Executing requirements is necessary for exploring instances and behaviors of these events, actions, and parameters that meet the constraints
F. Partitioning and allocating requirements to subsystems To allocate requirements to a subsystem, e.g., “payment”, we proceed as follows, using Table II: • Collect from Table II the requirements that are involved with “payment” but are not under its responsibility— these are R2.7 and R2.8 . These are not requirements for 19
Requirement R2.1 R2.2 R2.3 R2.4 R2.5 R2.6 R2.7 R2.8 R2.9 R2.10 R2.11 R2.12 R2.13 R2.14
Responsible user parking parking payment user payment user user payment payment user parking parking user
Involved parking
13) Upon entering the clearance ticket, the exit gate opens; 14) A user may exit only if the exit gate is open.
user user
So far this completes the subsystems’ requirements. The last step consists of deriving the user’s requirements: Contract 3 (“User”): 1) A user may enter only if the entry gate is open; 3) If the user presses the button, then the entry gate may open and then must return a ticket marked with the time of entrance; 4) The cost of staying-in-parking is proportional to the time spent; 5) Staying-in-parking is not allowed for more than 3 days; 6) The user may pay only after having introduced her ticket; 7) Only tickets issued by the parking can be inserted in the payment machine and tickets can be inserted at most once; 8) The user pays with coins; 9) The payment machine only accepts coins or credit cards; 10) If payment is correct, a clearance ticket is returned; 11) Only clearance tickets issued by the payment machine can be inserted in the exit gate and clearance tickets can be inserted at most once; 12) The clearance ticket is valid for 5 minutes; 13) Upon entering the clearance ticket, the exit gate opens; 14) A user may exit only if the exit gate is open. Assumption 1.7 expresses that the user cannot cheat by falsifying a ticket in some way. It occurs as a guarantee in Contract 3 for the “user”. It is tempting to consider that starting with no such assumption as a first step, and then adding it in a second step after further thinking, is a correct process. It is, however, not! Indeed, as we shall later see, it is problematic to strengthen the assumptions made on the environment, when updating the requirements for a subsystem (here: the “payment”). Problems may arise at integration level if this strengthening of assumptions is not forwarded to the other subsystems with which the considered subsystem is interacting (here: the “user”).
user payment payment user user parking user user parking
Table II Indentifying subsystem (including the “user”) responsible for and the ones involved with the requirements. Notation R2.i refers to the ith requirement among Specification 2.
the “payment” subsystem. Instead, they constitute the assumptions under which the “payment” subsystem must operate. • Collect the requirements that are under the responsibility of “payment”—these are R2.4 , R2.6 , R2.9 , and R2.10 . They constitute the obligations for the “payment” subsystem and are taken as subsystem requirements. To highlight the symmetry with respect to the assumptions when dealing with contracts, the obligations above are often called guarantees. We will stick to this wording in the the rest of the paper. Performing this operations yields the following set of assumptions and guarantees, thus constituting the contract for the “payment” subsystem. In this and the following contracts, “guarantees” are in italics, whereas “assumptions” are in roman: Contract 1 (Subsystem “Payment”): 4) The cost of staying-in-parking is proportional to the time spent; 6) The user may pay only after having introduced her ticket; 7) Only tickets issued by the parking can be inserted in the payment machine and tickets can be inserted at most once; 8) The user pays with coins; 9) The payment machine only accepts coins or credit cards; 10) If payment is correct, a clearance ticket is returned.
G. Further Refining Requirements Suppose that the system designer (an OEM) has subcontracted the subsystem “parking” to some supplier for its design. Based on her experience in designing parking management systems, this supplier has an off-the-shelf design implementing a set of assumptions and guarantees consisting of Contract 2 augmented with the following additional assumptions and guarantees (we use fresh labels for these, while keeping the same convention as before regarding assumptions versus guarantees): Contract 4 (Subsystem “Off-the-shelf parking”): This contract consists of Contract 2 augmented with the following assumptions and guarantees: 1) If the user presses the button, the entry gate must open within 10 sec; 2) Upon entering the clearance ticket, the exit gate must open within 10 sec;
Contract 2 (subsystem “Parking”): 1) A user may enter only if the entry gate is open; 2) The entry gate may open only if the parking is not full; 3) If the user presses the button, then the entry gate may open and then must return a ticket marked with the time of entrance; 11) Only clearance tickets issued by the payment machine can be inserted in the exit gate and clearance tickets can be inserted at most once; 12) The clearance ticket is valid for 5 minutes; 20
3) When the exit gate opens, the user must exit within 10 sec; 4) Entry and exit gates are soft enough not to hurt pedestrians.
Contracts 1 to 3 is a safe step? Also, was the supplier for the parking right in proposing her off-the-shelf design? These are important questions that are typically formulated as follows: Property 3 (Refinement): 1) Does the composition of Contracts 1 to 3 refine Specification 2? 2) Does Contract 4 for the off-the-shelf parking refine the original Contract 2 for the parking?
The first two additional guarantees refer to the timing behavior of the gates. The new assumption specifies the timing behavior of the user. Finally, the last guarantee is related to the parking hardware. Since the supplier has achieved more with this off-the-shelf parking management system, the corresponding design can be delivered to the OEM, at least as it seems to be the case. . .
Observe that this refinement property resembles the informal request of “completeness” that was stated as Property 1. The difference here is that system-wide requirements provide the missing reference against which refinement can be assessed. Each requirement document sets obligations on the considered subsystem (the requirements in italics) and implicit obligations on the environment (the assumptions made by the subsystem, written in roman). Are these feasible obligations? Note that the same issue arises when we consider the composition of Contracts 1 to 3. This property is generally referred to as “consistency”. We also consider its symmetric property of “compatibility” since we distinguished guarantees (to which the subsystem is committed) from assumptions (which are the duty of the environment). Property 4 (Consistency and Compatibility): Do designs exist that meet Contract 1-4 consistency? Do environments exist that meet Contract 1-4 compatibility? For example, requirements R2.8 and R2.9 might have been a source of non compatibility for the system wide requirements document—they are, however, compatible as they stand. Other properties are often requested by certification bodies regarding requirements engineering. Some of these properties concern ontologies. For example, are the terms used in the requirements capture well defined? are these terms consistently used? (This should not be confused with property 4.) Other properties concern the design flow. For example, are the requirements verifiable? (Are there ways of and design steps for checking these requirements?) While these are important issues, they are not fundamental to the development of theories underpinning requirements engineering.
H. More on Fundamental Properties At the beginning of this section we mentioned a number of properties that qualify the goodness of the requirements document, these were referred to as INCOSE criteria. A number of these criteria are clearly subject to human judgement. Examples of such properties include: Accuracy, Affordability, Level, Priority. However, several INCOSE criteria are more essential in that they qualify the soundness of both the requirements document and system design flow. We review them next. The first one is related to the completeness of requirements: Property 1 (Completeness): Are the requirements listed in Specification 2 complete? Completeness should be defined according to some reference. However, by definition, such a reference does not exist since Specification 2 is the entry point of the design process. Consequently, this question cannot be really formalized in our context, albeit it can be given a formal meaning in other contexts, e.g., for ontologies. Still, completeness can be explored in practice by executing and analyzing requirements as explained in Section III-C. Regarding our example, inspection of Specification 2 could reveal that there is a missing requirement specifying that the gates should be closed after a user enters or exits—to simplify our example we do not add this missing requirement though. The second question concerns what it means for a design to satisfy a contract.
I. Requirements and system architecture While refining requirements during the design flow, we may encounter requirements that involve multiple view points, for example reliability of the design. As an example, consider the following safety (or reliability) viewpoint for the parking: Contract 5 (subsystem “Parking”, safety viewpoint): 1) The probability that a user will cause damage to the gates is less than 10−10 ; 2) If the parking is not full, the probability that the entry gate remains closed is less than 10−9 ; 3) If a clearance ticket is entered, the probability that the exit gate remains closed is less than 10−9 .
Property 2 (Correctness of Designs): What does it mean for an actual design to satisfy a given contract? The basic idea is that the design should “satisfy all requirements”. While this idea conforms to our proposal that requirements belonging to the same document are composed in a conjunctive way, this is not sufficient. We must in particular handle assumptions and guarantees differently. A valid understanding of correctness is thus the following: When a design is inserted in an environment that includes other components of the design as well as external agents, if its interactions with the environment satisfy the assumptions, then the component is such that its guarantees to the environment are met.
Observe that we have again assigned responsibilities for the safety requirements by distinguishing between the “spontaneous” failures of the gates and the damage caused by the environment (the users).
The next property to be checked concerns the assignment of requirements to subsystems: In which sense can we ensure that replacing system wide Specification 2 by the composition of 21
The question arises of how to deal with requirements that involve assumptions and guarantees that relate to different aspects of the design and yet they are to be considered somehow together.
Industrial deployment is now on its way and tools are being developed and fielded that support the AUTOSAR design methodology. Modifications to the standard must be carefully weighted against the risk of causing disturbances in the current critical roll-out phase of Version 4. In dealing with the issue of introducing the contract-based paradigm within AUTOSAR, we carefully distinguish between benefits which can be achieved based on the current release, and what could be additional benefits in future releases. This section benefits from discussions with industrial partners, as well as from the involvement of the organizations of some of the authors as AUTOSAR development members.
Question 1 (Conjunction): What does it mean to structure a contract into a set of viewpoints? Contracts 2 and 3 involve several assumptions and guarantees. Thus we need to define how these different properties are combined: since the intent is that “all properties apply”, it is tempting to consider that assumptions and guarantees are combined in a conjunctive way. This is, however not correct in general. Indeed, assumptions and guarantees must be handled differently when dealing with two viewpoints. In other words, assumptions and guarantees must be combined in specific ways when taking the conjunction of viewpoints, e.g., functions, interfaces, safety, energy, and so on. An important issue related to viewpoints is to understand what should be the meaning of their conjunction. Referring to our running example, we need to deal with the function realized by the parking (Contract 2, denoted by Cpark ) and its safety requirements (Contract 5, denoted by Cpark_safety ). What should their conjunction Cpark_all_viewpoints = Cpark ∧ Cpark_safety guarantee? If users respect the rules of usage (no cheating with tickets, no damaging), then all guarantees must be met. If, however, users do not cause damage but may cheat with tickets, then only the safety guarantees will be met. Viceversa, if users do not cheat with tickets but may cause damage, then only the functional guarantees will be guaranteed. The important point here is that functional and safety viewpoints must be kept autonomously, considering them jointly should not cause spurious interaction between them. Only necessary interactions should remain, corresponding to shared states, events or messages, between their respective contracts.
A. Today - Offering a Smooth Integration of Contract-Based System Engineering with AUTOSAR The metamodel underlying the CESAR reference technology platform has been carefully designed to support a seamless design flow from the derivation of high-level requirements of new automotive functions to the level of detailed application design defined as entry point in AUTOSAR’s design methodology. The key for this smooth integration has been laid by AUTOSAR itself, notably in the enforcement of the clean separation between application development on one side, and deployment to distributed target architectures, on the other side. This then enables to capitalize on all the benefits of a contract based design methodology, as long as they are above the scope of the AUTOSAR meta model, notably then methods related to improving the quality of initial requirements and handling complex designs. As to layered design, the joint landscape covered by CESAR and AUTOSAR can support such design levels at the systems-of-systems levels for Car2X applications, all phases for supporting the introduction of new automotive functions, down to the detailed design level. As pointed out in the previous section, such phases would build on established design processes and currently used design tools, where contracts and viewpoints care conservatively added as additional flavor to existing design methodologies. The handover to AUTOSAR will take place at the detailed design stage, where rich components can then be mapped to the AUTOSAR component model, providing the entry point for AUTOSAR’s design methodology. Following the AUTOSAR flow, system configurations and ECU configurations describe the detailed target hardware. We can then automatically extract from system and ECU configurations all information for performing real-time analysis. Vertical assumptions on the component level can be derived by back-annotation from the underlying target hardware. Alternatively, vertical assumptions can be seen as constraining the target architecture (regarding its timing characteristics) and can thus be used to constrain the design space for possible target architectures. Finally, when deploying components to ECUs, communications of the virtual functional bus are mapped to the inter-component communications on the physical architecture.
The next issue is of paramount importance, since it relates the subsystems requirements to the systems requirements: Question 2 (Composition): What is the meaning of assigning requirement documents to different subsystems? Contracts 1 and 2 are documents attached to the different subsystems (not including the “user”). The intent is that these subsystems will be composed to form the whole system. How to mirror the composition of subsystems into a corresponding composition of requirements documents? It should be clear that this new type of composition differs from the conjunction of requirements documents, for a same subsystem or component. Question 1 and 2 discussed in this section are fundamental. Still, to the best of our knowledge, they seem to be ignored in the current system design practice by both the designers and the certification bodies. The different questions raised in this section are further discussed in companion paper [3]. IV. AUTOSAR AND C ONTRACTS In this section, we use AUTOSAR as an industrial example of how to leverage contracts within an existing standard to extend it. 22
B. The Future - Integrating Contracts in AUTOSAR
View point
The current release is expressive enough to represent realtime contracts. Using the concept of timing chains, both endto-end deadlines as well as assumed response times for component execution and communication can be expressed. However, the current release was not designed for extensibility: there is no established notion of viewpoints and, hence, no anchor to easily migrate from the current setting to one supporting multiple viewpoints. As pointed out before, the decision as to which viewpoints should or should not be anchored is a business decision. However, given that ISO 26262 is about to become binding, we see the need for a systematic integration of the safety viewpoint. Since we anticipate the addition of a second viewpoint, it is at least worthwhile to weigh the costs for such additional viewpoint integration against the costs of introducing the concepts of viewpoints systematically. Doing so will ease their activation at times when other market factors such as powermanagement mandate their introduction. Specifically, we could use contracts for both the encapsulation of Basic SoftWare (BSW) modules and the characterization of communication services. An ISO 26262 compliant encapsulation would, for instance, distinguish between BSW modules that (1) contribute to safety ("safety mechanisms") and (2) those that could potentially impact system’s safety (by providing their failure propagation behavior). A typical example for (1) would be the function inhibition manager that maintains function inhibitions whenever, for instance, implausible outputs are generated. A typical example for (2) would be an error that occurs in the communication services or an error that is generated in communication H/W that impacts communication services. An additional use for contracts is to deal with compliance between functional safety, where functions, hazards and safety functions are kept in a (functional) model and safety of the AUTOSAR architecture instance guaranteeing that the AUTOSAR implementation - using given safety functions of the AUTOSAR architecture - indeed implements the identified functional safety concept.
Contract
+strongAssum pti on
+weakAssum ption
Ti mi ngDescri pti on
+guarantee
Assertion
TimingDescriptionEvent
ObservableEvent
Figure 5.
Conceptual meta-model for integrating contracts in AUTOSAR
becomes active on a software component) separate from the ones already defined in the timing extensions and allow multiviewpoint contracts to refer to both. Figure 5 depicts an excerpt of a conceptual meta-model for this intermediate solution. In the long-term it may be desirable to harmonize these event definitions, effectively merging them. D. AUTOSAR Model of an Adaptive Cruise Control Enriched by Contracts We illustrate the benefits of contract-based systems engineering in AUTOSAR by means of an example: an Adaptive Cruise Control (ACC). With this example we show how requirements can be refined to contracts and discuss the added value of those contracts for negotiations between OEM and suppliers. The components and their interfaces of the presented example are based on AUTOSAR Specifications R.4 2009. Note that the decomposition of the ACC is not part of the AUTOSAR standard, but is only used for clarification. With this example we will illustrate the use of vertical contracts, e.g., to specify the expected latency of the communication solution from a timing point of view or a failure hypothesis in terms of reliability. Figure 6 shows the integration of the ACC in the Chassis Domain as per AUTOSAR Specifications R.4 2009. SurrSnsr
CrsCtrlAndAcc
Vlc
ev3SW-Composition
C. An Approach for Integrating Contracts in AUTOSAR The AUTOSAR meta-model is defined as an UML [5] model. It consists of AUTOSAR templates providing the vocabulary that can be used by developers of AUTOSAR based systems. For example the Software Component Template26 provides all artifacts necessary for the definition of AUTOSAR software components. To integrate contracts supporting multiple viewpoints, we can use the mechanism of defining events that refer to elements of an underlying AUTOSAR model and provide syntax and semantics of a suitable contract specification language. that addresses multiple viewpoints. In an intermediate solution one may keep the introduction of new events (e.g. an event, denoting the point in time when a certain failure condition
ev1 ev2
…
ev4 VFB
ECU Abstraction
Figure 6.
Integration of the ACC in System-Composition (system view)
1) SW-composition CrsCtrlAndAcc: This SWComposition shown in Figure 7: specifies the ACC. It controls the velocity of the vehicle and its distance to other vehicles in front of itself (the ego-vehicle). The real interface names and ports have been abstracted for the sake of brevity. The DelegationSwConnectors model the delegation of the outer ports of a composition to ports of components being parts of that composition. The AssemblySwConnectors
26 See http://www.autosar.org/index.php?p=3&up=1&uup=0, AUTOSAR Specifications R.4 2009.
23
CrsCtrlAndAcc SW-Composition
ev1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000000000000000000000000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0SurrndgsSnsr 0000000000000000000000000000000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SnsrDa 0 0 0 0 0 0 0Sensor 0000000000000000000000000 00000000000000000000000000000000 ProcGen 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000000000000000000000000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000000000000000000000000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000000000000000000000000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000000000000000000000000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000000000000000000000000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Complex 00000000000000000000000000000000 00000000000000000000000000000000 00 00 00Hardware 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Device 00000000000000000000000000000000 Driver 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000000000000000000000000000
Figure 7.
(Powertrain) Epb ....
ev7
Supplier
only be guaranteed under assumptions about the triggeringfrequency. Corresponding contract C1 is shown on Table III. The strong assumption specifies a periodic activation (denoted
ev2 Esc
CrsCtrlAndAccStCtrl
(HMI)
ev8 ev5
Esc
ev6
strong assumption: weak assumption: guarantee:
FolwCtrlAndAArbn
ev3
AccObj TarSeln
ev4 ev9
Vlc
ev3 occurs each 500ms with jitter 50ms true delay between ev3 and ev4 within [0ms,200ms]
CrsCtrlFree
Table III C ONTRACT C1 FOR C R S C T R L A N D A C C . T ERMS IN BOLDFACE ARE KEYWORDS OF A PATTERN - BASED LANGUAGE TO SPECIFY CONTRACTS .
…
CrsCtrlAndAccObsvrForVehSt
(Powertrain) Esc Epb ....
by ev3) while the guarantee concerns the end-to-end latency. This end-to-end latency must then be budgeted among the components involved in the composition, for separate implementation by suppliers. The weak assumption is true, which means the context characterized by the strong assumption has not been further refined here.
ACC as the SW-composition CrsCtrlAndAcc
link the ports of parts of a composition and are subject to communication refinement. The components used in the composition and their functions are as follows (evx denotes an observable event): • AccObjTarSeln selects target objects (e.g. aheadmoving vehicles) that are necessary for the ACC to control the velocity of the ego-vehicle and its distance to vehicles in front of it. • CrsCtrlFree controls the acceleration of the egovehicle depending on the set speed of the driver. • FolwCtrlAndAArbn controls the acceleration of the egovehicle depending on the selected target objects. 27 • CrsCtrlAndAccStCtrl provides the control mode of the system and its status. It also determines the state of the ACC according to the HMI inputs and the pedals (acceleration and brake) pressed by the driver (ev2). The outputs (set speed and time gap) go to the follow and free cruise controllers (ev7). 28 • CrsCtrlAndAccObsvrForVehSt provides information about the ego-vehicle, e.g., its speed, steering wheel angle, and curvature of its predicted path. Non-functional properties of the ACC can be specified by means of contracts. In the ISO2002 standard29 performance requirements on an ACC are specified. The latter could serve as input for such contracts. For example, referring to Figure 7, the time gap — the time required to travel the distance between the ego-vehicle and the forward vehicle — is refined into a latency requirement constraining the time between the reception of a new sensor sample (ev3) and producing a corresponding acceleration value (ev4). As this required latency depends on many factors like the mass of the vehicle, the used sensors, polling frequency, other ACC design parameters, we simply assume a fictitious value of 200ms here. For system integration this becomes part of an endto-end latency involving the components connected to the CrsCtrlAndAcc composition (cf. Figure 6). The latency can
2) Sub-contracting: CrsCtrlAndAccStCtrl and CrsCtrlAndAccObsvrForVehSt have the widest interface to other domains and would ideally be developed by the OEM to ensure proper system integration of the SW-composition CrsCtrlAndAcc. The follow cruise control, the free cruise control, their arbitration and connection to sensor(s) are encapsulated as components, for implementation by suppliers. In a time budgeting process involving OEM and supplier(s) the latency requirement of 200ms is decomposed into smaller slots allocated to the different components involved in the composition. The choice of how the timing requirement is decomposed can be done on estimated figures from previous projects. 3) Vertical Assumptions on Software Components: Figure 8 shows the internal behavior of component AccObjTarSeln.
AccObjTarSeln
Internal Behavior
ev10
ev11 MainRunnable
dataReadAccess
ev3
Figure 8.
This
dataWriteAccess
ev5
Internal behavior of AccObjTarSeln-component
component
consists
of
a
single
runnable
MainRunnable, which reads the sensor values available at its
27 Cruise
Control and ACC State Machine Control and ACC Vehicle State Observer 29 http://www.iso.org/iso/catalogue_detail?csnumber=31169
required Sender/Receiver port and provides information about the selected target object on its provided Sender/Receiver
28 Cruise
24
strong assumption:
port. The depicted events refer to an observable behavior of the AccObjTarSeln component. The following events are involved: • Event ev3 denotes the reception of a data on the required Sender/Receiver port of the AccObjTarSelncomponent. This data is then available in the communication buffer of the RTE. • Event ev10 denotes the start of MainRunnable, which is part of the InternalBehavior of the AccObjTarSelncomponent. • Event ev5 denotes the point in time the AccObjTarSeln-component has successfully sent out the selected target object on its provided Sender/Receiver port. • Event ev11 denotes the termination of MainRunnable, which is part of the InternalBehavior of the AccObjTarSeln-component. Figure 9 shows that some segments of the control flow from ev3 to ev5 cannot be guaranteed by the provider of the SWcomponent without knowing the system configuration. She can only specify that MainRunnable shall be triggered when a data element is received at the required Sender/Receiver port by means of RTEEvents and that MainRunnable will send a data item on its provided Sender/Receiver port, e.g. by means of dataWriteAccess.
weak assumption: guarantee:
Table IV C ONTRACT C2 FOR COMPONENT A C C O B J T A R S E L N .
AccObjTarSeln are mapped to the same ECU, the vertical
assumptions of timing contracts can be established by means of schedulability analysis. That analysis would reveal the response times, which need to fulfill the vertical assumptions. The vertical assumptions (the 2nd and 3rd strong assumptions) of contract C2 can be used to constrain possible ECU configurations in advance. Figure 10, top, sketches a possible outcome of such an ECU configuration design step. The components SurrSnsr and AccObjTarSeln are integrated on the same ECU and their Runnables are mapped to tasks of the OSEK operating system. Especially R1 is mapped to the same task as MainRunnable and will be executed first. The analysis has to prove that under the given scheduling strategy this task has a response time of less than 55ms in order to establish the 2nd vertical assumption of C2 . Further it must be ensured that it takes at most 55ms from the point in time data is available at the RTE (denoted by ev3) until the task hosting MainRunnable is activated (denoted by ev10).
Task COM
Main Runnable
RTE
RTE gluecode
Rte_COMCkb
Other Runnable
Com_ReceiveSignal E_OK
Activate an OSEK Task
Runnable
4) Vertical Assumptions on AssemblySwConnectors: Figure 10, bottom, shows the possible outcome of a system configuration step. The topology includes two ECUs, which are connected via a Bus (e.g. CAN). The components AccObjTarSeln and FolwCtrlAndAArbn, whose ports were directly connected in the CrsCtrlAndAcc composition (see Figure 7), are now mapped to different ECUs. Their connection is mapped onto ISignals, which are handled by the Com module and packed into I-PDUs (Interaction layer Protocol Data Unit), which in turn may be segmented and reassembled by a transport layer module and finally passed to the bus driver for transmission in a frame. The configuration of that communication stack is specified by means of a “communication matrix” defined as part of the system configuration.
ev10 Main Runnable
MainRunnable
ev3 ev5 ev10
Figure 9.
ev11
ev3 occurs each 500ms with jitter 100ms delay between ev3 and, ev10 within [0ms,55ms] delay between ev10 and, ev11 within [0ms,55ms] true delay between ev3 and, ev5 within [0ms,120ms]
ev5
ev11
Observable events in the BSW-modules COM, OS and the RTE
However the time from ev3 to ev10 depends on the RTE, the RTOS, and their configuration. For example there might be a second Runnable that is mapped to the same OSEK task (see Figure 9) and is executed by it prior to MainRunnable. This would extend the latency between ev3 and ev10 by at least the execution time of the other runnable. In addition the underlying OSEK task may be preempted by other OSEK tasks with higher priority. Thus, the latency between ev10 and ev5 also depends on the ECU configuration. If implementations of the involved components already exist for particular ECUs, those latencies can be obtained by analysis and formulated as vertical contracts. Table IV shows the resulting vertical contract C2 for component AccObjTarSeln. When the ECU is configured components in addition to
With regard to the latency requirements specified in the system view (see Figure 6), there must be vertical assumptions on each AssemblySwConnector. Thus contract C1 of Table III should actually be enriched by vertical assumptions, thus resulting in the contract C10 shown on Table V, top. If the framework used for contracts supports contract conjunction, we can instead consider contract Ce1 shown on Table V, bottom, and then get C10 = C1 ∧ Ce1 . This alternative way favors modularity in the design and is thus preferred. 25
strong assumption:
ECU1 SurrSnsr R1
C10 :
AccObjTarSeln
… MainRunnable
ev5
ev3
strong assumption: Ce1 :
RTE1 Standard IF
OSEK OS
ECU Abstraction
weak assumption: guarantee:
Com
weak assumption: guarantee:
ev3 occurs each 500ms with jitter 50ms delay between ev5 and, ev6 within [0ms,80ms] true delay between ev3 and, ev4 within [0ms,200ms] delay between ev5 and, ev6 within [0ms,80ms] true true
Table V C ONTRACTS C10 ( TOP ) AND Ce1 ( BOTTOM ).
Standard IF
… Standard IF
Standard IF
BSW1
MCAL
CAN-Drv
ECU Hardware
: Dataflow in BSW-Stack : Runnable to task mapping ECU1
ev3
FolwCtrlAndAArbn
ev5
ev6
…
{Double_Fault} does not occur. true {Undetected_fail(Vlc_out)} does not occur.
C4 :
strong assumption: weak assumption: guarantee:
{fail(HMI_in)} does not occur. true {fail(Vlc_out)} does not occur.
C5 :
strong assumption: weak assumption: guarantee:
{fail(valid)} does not occur. true always(valid == 0 → fail(Vlc_out))
Table VI C ONTRACTS C3 ( TOP ) AND REFINED CONTRACTS : C4 AND C5 .
RTE2 Standard IF
BSW1
…
ev4
RTE1
…
strong assumption: weak assumption: guarantee:
ECU2
AccObjTarSeln
…
C3 :
Standard IF
Com
Com
Standard IF
Standard IF
Standard IF
Standard IF
CAN-Drv
CAN-Drv
ECU Hardware
… …
measures and failure propagation rules. We already demonstrated the use of contracts for handling time budgets and pinning down timing assumptions about ECU and system configuration by means of vertical contracts. In the same manner allocations to hardware components and the resulting propagation of hardware failures can be part of the safety specification. Figure 11 depicts a small part of the ACC system described earlier with an added component Monitor. The corresponding contracts can be found in table VI. In this example the connection between failure modes, counter measures and allocations shall be demonstrated. Contract C3 is attached to component CrsCtrlAndAcc and represents the safety goal that no undetected failure of the component can occur under the assumption that only one failure may occur. Contract C4 is attached to component FolwCtrlAndAArbn and clarifies the failure propagation of the component. In this case no design failure of the component is considered to keep the example simple. The contract states a typical propagation. If there is no failure on the input ports, then there is also no failure at the output ports. Contract C5 specifies the Monitor component which has been added to the ACC system in order to have a counter measure. The monitor gets the input and output of the FolwCtrlAndAArbn component and detects failure in the calculation. There are hardware faults assigned to each ECU (contracts not stated here). In Figure 11 two possible allocations are depicted. Mapping the two components to the same ECU
BSW2 ECU Hardware
Bus : Dataflow in BSW-Stack and on the Bus
Figure 10. ECU configuration with mapping of Runnables (top) and SystemConfiguration showing the refinement of AssemblySwConnectors (bottom).
E. Using Contracts for Safety Specification Contracts have already been introduced as an harmonic extension to AUTOSAR from the process point of view at the beginning of this chapter. Furthermore the possibility of expressing timing behavior has been demonstrated. Driven by the need for compliance to the upcoming ISO26262 standard, the safety aspects, especially with respect to contract based specification, gained attention. The ISO26262 does not only require comprehensive checking of requirements but rather states explicitly the need for using assumptions on the environment to develop a safety relevant element on the supplier side (safety element out of context). This fact manifested in a concept for extending the AUTOSAR methodology and templates to directly integrate contracts for safety property specification. Besides the obvious interest in enabling reasoning on assumptions the focus is also on supporting a wide range of safety analysis like FTA or safety-completeness from the AUTOSAR templates without having to rely on external sources storing requirements and functionality of used counter 26
components. The difficulty in doing so resides in the need of developing the notion of contracts for continuous-time systems.
CrsCtrlAndAcc SW-Composition
HMI_in
Vlc_out
FolwCtrlAndAArbn
A. Analog Circuit Design: Why Are Contracts Important? Monitor
« « «
«
«
Figure 11.
Monitor
Monitor
FolwCtrlAndAArbn
ECU1
« « «
«
«
12
valid
ECU2
FolwCtrlAndAArbn
ECU1
Analog, mixed-signal, and RF (AMS-RF) components are indispensable parts of many integrated Systems-on-Chip (SoCs). Integration and verification of these blocks in the complete system is the bottleneck in terms of design time and required resources. As both Non-Recurring Engineering (NRE) costs and demands on quick product cycles continue to increase, AMS-RF design productivity must be improved. In particular, structured and rigorous design methodologies at higher levels of abstraction should be developed to overcome complexity and take advantage of design reuse. To address this problem, analog platform-based design (APBD) was introduced in [11], [13] (see Section II-G) as a meet-in-the-middle approach for fast and reliable design space exploration at the system-level. Circuit components are first built and characterized bottom-up by exporting high-level behavioral and performance models. System functionalities are independently specified and propagated top-down as constraints on the library of pre-characterized component models. Systems are optimized leveraging global tradeoffs among all components, while ensuring implementation feasibility at the circuit level. In [33], [32], contracts were introduced into the design flow to ensure predictable component behavior after integration into the system, by accounting for the external interface effects on circuit performances. Circuits are constrained to operate under the same environment as in the assumptions made during characterization, so that their behavior in the system is as close as possible to the one predicted by the component models. Component-level contracts are horizontal since they are enforced among components at the same abstraction level to guarantee the validity of their composition. When composing parts described by integrodifferential equations as analog circuits, the difficulty is that the behavior of each of the components is affected by the presence of the other in a substantial way (loading effect) given the lack of the robustness provided by the digital abstraction: in analog circuits waveforms are essential. Hence, the horizontal contracts have to be carefully defined. Their role is to establish the limits on the interface variables of a component so that the behavior of the component is within what was expected by the designer. The contracts then will be defined themselves in general as integro-differential equations and inequalities. Horizontal contracts are not sufficient, in general, to guarantee that the system behaves as specified at higher abstraction levels. They are intended to make sure that the components maintain their behavior. We need additional constructs to capture the fact that system architects introduce requirements to craft the behavior of a chosen architecture according to the desired functionality. Further, at different design stages, more knowledge about the system is gained, and additional information is incrementally accumulated to refine the system
Extract of ACC System
would result in an error during the completeness analysis since the promise that no undetected error can occur would be violated by the occurrence of the hardware failure of the ECU both component are mapped to. An allocation to two separate ECUs would create a successful completeness analysis result. With regard to the underlying failure model, contracts can be translated to various formal representations and verified by model checking or SAT engines. F. Summary and discussion We have proposed a smooth path for integrating contracts in the context of AUTOSAR at the level of detailed design. We believe that the main aspects for consideration while introducing contracts are the handling of time budgets and the specification of failure modes and failure propagation. We did not consider the functional aspect as we think that the OEM would subcontract subsystems to different suppliers only if they are loosely, not tightly, coupled from the functional point of view. Vertical contracts were instrumental in handling time budgets. Such contracts relate two different layers of the AUTOSAR framework. The safety aspect with its designtime part (reliability analysis) and run-time part (On-Board Diagnosis, OBD2) can be handled using the same philosophy. Of course, this use of contracts at the level of detailed design could be complemented with a use of them at the early phase of requirements capture, following the parking garage example of Section III. V. C ONTRACTS AND A NALOG M IXED -S IGNAL C IRCUIT D ESIGN In this section, we address how to use contracts for assembling analog integrated systems out of pre-designed analog 27
within the margins δ, where δ defines the assumption ranges. 2) gi is the set of all (y,x) ∈ Y×X , such that aδi |= A =⇒ P(gi ) = 1, that is, if aδi satisfies A, then gi is contained in the AP performance feasibility model. Clearly, gi can be also computed by directly executing the behavioral model under the condition aδi |= A. To guarantee that models and compositions are valid, all AP assumptions must be satisfied for all components. In particular, only compatible components can be composed to construct a higher level AP. While we direct interested readers to [33] for a formal definition of compatible components30 we say informally that two AP components are compatible if there exists a set of values for their input, output and internal variables that satisfy the assumptions of both components and follow their behavioral and performance feasibility models. However, composition is not, in general, commutative, as also discussed in [33]. The set of all compatible component configurations form the compatible regions for the APs during composition, which are the valid search spaces to explore while ensuring that APs remain valid after system construction. b) Vertical Contracts: System-level assumptions may result from several modeling and architectural decisions made by system architects. As pictured in Figure 13, the desired behavior of the system, as dictated by specifications, can already be translated into a set of constraints, both equalities and inequalities, which are independent of any architecture. As soon as an architecture is chosen for exploration, the specification constraints are further translated into constraints on the selected architecture and its underlying components. At this stage, the architect may already make assumptions to bound the behavior of the chosen architecture to capture the desired specifications. As a first step, when no feasibility constraints (vertical bottom-up contracts) are propagated bottom-up, idealized models may be assumed for the components. However, an experienced designer could already anticipate and account for possible undesired behaviors or non-idealities, such as loading effects, unwanted signal paths and coupling. Additional assumptions can then be made this time to minimize the impact of undesired behaviors on the overall system. Finally, there is clearly a tradeoff between the number of effects accounted for in a model and its computational complexity. Therefore, assumptions might also be needed to reduce the complexity of the system macro-model used for high-level simulation and design exploration, which otherwise may be too computationally expensive to evaluate or too complex to offer intuitive insights. As a result, several assumptions are aggregated incrementally during the system-level specification refinement process. We define these assumptions as system-level assumptions, and
behavior into the desired function. These are top-down vertical requirements. When verifying the behavior of mixed-signal systems consisting of several potentially complex components, detailed models at the transistor level are very difficult to analyze and simulate. Indeed, experienced designer use simplified macromodels that are intended to capture the relevant behavior of the components at higher level of abstraction. In a rigorous design methodology, we would like to have guarantees on the accuracy of the macro-models with respect to models at lower levels of abstraction. The conditions under which the higher level models are ’faithful’ with respect to the lower level models can be captured by vertical bottom-up contracts. In the following sections, we define more precisely what we described above albeit we refer the interested readers for details to [13], [32]. B. Analog Platform-Based Design and Contracts In APBD, circuits and systems are represented as Analog Platforms. Definition 1: An Analog Platform (AP) consists of a collection of: • Variables: inputs u ∈ U; outputs y ∈ Y; internal signals x ∈ X ; and configuration parameters κ ∈ K. • Behavioral model: F(u, y, x, κ) = 0, which is a set of integro-differential equations representing the desired behavior of the component. • Performance feasibility model : P(y, x) = 1 ⇔ ∃κ, u, (y, x) = φy (κ, u) where the classifier P(y, x) denotes the feasible performance space [12] and φy denotes the mapping obtained by solving the behavioral model with respect to the output and internal variables, also called the performance mapping. This mapping can be computed for a given value of κ and u by a numerical solver, e.g., a circuit simulator. • Assumptions: A(u, y, x, κ, δ) ≤ 0, which is a set of constraints on the variables of the AP for which both behavioral and performance models are guaranteed to be valid within a set of tolerable margins δ ∈ D. An AP model is defined to be valid when all assumptions are satisfied, which guarantees the model outputs correspond to the actual circuit performance within a tolerance dictated by δ. a) Horizontal Contracts: Given a set of AP components at level l, systems can be composed and represented as APs at level l+1, which themselves are components for a higher-level. Contracts help ensure component validity during composition and are defined as follows. Definition 2: A horizontal contract C for an AP component is a set of assume/guarantee tuples {ci = (aδi , gi ) : i = 1, . . . , N } where for each i, 1) aδi is the set of vectors (u,y,x,κ) ∈ U ×Y×X ×K, that satisfies assumption constraints A of the AP component
30 In [33], compatible components are called consistent components. We changed the terminology here, from ’consistent’ and ’consistency’ to ’compatible’ and ’compatibility’, to align with the definitions developed in the SPEEDS contracts [1]
28
we represent them as a set AS in Figure 12. AS is then the set of vectors (uS ,yS ,xS ,κS ) ∈ US ×YS ×XS ×KS , that satisfies the system-level assumptions within system margins δS , where uS and yS are the system input and output variables, xS are the system internal variables and κS denotes the system configurations. In APBD the final design is obtained via mapping of the desired specification onto an implementation space made up of the pre-characterized AP components [13]. Mapping is cast as an optimization problem, where a set of performance metrics and quality factors are optimized over a space constrained by both system requirements and component feasibility constraints. Therefore, to ensure that correct systems are constructed, AS need to be considered during the optimization phase. In this presentation, we include the effect of system-level assumptions by propagating back AS onto the components and their pre-existing horizontal contracts. This “vertical propagation” step for AS is pictorially represented in Figure 12. Let AC be the set of all satisfying vectors for the component-level assumptions, and, similarly, GC be the set of all guarantees of a component. Moreover, let A0C and G0C be the compatible assume and guarantee subsets. When AS is projected onto the space of the component parameters, it generates an additional assumption set A0S . As discussed above, system-level assumptions may be defined in a somewhat independent fashion with respect to component-level assumptions, so that simply satisfying the consistency conditions of the component-level contracts A0C is not, in general, sufficient to satisfy A0S . A0C needs to be intersected with A0S and only configurations in A00C = A0C ∩ A0S , will guarantee both a valid composition and the desired system behavior. In fact, if G00C is the set of guaranteed component behaviors under the assumptions A00C , G00C ⊆ G0C will necessarily hold by definition of contracts, and the final composition will be correct. By projecting back A00C and G00C up to the system-level, we generate the new system-level contract as the tuple (A00S ,GS ) where A00S and GS are obtained from A00C and G00C , respectively, after projection. The newly generated system-level contract can then be used for compositions at higher abstraction levels thus enabling hierarchical system construction.
A"s
System-Level Contract
As
Ac
A'c
Select Sample Configurations
Select System Architecture
Define Component Assumptions
System Design Optimization
Component Model Simulate
Characterize Model
System Model
Optimized System Configuration
Component Characterization
Design Validation
Figure 13.
Define System Behavior
Define System Assumptions
System Modeling
APBD Design Flow
As shown in Figure 13, in the APBD design flow component design and characterization is completely orthogonalized from system specification and architectural design. AP components are built bottom-up satisfying vertical bottomup contracts to provide component models to a system-level optimization engine. On the other side, system constraints capturing the desired specification are propagated top-down, possibly associated with more abstract system-level behavioral models via vertical top-down constraints. The optimization phase leverages information from both the system and the component levels to evaluate global tradeoffs among components, while respecting the physical constraints dictated by the performance feasibility models of the AP components (horizontal contracts). The optimized results are then passed to a validation stage, where the design is verified against electrical simulations. We validated our methodology by using it to optimize a Sallen-Key base-band filter for UWB applications. Circuitlevel simulation results show that the constructed systems closely matches the desired behavior at the system-level, with an average error reduction of 10% for base-band gain and 60% for filter bandwidth, when compared with systems constructed without accounting for system-level assumptions. Moreover, the system design could be efficiently configured to satisfy various specification sets with high accuracy, which makes our approach suitable to design reuse.
Gs
In this paper, we introduced the concepts underlying Contract-Based Design and its use in a variety of scenarios. In particular, we presented the challenges facing facing designers of large-scale complex systems today. Then we reviewed the design methodologies and design concepts so far used to address these challenges (viewpoints, layered design, component-based design, the V-model of design, model-based development, virtual integration, platform-based design) and showed how contracts can be used in all these approaches to enhance their applicability and the quality of the final result. Finally, we examined three examples of the use of contracts:
G"c G'c A's
Figure 12.
System Specification
Component Design
VI. C ONCLUDING R EMARKS
A"c
Assume Set
C. Contract-Based Design Flow
Component-Level Contract
Gc Guarantee Set
Vertical Propagation of System-level Contracts
29
one simple example to underline the key steps of contractbased design, one about the use of contracts in enhancing and extending the AUTOSAR automotive standard and one related to analog-mixed signal integrated circuit design. In this paper, central to contracts was the distinction between assumptions and guarantees, mirroring the different roles and responsibilities in the design of systems. In concluding this section, we advocate the need for a mathematically sound theory underpinning the use of contracts in terms that are more general than the assumption-guarantee form of contracts to provide solid, unambiguous bases for contract-based design tools and methods. In fact, we strongly believe that any methodology and tool set MUST be based on solid theoretical foundations to be universally usable and long lasting. In the companion paper [3] we formalize the requirements for contract theories and present some candidate theories that satisfy in full or partially the requirements.
[16] R. Glabbeek and W. P. Weijland. Branching time and abstraction in bisimulation semantics. Journal of the ACM, 43(3):555–600, 1996. [17] C. Haerdt and A. Keis. A. model-based integration of analysis services: Experiences with an analysis dashboard. In 3rd Workshop on ModelDriven Tool and Process Integration, 2010. [18] David Harel, Hillel Kugler, Rami Marelly, and Amir Pnueli. Smart play-out of behavioral requirements. In FMCAD, pages 378–398, 2002. [19] David Harel and Rami Marelly. Come, Let’s Play: Scenario-Based Programming Using LSCs and the Play-Engine. Springer-Verlag, 2003. http://www.wisdom.weizmann.ac.il/∼harel/ComeLetsPlay.pdf. [20] David Harel and Itai Segall. Planned and traversable play-out: A flexible method for executing scenario-based programs, . In TACAS, pages 485– 499, 2007. [21] INCOSE. Incose systems engineering handbook, 2010. http://www. incose.org/ProductsPubs/products/sehandbook.aspx. [22] S. Karris. Introduction to Simulink with Engineering Applications. Orchard Publications, 2006. [23] Y. Kesten, N. Piterman, and A. Pnueli. Bridging the gap between fair simulation and trace inclusion. Information and Computing, 200(1):35– 61, 2005. [24] H. Kopetz. Composability in the time-triggered architecture. SAE International Congress and Exhibition (2000-01-1382), Detroit, MI, USA, 6-9 March 2000, March 2000. [25] Object Management Group (OMG), . A UML profile for MARTE, beta 1. OMG Adopted Specification ptc/07-08-04, OMG, August 2007. [26] Object Management Group (OMG), . System modeling language specification v1.1. Technical report, OMG, 2008. [27] The Design Automation Standards Committee of the IEEE Computer Society, editor. 1850-2010 - IEEE Standard for Property Specification Language (PSL). IEEE Computer Society, 2010. [28] J. Hudak P. Feiler, D. Gluch. The Architecture Analysis and Design Language (AADL): An Introduction. Software Engineering Institute (SEI) Technical Note, CMU/SEI-2006-TN-011, February 2006. [29] Roberto Passerone, Luca de Alfaro, Thomas A. Henzinger, and Alberto Sangiovanni-Vincentelli. Convertibility verification and converter synthesis: Two faces of the same coin. In Proceedings of International Conference on Computer Aided Design, San Jose, CA., 2002. [30] R. Sudarsan and S.J. Fenves and R.D. Sriram and F. Wang. A product information modeling framework for product lifecycle management. Computer-Aided Design, 37:1399–1411, 2005. [31] A. Sangiovanni-Vincentelli, S. Shukla, J. Sztipanovits, G. Yang, and D. Mathaikutty. Metamodeling: An emerging representation paradigm for system-level design". Special Section on Meta-Modeling, IEEE Design and Test,, 26(3):54–69, 2009. [32] X. Sun, A. Puggelli, P. Nuzzo, and A. Sangiovanni-Vincentelli. Vertical propagation of system-level contracts in analog platform-based design. submitted for publication, 2010. [33] Xuening Sun, P. Nuzzo, Chang-Ching Wu, and A. SangiovanniVincentelli. Contract-based system-level composition of analog circuits. In Proceedings of 2009 Design Automation Conference, pages 605 –610, jul. 2009.
R EFERENCES [1] Albert Benveniste and Benoît Caillaud and Alberto Ferrari and Leonardo Mangeruca and Roberto Passerone and Christos Sofronis. ContractBased Specification and Design, 2008. submitted. [2] F. Balarin, H. Hsieh, L. Lavagno, C. Passerone, A. L. SangiovanniVincentelli, and Y. Watanabe. Metropolis: an integrated electronic system design environment. Computer, 36(4), 2003. [3] A. Benveniste, J.B. Raclet, B. Caillaud, D. Nickovic, R. Passerone, T. Henzinger, and Larsen K. Contracts and Interfaces for the Design of Embedded Systems; Part II: theory. Proceedings of the IEEE, 2011. companion paper. [4] Gerard Berry. The effectiveness of synchronous languages for the development of safety-critical systems. White paper, Esterel Technologies, 2003. [5] G. Booch, I. Jacobson, and J. Rumbaugh. The Unified Modeling Language User Guide. Addison-Wesley, 1998. [6] M. Broy. Compositional refinement of interactive systems. Journal of the ACM, 44(6):555–600, November 1997. [7] Henning Butz. The Airbus approach to open Integrated Modular Avionics (IMA): technology, functions, industrial processes and future development road map. In International Workshop on Aircraft System Technologies, Hamburg, March 2007. [8] Werner Damm. Controlling speculative design processes using rich component models. In Proceedings of 5th International Conference on Application of Concurrency to System Design (ACSD), 2005. [9] Werner Damm, Angelika Votintseva, Alexander Metzner, Bernhard Josko, Thomas Peikenkamp, and Eckard Böde. Boosting reuse of embedded automotive applications through rich components. In Proceedings of FIT 2005 - Foundations of Interface Technologies, 2005. [10] Abhijit Davare, Douglas Densmore, Trevor Meyerowitz, Alessandro Pinto, Alberto Sangiovanni-Vincentelli, Guang Yang, and Qi Zhu. A next-generation design framework for platform-based design. In Design Verification Conference (DVCon), San Jose’, California, 2007. [11] F. De Bernardinis, S. Gambini, R. Vincis, F. Svelto, A. SangiovanniVincentelli, and R. Castello. Design space exploration for a umts frontend exploiting analog platforms. In ICCAD ’04 Proceedings, pages 923–930, 2004. [12] F. De Bernardinis, M. I. Jordan, and A. Sangiovanni-Vincentelli. Support vector machines for analog circuit performance representation. In DAC ’03 Proceedings, pages 964–969, 2003. [13] F. De Bernardinis, P. Nuzzo, and A. Sangiovanni-Vincentelli. Mixed signal design space exploration through analog platforms. In DAC 2005 Proceedings, pages 1390–1393, 2005. [14] Johan Eker, Jörn W. Janneck, Edward A. Lee, Jie Liu, Xiaojun Liu, J. Ludvig, Stephen Neuendorffer, S. Sachs, and Yuhong Xiong. Taming heterogeneity - the ptolemy approach. Proc. of the IEEE, 91(1):127–144, 2003. [15] Peter Fritzson. Principles of Object-Oriented Modeling and Simulation with Modelica 2.1. Wiley, 2003.
30
