DOCSLIB.ORG

Selection and Evaluation of an Embedded Hypervisor: Application to an Automotive Platform

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Selection and Evaluation of an Embedded Hypervisor: Application to an Automotive Platform Selection and evaluation of an embedded hypervisor: application to an automotive platform Etienne Hamelin∗, Moha Ait Hmid∗, Amine Najiy, Yves Mouafo-Tchindaz ∗CEA, LIST (email: [email protected]) yJaguar Land Rover (email: [email protected]) zContinental (email: [email protected]) Abstract—This paper presents a methodology for selecting an criteria and then evaluating the candidates, especially when embedded hypervisor for embedded applications consolidation, non-technical and subjective criteria are in balance with based on qualitative and quantitative criteria, then describes technical ones. how this methodology is applied to the construction of an This paper proposes a methodological selection process, automotive hardware and software platform. applicable to many embedded system domains, and presents its successful application to the selection of a hypervisor for 1. Introduction a new automotive computing platform. The advent of multi/many-core SoCs in embedded sys- 2. Related work tems enables the execution of multiple software applica- tions on the same integrated circuit, possibly with very Several works address hypervisor evaluation and com- different requirements in terms of performance, security, parison. We can cite Patel et al [2] who present the open safety criticality, and lifecycle management. The realization source embedded hypervisor Xvisor and compare it against of the full potential of such platforms involves the use of two of the commonly used hypervisors KVM and XEN ac- multiple software computing domains, often managed by cording to factors that affect the whole system performance. different operating systems, on the same physical device. Experimental results on ARM architecture prove Xvisor’s To host a diversity of software computation payload, either lower CPU overhead, higher memory bandwidth, lower lock a hardware or a software solution can be considered. The synchronization latency and lower virtual timer interrupt hardware solution consists in dedicating to each software overhead and thus overall enhanced virtualized embedded computing domain a distinct core or cluster on the platform. system performance. In [3], Shimada et al. have presented While providing a good isolation of domains, it does not an evaluation of their designed hypervisor according to four enable efficient sharing of hardware resources. The software main criteria: boot time, communication overhead, CPU solution is virtualization [1]. It provides a software envi- time overhead for intensive tasks and latency of interrupts. ronment on which programs or complete operating systems We did not find microbenchmarks suitable for embedded can run simultaneously, as if they were running natively on hypervisor evaluation. However, some OS benchmarks such hardware. The software layer providing this environment is as LMBENCH [4], UnixBench [5] and HBench-OS [6], [7] called Virtual Machine (VM). Multiple VMs can thus run provide metrics that can be used for hypervisor evaluation. almost transparently on a single hardware device, managed A common limitation of several of these previous works by a hypervisor which provides an abstraction layer between is that they advocate a specific hypervisor solution, and the physical hardware and the VMs. However, due to shared therefore focus on their specific performance advantage. resources, some interference may occur between virtual Moreover they usually use a very technical evaluation ap- machines. proach with many details (microbenchmarks), which can be Several forms of virtualization may be applicable to far from the realm of a real-world business-driven decision. embedded software consolidation. Virtualization solutions Our methodology proposes a balance technical criteria (al- are usually classified as type-I (bare-metal hypervisor) or though less detailed than several related works) with non- type-II (hypervisor hosted inside a bare-metal, full-featured technical criteria, in a methodological approach. operating system), microkernel-based hypervisors being a hybrid between both, where the VMM (virtual machine 3. Approach manager) runs over a small microkernel or separation kernel. Deciding among the available hypervisors which ones We propose a rational and practical approach to selecting are more suitable is not an easy task as it requires eliciting an embedded hypervisor for a specific domain needs. First, This work was done while all authors were research engineers at CEA, the user needs have to be turned into selection criteria. LIST. Based on user requirements, on knowledge of embedded hypervisors and of applications of the domain, we propose possibility of a long-term relationship between the a set of criteria, both qualitative and quantitative, which integrator and hypervisor editor (or open-source detail specific characteristics, features, or metrics, that can community) needs to be assessed, as well as le- be evaluated for each particular solution. gal/contractual constraints. It however would be prohibitive to evaluate all metrics • Required vs. nice-to-have features: some features on all hypervisors, and approach selection as a maximization are strictly necessary to certain users (e.g. ”support process. Instead, we propose a multi-step filtering process the ARMv8A instruction set”), while some others where at each step the most blocking or most easily- may be added later (e.g. support a specific driver), evaluated criteria are used to reject a number of solutions, so and only represent a limited additional cost. that the subsequent steps can devote more effort to evaluate • Objective vs. subjective evaluation: several crite- in depth a reduced number of solutions. ria are uneasy to assess objectively e.g. ease of We propose a list of evaluation criteria, grouped into the use. Moreover, many technical criteria (e.g.context- following classes: switch performance, inter-VM interference), while objectively defined, can only be evaluated on a spe- • Main features cific hardware, and in a specific configuration. The – hypervisor type (type I, type II, microkernel- definition of test cases and hypervisor configurations based) may not accurately model the actual field usage – supported hardware architectures (e.g. configurations. For these reasons, all quantitative ARMv8A, x86/64, etc.) criteria are regarded as an estimation only and are – supported OSs (e.g. full-virtualized Linux, subject to interpretation. paravirtualized RTOSs) – communication services (e.g. inter-partition 4. Application in the automotive domain comms, virtual network) – exposed APIs (e.g. Posix PSE-53, OSEK, In collaboration with the Renault-Nissan Alliance within ARINC653, etc.) the project FACE “Future architecture for Automotive Com- – real-time support (time-driven or priority- puter Environment“1, CEA has designed a centralized com- driven, preemption model, resource monitor- puting hardware and software platform. This platform shall ing model, etc.) serve as a generic computing unit supporting various ve- – safety & security services (memory partition- hicle product lines, designed to host several heterogeneous ing, health monitoring, fault-tolerance, etc.) software appliances ranging from e.g. hard real-time control Industrial maturity & business model to soft real-time CPU-intensive ADAS processing and best- effort multimedia applications. These appliances may be – application domains and success stories (how developed, deployed and updated independently by vari- many prototypes or industrial products that ous software providers. In this context, we applied the rely on a version of that hypervisor) methodological selection process presented above to select a – available safety & security qualification pack- suitable candidate. Choosing a software platform for a wide ages (e.g. generic qualification package like range of product is a long-term strategic decision, there- automotive SEooC or Common-Criteria EAL fore business and strategic stakes are as high as technical, certification, or successful use in a safety- or performance-related ones. security-qualified product; applicable restric- Our selection process was performed in 3 steps. At each tion for safety- or security-qualified usage) step, several criteria are used to select a limited number of – toolset (availability, and ease-of-use of devel- candidates for further analysis, as illustrated in figure 1. opment environment, configuration, debug, analysis tools) 4.1. Selection process overview – licensing model (e.g. open-source, flat rate or per-product license fee) At first, list of 23 embedded hypervisor solutions was – business model (available support, applicable identified, both open-source and commercial ones. These regulation, partnership model) were then scrutinized together against the main discriminat- These criteria are characterized along the following as- ing requirements of: pects: • real-time support, • Qualitative vs. quantitative: many qualitative crite- • available safety/security qualification package, ria are easily evaluated from public documentation, • estimated industrial maturity (assessed based on and may therefore be used in early selection steps; known industrial uses of the hypervisor) and avail- whereas most quantitative criteria should be mea- able support. sured on target, which is a more costly process. 1. http://www-list.cea.fr/en/media/news/2019/409-february-19-2019- • Technical vs. non-technical criteria: besides tech- face-powers-automotive-innovations-by-revolutionizing-electrical-and- nical compatibility and
Load more

