Handling Mixed-Criticality in SoC-based Real-Time Embedded Systems ∗ Rodolfo Pellizzoni, Patrick Meredith, Min-Young Nam, Mu Sun, Marco Caccamo, Lui Sha University of Illinois at Urbana-Champaign Urbana, IL 61801-2302 {rpelliz2, pmeredit, mnam, musun, mcaccamo, lrs}@illinois.edu ABSTRACT System-on-Chip (SoC) is a promising paradigm to imple- ment safety-critical embedded systems, but it poses signifi- cant challenges from a design and verification point of view. In particular, in a mixed-criticality system, low criticality applications must be prevented from interfering with high criticality ones. In this paper, we introduce a new design methodology for SoC that provides strong isolation guaran- tees to applications with different criticalities. A set of cer- tificates describing the assumed application behavior is ex- tracted from a functional Architectural Analysis and Design Language (AADL) specification. Our tools then automati- cally generate hardware wrappers that enforce at run-time the behavior described by the certificates. In particular, we employ run-time monitoring to formally check all data com- munication in the system, and we enforce timing reservations for both computation and communication resources. Verifi- cation is greatly simplified because certificates are much sim- pler than the components used to implement low-criticality applications. The effectiveness of our methodology is proven on a case study consisting of a medical pacemaker. Categories and Subject Descriptors B.4.3 [Input/Output and Data Communications]: In- terconnections (subsystems); D.2.2 [Software Engineer- ing]: Design Tools and Techniques General Terms Design, Reliability, Verification 1. INTRODUCTION Systems-on-Chip (SoCs) are increasingly popular in the embedded system domain because they consume less power ∗ This material is based upon work supported by Lock- heed Martin, John Deere and NSF under Awards No. CNS0720702, CNS0720512, CNS0613665. Any opinions, findings, and conclusions or recommendations expressed in this publication are those of the authors and do not necessar- ily reflect the views of the NSF or the supporting companies. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. EMSOFT’09, October 12–16, 2009, Grenoble, France. Copyright 2009 ACM 978-1-60558-627-4/09/10 ...$10.00. and cost less money than the multi-chip solutions they re- place. We believe that the SoC paradigm is especially promis- ing for safety-critical embedded systems such as those em- ployed in the medical market [35]: it is easier to formally verify the correctness of critical functionalities when they are implemented in hardware rather than in software on top of an OS and library stack [4]. Furthermore, SoC design can offer higher hardware reliability. However, implementing safety-critical applications on SoC brings additional design challenges. The high degree of in- tegration possible in modern fabrication processes can eas- ily lead to mixed-criticality systems : multiple applications with different criticalities run simultaneously on the same chip. The goal of a safe design is to prevent safety-critical applications from failing; low-criticality applications can be allowed to fail, albeit it is undesirable. As an example, con- sider a medical pacemaker (a more detailed description can be found in Section 3). Implanted cardiac pacemakers are used to provide pacing assistance for patients with slow or abnormal heart rates. The life-critical pacing component uses leads to send shocks to the heart to force contraction. However, modern pacemakers also implement a variety of other applications such as data logging and remote commu- nication and programming that are used for diagnosis. Un- fortunately, formally verifying and/or certifying these non safety-critical applications is either extremely expensive or unfeasible: they typically make large use of both software and hardware Intellectual Properties (IP) such as CPU cores and OSes that are very complex. As such, they must be al- lowed to fail. The problem is that low-criticality modules must communicate with the life-critical module and share physical resources such as battery energy, memory and com- munication bandwidth; therefore, faults can propagate from a lower to a higher criticality application, making the whole system unsafe. In this paper, we introduce a new design methodology for SoC that specifically targets mixed-criticality systems. Our methodology provides strong isolation guarantees to appli- cations and imposes limits to fault propagation. In detail, we distinguish between functional isolation, which deals with the correct exchange of data, and physical isolation, which deals with the correct sharing of system resources. Our methodology is similar to the concept of Platform-Based De- sign (PBD) [29]. A platform is a library of (usually para- metric) components. A platform instance is a set of library components selected to generate a concrete design. In a PBD design flow, the designer first specifies the system func- tionality using an implementation-independent description language. The designer then selects a suitable platform and performs mapping of functional elements to platform com- ponents, thus creating a platform instance. Our platform contains three types of architectural components: proces-