Recommended publications
  • Implementation of Machining on the Cloud
    Implementation of Machining on the Cloud: A Case Study in PLM Environment Saurav Bhatt, Frédéric Segonds, Nicolas Maranzana, Ameziane Aoussat, Vincent Frerebeau, Damien Chasset To cite this version: Saurav Bhatt, Frédéric Segonds, Nicolas Maranzana, Ameziane Aoussat, Vincent Frerebeau, et al.. Implementation of Machining on the Cloud: A Case Study in PLM Environment. 13th IFIP Interna- tional Conference on Product Lifecycle Management (PLM), Jul 2016, Columbia, SC, United States. pp.341-355, 10.1007/978-3-319-54660-5_31. hal-01699699 HAL Id: hal-01699699 https://hal.inria.fr/hal-01699699 Submitted on 2 Feb 2018 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Distributed under a Creative Commons Attribution| 4.0 International License Implementation of Machining on the Cloud: A case study in PLM environment Saurav Bhatt1,3, Frédéric Segonds2, Nicolas Maranzana2, Améziane Aoussat2, Vincent Frerebeau3, Damien Chasset3 1 Delhi College of Engineering, Delhi, India 2 Arts et Métiers, Paris Tech, LCPI, 151 Boulevard de l’Hôpital, 75013 Paris, France 3 Dassault Systemes, 10 Rue Marcel Dassault, 78140 Velizy Villacoublay, France [email protected] Abstract. This paper focuses on the implementation of cloud solutions in the field of machining which is encompassed by the much larger field of manufacturing.
    [Show full text]
  • Enhancing Undergraduate Understanding of Subtractive Manufacturability Through Virtualized Simulation of CNC Machining
    Paper ID #18310 Enhancing Undergraduate Understanding of Subtractive Manufacturability through Virtualized Simulation of CNC Machining Mr. Roby Lynn Dr. Kathryn W. Jablokow, Pennsylvania State University, Great Valley Dr. Kathryn Jablokow is an Associate Professor of Engineering Design and Mechanical Engineering at Penn State University. A graduate of Ohio State University (Ph.D., Electrical Engineering), Dr. Jablokow’s teaching and research interests include problem solving, invention, and creativity in science and engineer- ing, as well as robotics and manufacturing education. In addition to her membership in ASEE, she is a Senior Member of IEEE, a Fellow of ASME, and the recipient of the 2016 ASME Ruth and Joel Spira Outstanding Design Educator Award. Dr. Jablokow is the architect of a unique 4-course module fo- cused on creativity and problem solving leadership and is currently developing a new methodology for cognition-based design. She is one of three instructors for Penn State’s Massive Open Online Course (MOOC) on Creativity, Innovation, and Change, and she is the founding director of the Problem Solving Research Group, whose 50+ collaborating members include faculty and students from several universities, as well as industrial representatives, military leaders, and corporate consultants. Prof. Christopher Saldana Dr. Thomas Marshall Tucker, Tucker Innovations Dr. Tommy Tucker is the CEO and owner of Tucker Innovations. He has a Ph.D. in Mechanical Engineer- ing from the Georgia Institute of Technology. He has over 15 years of experience writing computationally intensive software applications for engineering, medical, and defense applications. After spending the early part of his career at high tech start-up companies, Dr.
    [Show full text]
  • Real-Time, Safe and Certified OS
    Real-Time, Safe and Certified OS Roman Kapl <[email protected]> drivers, customer projects, development Tomas Martinec <[email protected]> testing and certification © SYSGO AG · INTERNAL 1 Introduction • PikeOS – real-time, safety certified OS • Desktop and Server vs. • Embedded • Real-Time • Safety-Critical • Certified • Differences • Scheduling • Resource management • Features • Development © SYSGO AG · INTERNAL 2 Certification • Testing • Analysis • Lot of time • Even more paper • Required for safety-critical systems • Trains • Airplanes © SYSGO AG · INTERNAL 3 PikeOS • Embedded, real-time, certified OS • ~150 people (not just engineers) • Rail • Avionics • Space • This presentation is not about PikeOS specifically © SYSGO AG · INTERNAL 4 PikeOS technical • Microkernel • Inspired by L4 • Memory protection (MMU) • More complex than FreeRTOS • Virtualization hypervisor • X86, ARM, SPARC, PowerPC • Eclipse IDE for development © SYSGO AG · INTERNAL 5 Personalities • General • POSIX • Linux • Domain specific • ARINC653 • PikeOS native • Other • Ada, RT JAVA, AUTOSAR, ITRON, RTEMS © SYSGO AG · INTERNAL 6 PikeOS Architecture App. App. App. App. App. App. Volume Syste m Provider Partition PikeOS Para-Virtualized HW Virtualized File System (Native, POSIX, Guest OS PikeOS Native ARINC653, ...) Guest OS Linux, Android Linux, Android Device Driver User Space / Partitions Syste m PikeOS System Software ExtensionSyste m Extension PikeOS Microkernel Kernel Space / Hypervisor Architecture Platform Kernel Level Support Package Support Package Driver SoC /
    [Show full text]
  • An Event-Driven Embedded Operating System for Miniature Robots
    This is a repository copy of OpenSwarm: an event-driven embedded operating system for miniature robots. White Rose Research Online URL for this paper: http://eprints.whiterose.ac.uk/110437/ Version: Accepted Version Proceedings Paper: Trenkwalder, S.M., Lopes, Y.K., Kolling, A. et al. (3 more authors) (2016) OpenSwarm: an event-driven embedded operating system for miniature robots. In: Proceedings of IROS 2016. 2016 IEEE/RSJ International Conference on Intelligent Robots and Systems, 09-14 Oct 2016, Daejeon, Korea. IEEE . ISBN 978-1-5090-3762-9 https://doi.org/10.1109/IROS.2016.7759660 © 2016 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other users, including reprinting/ republishing this material for advertising or promotional purposes, creating new collective works for resale or redistribution to servers or lists, or reuse of any copyrighted components of this work in other works. Reuse Items deposited in White Rose Research Online are protected by copyright, with all rights reserved unless indicated otherwise. They may be downloaded and/or printed for private study, or other acts as permitted by national copyright laws. The publisher or other rights holders may allow further reproduction and re-use of the full text version. This is indicated by the licence information on the White Rose Research Online record for the item. Takedown If you consider content in White Rose Research Online to be in breach of UK law, please notify us by emailing [email protected] including the URL of the record and the reason for the withdrawal request.
    [Show full text]
  • What Are the Problems with Embedded Linux?
    What Are the Problems with Embedded Linux? Every Operating System Has Benefits and Drawbacks Linux is ubiquitous. It runs most internet servers, is inside Android* smartphones, and is used on millions of embedded systems that, in the past, ran Real-Time Operating Systems (RTOSes). Linux can (and should) be used were possible for embedded projects, but while it gives you extreme choice, it also presents the risk of extreme complexity. What, then, are the trade-offs between embedded Linux and an RTOS? In this article, we cover some key considerations when evaluating Linux for a new development: ■ Design your system architecture first ■ What is Linux? ■ Linux vs. RTOSes ■ Free software is about liberty—not price ■ How much does Embedded Linux cost? ■ Why pay for Embedded Linux? ■ Should you buy Embedded Linux or roll-your-own (RYO)? ■ To fork or not to fork? ■ Software patching ■ Open source licensing ■ Making an informed decision The important thing is not whether Linux or an RTOS is “the best,” but whether either operating system—or both together—makes the most technical and financial sense for your project. We hope this article helps you make an informed decision. Design Your System Architecture First It is important to design your system architecture first—before choosing either Linux or an RTOS—because both choices can limit architectural freedom. You may discover that aspects of your design require neither Linux nor an RTOS, making your design a strong candidate for a heterogeneous approach that includes one or more bare-metal environments (with possibly a Linux and/or RTOS environment as well).
    [Show full text]
  • Co-Optimizing Performance and Memory Footprint Via Integrated CPU/GPU Memory Management, an Implementation on Autonomous Driving Platform
    2020 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS) Co-Optimizing Performance and Memory Footprint Via Integrated CPU/GPU Memory Management, an Implementation on Autonomous Driving Platform Soroush Bateni*, Zhendong Wang*, Yuankun Zhu, Yang Hu, and Cong Liu The University of Texas at Dallas Abstract—Cutting-edge embedded system applications, such as launches the OpenVINO toolkit for the edge-based deep self-driving cars and unmanned drone software, are reliant on learning inference on its integrated HD GPUs [4]. integrated CPU/GPU platforms for their DNNs-driven workload, Despite the advantages in SWaP features presented by the such as perception and other highly parallel components. In this work, we set out to explore the hidden performance im- integrated CPU/GPU architecture, our community still lacks plication of GPU memory management methods of integrated an in-depth understanding of the architectural and system CPU/GPU architecture. Through a series of experiments on behaviors of integrated GPU when emerging autonomous and micro-benchmarks and real-world workloads, we find that the edge intelligence workloads are executed, particularly in multi- performance under different memory management methods may tasking fashion. Specifically, in this paper we set out to explore vary according to application characteristics. Based on this observation, we develop a performance model that can predict the performance implications exposed by various GPU memory system overhead for each memory management method based management (MM) methods of the integrated CPU/GPU on application characteristics. Guided by the performance model, architecture. The reason we focus on the performance impacts we further propose a runtime scheduler.
    [Show full text]
  • Sistemi Operativi Real-Time Marco Cesati Lezione R13 Sistemi Operativi Real-Time – II Schema Della Lezione
    Sistemi operativi real-time Marco Cesati Lezione R13 Sistemi operativi real-time – II Schema della lezione Caratteristiche comuni VxWorks LynxOS Sistemi embedded e real-time QNX eCos Windows Linux come RTOS 15 gennaio 2013 Marco Cesati Dipartimento di Ingegneria Civile e Ingegneria Informatica Università degli Studi di Roma Tor Vergata SERT’13 R13.1 Sistemi operativi Di cosa parliamo in questa lezione? real-time Marco Cesati In questa lezione descriviamo brevemente alcuni dei più diffusi sistemi operativi real-time Schema della lezione Caratteristiche comuni VxWorks LynxOS 1 Caratteristiche comuni degli RTOS QNX 2 VxWorks eCos 3 LynxOS Windows Linux come RTOS 4 QNX Neutrino 5 eCos 6 Windows Embedded CE 7 Linux come RTOS SERT’13 R13.2 Sistemi operativi Caratteristiche comuni dei principali RTOS real-time Marco Cesati Corrispondenza agli standard: generalmente le API sono proprietarie, ma gli RTOS offrono anche compatibilità (compliancy) o conformità (conformancy) allo standard Real-Time POSIX Modularità e Scalabilità: il kernel ha una dimensione Schema della lezione Caratteristiche comuni (footprint) ridotta e le sue funzionalità sono configurabili VxWorks Dimensione del codice: spesso basati su microkernel LynxOS QNX Velocità e Efficienza: basso overhead per cambi di eCos contesto, latenza delle interruzioni e primitive di Windows sincronizzazione Linux come RTOS Porzioni di codice non interrompibile: generalmente molto corte e di durata predicibile Gestione delle interruzioni “separata”: interrupt handler corto e predicibile, ISR lunga
    [Show full text]
  • Performance Study of Real-Time Operating Systems for Internet Of
    IET Software Research Article ISSN 1751-8806 Performance study of real-time operating Received on 11th April 2017 Revised 13th December 2017 systems for internet of things devices Accepted on 13th January 2018 E-First on 16th February 2018 doi: 10.1049/iet-sen.2017.0048 www.ietdl.org Rafael Raymundo Belleza1 , Edison Pignaton de Freitas1 1Institute of Informatics, Federal University of Rio Grande do Sul, Av. Bento Gonçalves, 9500, CP 15064, Porto Alegre CEP: 91501-970, Brazil E-mail: [email protected] Abstract: The development of constrained devices for the internet of things (IoT) presents lots of challenges to software developers who build applications on top of these devices. Many applications in this domain have severe non-functional requirements related to timing properties, which are important concerns that have to be handled. By using real-time operating systems (RTOSs), developers have greater productivity, as they provide native support for real-time properties handling. Some of the key points in the software development for IoT in these constrained devices, like task synchronisation and network communications, are already solved by this provided real-time support. However, different RTOSs offer different degrees of support to the different demanded real-time properties. Observing this aspect, this study presents a set of benchmark tests on the selected open source and proprietary RTOSs focused on the IoT. The benchmark results show that there is no clear winner, as each RTOS performs well at least on some criteria, but general conclusions can be drawn on the suitability of each of them according to their performance evaluation in the obtained results.
    [Show full text]
  • Security Target Pikeos Separation Kernel V4.2.2
    Security Target PikeOS Separation Kernel v4.2.2 Document ID Revision DOORS Baseline Date State 00101-8000-ST 20.6 N.A. 2018-10-10 App Author: Dominic Eschweiler SYSGO AG Am Pfaffenstein 14, D-55270 Klein-Winternheim Notice: The contents of this document are proprietary to SYSGO AG and shall not be disclosed, disseminated, copied, or used except for purposes expressly authorized in writing by SYSGO AG. Doc. ID: 00101-8000-ST Revision: 20.6 This page intentionally left blank Copyright 2018 Page 2 of 47 All rights reserved. SYSGO AG Doc. ID: 00101-8000-ST Revision: 20.6 This page intentionally left blank Copyright 2018 Page 3 of 47 All rights reserved. SYSGO AG Doc. ID: 00101-8000-ST Revision: 20.6 Table of Contents 1 Introduction .................................................................................................................... 6 1.1 Purpose of this Document ........................................................................................... 6 1.2 Document References ................................................................................................ 6 1.2.1 Applicable Documents......................................................................................... 6 1.2.2 Referenced Documents ....................................................................................... 6 1.3 Abbreviations and Acronyms ....................................................................................... 6 1.4 Terms and Definitions................................................................................................
    [Show full text]
  • Oracle® Linux Virtualization Manager Getting Started Guide
    Oracle® Linux Virtualization Manager Getting Started Guide F25124-11 September 2021 Oracle Legal Notices Copyright © 2019, 2021 Oracle and/or its affiliates. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract.
    [Show full text]
  • Our Tas Top 11 Technologies of the Decade Tinyos and Nesc Hardware Evolu On
    Our TAs Top 11 Technologies of the Decade Mo Sha Yong Fu 1.! Smartphones 7.! Drone Aircra • [email protected]" •! [email protected]" •! TinyOS tutorial." •! Grade critiques." 2.! Social Networking 8.! Planetary Rovers •! Help students with projects." •! Office Hour: by appointment." 3.! Voice over IP 9.! Flexible AC •! Manage motes." •! Bryan 502D Transmission •! Grade projects." 4.! LED Lighng •! Office Hour: Tue/Thu 5:30-6." 5.! Mul@core CPUs 10.!Digital Photography •! Bryan 502A 6.! Cloud Compung 11.!Class-D Audio Chenyang Lu 1 Chenyang Lu 2 TinyOS and nesC Hardware Evoluon ! TinyOS: OS for wireless sensor networks. ! Miniature devices manufactured economically ! nesC: programming language for TinyOS. ! Microprocessors ! Sensors/actuators ! Wireless chips 4.5’’X2.4’’ 1’’X1’’ 1 mm2 1 nm2 Chenyang Lu 4 Chenyang Lu 3 Mica2 Mote Hardware Constraints ! Processor ! Microcontroller: 7.4 MHz, 8 bit Severe constraints on power, size, and cost ! Memory: 4KB data, 128 KB program ! slow microprocessor ! Radio ! low-bandwidth radio ! Max 38.4 Kbps ! limited memory ! Sensors ! limited hardware parallelism CPU hit by many interrupts! ! Light, temperature, acceleraon, acous@c, magne@c… ! manage sleep modes in hardware components ! Power ! <1 week on two AA baeries in ac@ve mode ! >1 year baery life on sleep modes! Chenyang Lu 5 Chenyang Lu 6 Soware Challenges Tradional OS ! Small memory footprint ! Mul@-threaded ! Efficiency - power and processing ! Preemp@ve scheduling ! Concurrency-intensive operaons ! Threads: ! Diversity in applicaons & plaorm efficient modularity ! ready to run; ! Support reconfigurable hardware and soJware executing ! execu@ng on the CPU; ! wai@ng for data. gets CPU preempted needs data gets data ready waiting needs data Chenyang Lu 7 Chenyang Lu 8 Pros and Cons of Tradional OS Example: Preempve Priority Scheduling ! Each process has a fixed priority (1 highest); ! Mul@-threaded + preemp@ve scheduling ! P1: priority 1; P2: priority 2; P3: priority 3.
    [Show full text]
  • A Lightweight Virtualization Layer with Hardware-Assistance for Embedded Systems
    PONTIFICAL CATHOLIC UNIVERSITY OF RIO GRANDE DO SUL FACULTY OF INFORMATICS COMPUTER SCIENCE GRADUATE PROGRAM A LIGHTWEIGHT VIRTUALIZATION LAYER WITH HARDWARE-ASSISTANCE FOR EMBEDDED SYSTEMS CARLOS ROBERTO MORATELLI Dissertation submitted to the Pontifical Catholic University of Rio Grande do Sul in partial fullfillment of the requirements for the degree of Ph. D. in Computer Science. Advisor: Prof. Fabiano Hessel Porto Alegre 2016 To my family and friends. “I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.” (Linus Torvalds) ACKNOWLEDGMENTS I would like to express my sincere gratitude to those who helped me throughout all my Ph.D. years and made this dissertation possible. First of all, I would like to thank my advisor, Prof. Fabiano Passuelo Hessel, who has given me the opportunity to undertake a Ph.D. and provided me invaluable guidance and support in my Ph.D. and in my academic life in general. Thank you to all the Ph.D. committee members – Prof. Carlos Eduardo Pereira (dissertation proposal), Prof. Rodolfo Jardim de Azevedo, Prof. Rômulo Silva de Oliveira and Prof. Tiago Ferreto - for the time invested and for the valuable feedback provided.Thank you Dr. Luca Carloni and the other SLD team members at the Columbia University in the City of New York for receiving me and giving me the opportunity to work with them during my ‘sandwich’ research internship. Eu gostaria de agraceder minha esposa, Ana Claudia, por ter estado ao meu lado durante todo o meu período de doutorado. O seu apoio e compreensão foram e continuam sendo muito importantes para mim.
    [Show full text]