Secure Firmware Updates for Constrained Iot Devices

Total Page:16

File Type:pdf, Size:1020Kb

Secure Firmware Updates for Constrained Iot Devices Secure Firmware Updates for Constrained IoT Devices Using Open Standards: A Reality Check Koen Zandberg, Kaspar Schleiser, Francisco Acosta, Hannes Tschofenig, Emmanuel Baccelli To cite this version: Koen Zandberg, Kaspar Schleiser, Francisco Acosta, Hannes Tschofenig, Emmanuel Baccelli. Secure Firmware Updates for Constrained IoT Devices Using Open Standards: A Reality Check. IEEE Access, IEEE, 2019, 7, pp.71907-71920. 10.1109/ACCESS.2019.2919760. hal-02351794 HAL Id: hal-02351794 https://hal.inria.fr/hal-02351794 Submitted on 6 Nov 2019 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. Secure Firmware Updates for Constrained IoT Devices using Open Standards: A Reality Check Koen Zandberg Kaspar Schleiser Francisco Acosta Inria & FU Berlin Inria & FU Berlin Inria Hannes Tschofenig Emmanuel Baccelli Arm Ltd. Inria ABSTRACT This highlights the need to design a firmware update mecha- While IoT deployments multiply in a wide variety of verticals, most nism into IoT devices at the beginning of the product development. IoT devices lack a built-in secure firmware update mechanism. With- Of course, if designed incorrectly, firmware updates can become at- out such a mechanism, however, critical security vulnerabilities tack vectors themselves. The Zigbee Worm54 [ ], for example, trig- cannot be fixed, and IoT devices can become a permanent liabil- gered a chain reaction combining a series of malicious firmware ity, as demonstrated by recent large-scale attacks. In this paper, updates and promiscuous wireless communications. The situation we survey open standards and open source libraries that provide would be significantly improved if developers could use a stan- useful building blocks for secure firmware updates for constrained dardized firmware update mechanism rather than having to design IoT devices – by which we mean low-power, microcontroller-based their own. devices such as networked sensors/actuators with a small amount In this paper, therefore, we explore the options that developers of memory, among other constraints. We design and implement a have today, and we design a prototype that enables IoT firmware prototype that leverages these building blocks and assess the se- updates based on standardized building blocks. curity properties of this prototype. We present experimental re- We focus in particular on firmware update mechanisms that can sults, including first experiments with SUIT, a new IETF standard work on constrained IoT devices. Such devices, as specified in RFC for secure IoT firmware updates. We evaluate the performance of 7228 [19], use microcontrollers – for instance Arm Cortex-M – on our implementation on a variety of commercial off-the-shelf con- which run real-time operating systems, such as RIOT, FreeRTOS, strained IoT devices. We conclude that it is possible to create a µC/OS, Contiki, mbed OS, among others [30]. Compared to ma- secure, standards-compliant firmware update solution that uses chines that run full-blown operating systems, such as Linux, con- state-of-the-art security for IoT devices with less than 32kB of RAM strained IoT devices use a fraction of the power and are equipped and 128kB of flash memory. with RAM and flash sizes in the kilobyte range. Constrained IoT devices cannot afford the energy drain of Wi-Fi, and thus connect CCS CONCEPTS to the network using low-power, wireless, link-layer technologies, such as Bluetooth Low-Energy, IEEE 802.15.4, LoRa, 3GPP Cellular • Computer systems organization → Embedded systems. IoT (NB-IoT), or through wired buses, such as BACnet. KEYWORDS Internet of Things, IoT, Security, Software Update, Firmware Up- The contributions of this paper are structured as follows: date, Open Standards, Constrained Device (1) In Sections II-III, we survey available open standards and open source libraries, which provide useful generic building 1 INTRODUCTION blocks that can be used to enable IoT firmware updates; The increasing availability of low-cost hardware, new low-power (2) In Section IV, we design and implement a prototype that radio technologies, and real-time operating systems specially de- leverages the building blocks we surveyed. This prototype signed for these embedded devices makes the Internet of Things enables secure firmware updates on a large variety of con- (IoT) accessible to a broader range of developers. IoT devices are strained IoT devices, while entirely avoiding proprietary mech- now used in many verticals, from logistics to precision farming, anisms and code; introducing new ways to optimize existing business processes and (3) In Section V, we measure and compare the performance of enabling novel use cases. IoT devices are also used in critical infras- various crypto libraries that are relevant in this context; tructures where safety and security plays an even more important (4) In Section VI, we assess the security properties of our pro- role. totype; However, while IoT devices are expected to have a major impact (5) In Section VII, we measure and compare the performance of on our economy, they are also known for their weak security. The several deployment configurations using our prototype, and Mirai botnet [5], for example, demonstrated that large-scale DDoS provide the first experimental evaluation of the IETF SUIT attacks using compromised IoT devices threaten other communi- specification; cation infrastructures. It is equally alarming that many of these (6) In Section VIII, we discuss the limitations of our prototype. compromised IoT devices are not equipped with a firmware update We conclude that, as we have shown, it is possible today to mechanism and, therefore, remain unpatched to this day. create a generic, secure firmware update mechanism that complies with open standards, and we provide recommen- In addition to authentication and integrity protection, even when dations for future work. updates are stored on untrusted repositories, the SUIT specifica- tions enable encrypting the firmware image, to protect against at- 2 PRIOR WORK ON SOFTWARE UPDATES tacks based on reverse engineering. SUIT followed previous work FOR CONSTRAINED IOT DEVICES such as FOSE [? ] which proposed firmware encryption and sign- ing using JSON and JOSE. The Update Framework (TUF)3 [ ] and An IoT firmware update solution is a special case of software up- Uptane [37], designed for use in connected cars, aim to ensure the date, and consists of three areas of work [23], namely: (a) embed- security of a software update system, even against attackers who ded software design on low-end IoT devices, (b) backend frame- compromise the repository or signing keys. ASSURED [14] builds work, and (c) network transport of the firmware towards the IoT on TUF to improve support for constrained IoT devices by lever- devices. aging a trusted intermediate controller between the update reposi- Embedded software design on low-end IoT devices. The software tory and IoT device. CHAINIAC [46] is another approach that uses on an IoT device has to be prepared to support a firmware update a blockchain-like mechanism to attest to the history of prior up- mechanism. The device needs a bootloader, the logic that is exe- dates, even without central authority. cuted first when the device boots and determines which firmware it launches. Sometimes devices are equipped with multiple boot- Network transport. The third aspect of IoT firmware updates con- loaders; for example, a stage 1 bootloader in the ROM and a stage cerns the dissemination of software through the network. The vari- 2 bootloader that can be updated. The reason for such designs is ety of approaches to this topic, as presented in recently published security-related because updating a bootloader can lead to a bricked literature, includes protocols that optimize the dissemination of up- device. Whenever a bootloader is present on a device, the memory dates through multiple paths in a multi-hop, low-power wireless layout of the hardware has to be considered, and exception han- network [31]; updating network stack modules to reconfigure the dlers1 must be repositioned. network on the fly [65]; and using the Message Queuing Teleme- The typical firmware update procedure is fairly simple: adevel- try Transport (MQTT) protocol to disseminate software updates oper recompiles the code and generates an entirely new firmware to a fleet of IoT devices [27]. 6LoWPAN protocols [58] enable end- image, which is then distributed to the device. The flash memory to-end IP connectivity from constrained IoT devices to anywhere of the IoT device is split into memory regions (slots) containing (i) on the (IPv6) internet. The IETF Trusted Execution Environment the bootloader and (ii) firmware images (with some metadata). The Provisioning (TEEP) working group [32] is standardizing a trans- new firmware is stored into one of the available slots. TheIoTde- port mechanism to update trusted applications running in trusted vice is then reset so that the bootloader can boot the new firmware execution environments (TEEs), such as Arm TrustZone and Intel image [10]. This approach is used, for example, by MCUboot [2] SGX. and ESPer [27]. Other considerations can lead to different designs. For instance, 3 OPEN STANDARDS FOR SECURE one may consider the granularity of the software update, or the CONSTRAINED IOT FIRMWARE UPDATES amount of data that needs to be transmitted for an update. Certain Over the last few years, the technical community has been work- approaches enable partial update via dynamic loading of binary ing on open standards [36] that can be combined to facilitate IoT modules [26, 55], while others use differential binary patching [33]. firmware updates.
Recommended publications
  • 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]
  • Wireless Sensor Networks
    WIRELESS SENSOR NETWORKS PRESENTED BY VIVEK KRISHNA KANNAN SIDDARTH RAM MOHAN ARUN OUTLINE • Wireless sensor networks • The Internet of Things and the role of WSN • TinyOS • Programming with Tinyos WIRELESS SENSOR NETWORKS • Comprises of spatially connected autonomous sensors • Typically used to measure temperature, pressure etc • Usually bi-directional allowing for control of sensor activity WIRELESS SENSOR NETWORKS MOTES/NODES • Sensors + supporting elements = Mote/Node • So, apart from the sensor, each mote typically consists of : • Radio transceiver with an internal antenna • A microcontroller • An interfacing element between the microcontroller and sensor • An energy source ( Battery or an energy harvesting element) GATEWAY • GATEWAY acts as a bridge between the WSN and other networks. This enables data to be stored and processed by devices with more resources, for example, in a remotely located server. RADIO TECHNOLOGIES AVAILABLE • Long range: 3G / GPRS • Medium range: ZigBee / 802.15.4 / WiFi • Short range: RFID / NFC / Bluetooth 4.0 ROUTING PROTOCOLS : CHALLENGES • No global IP addressing • This is due to the relatively large number of sensor nodes • Consequently overhead of ID maintenance is high • Thus IP based protocols don’t work ROUTING PROTOCOLS • The search for an ideal universal routing protocol for WSN’s is an ongoing process • A Technique is to have protocols based on the network structure • Common protocols for WSN: flat based and location based network structures ROUTING PROTOCOL : FLAT BASED NETWORK STRUCTURE • Here
    [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]
  • 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]
  • Building for I.MX Mature Boards
    NXP Semiconductors Document Number: AN12024 Application Notes Rev. 0 , 07/2017 Building for i.MX Mature Boards 1. Introduction Contents The software for mature i.MX boards is upstreamed into 1. Introduction ........................................................................ 1 the Linux Kernel and U-Boot communities. These 2. Mature SoC Software Status .............................................. 2 boards can use the current Linux Kernel and U-Boot 3. Further Assistance .............................................................. 2 4. Boards Supported by the Yocto Project Community ......... 2 community solution. NXP no longer provides code and 4.1. Build environment setup ......................................... 3 images for these boards directly. This document 4.2. Examples ................................................................ 3 describes how to build the current Linux kernel and U- Boot software using the community solution for mature boards. The i.MX Board Support Packages (BSP) Releases are only supported for one year after the release date, so developing mature SoC projects using community solutions provides more current software and longer life for software than using the static BSPs provided by NXP. Community software includes upstreamed patches that the i.MX development team has provided to the community after the BSPs were released. Peripherals on i.MX mature boards such as the VPU and GPU, which depend on proprietary software, might be limited to an earlier version of the i.MX BSP. Supported i.MX reference boards should use the latest released i.MX BSPs on i.MX Software and Tools. Community solutions are not formally validated for i.MX. © 2017 NXP B.V. Boards Supported by the Yocto Project Community 2. Mature SoC Software Status The following i.MX mature SoC boards are from the i.MX 2X, 3X, and 5X families.
    [Show full text]
  • Field Area Network
    IEEE IoT Vertical & Topical Summit for Agriculture Patrick Wetterwald, CTAO IOT Standards and Architecture ETSI IP6 Vice Chairman, IEC SEG8 Chair, IPSO Alliance Past President [email protected] May 21st , 2017 What Is the Internet of Things? “The Internet of Things is the intelligent connectivity of physical devices driving massive gains in efficiency, business growth, and quality of life.” © 2013-2014 Cisco and/or its affiliates. All rights reserved. 2 IoT Is Here Now – and Growing! 50 50 Billion 40 “Smart Objects” Rapid Adoption 30 Rate of Digital Infrastructure: 5X Faster Than 20 25 Electricity and InflectionThe New Essential InfrastructureTelephony Point BILLIONS OF DEVICES 12.5 10 World Population 6.8 7.2 7.6 0 TIMELINE 2010 2015 2020 Source: Cisco IBSG, 2011 © 2013-2014 Cisco and/or its affiliates. All rights reserved. 3 Smart Agriculture © 2013-2014 Cisco and/or its affiliates. All rights reserved. 4 IoT Transforms Data into Wisdom More Important Wisdom (Scenario Planning) Knowledge Information 01010100101010101010101010101 Data 01010101010001010100101010101 01110101010101010101 Less Important © 2013Big-2014 Cisco Data and/or its affiliates. becomes All rights reserved. Open Data for Customers, Consumers to Use 5 But It Also Adds Complexity NewAPPLICATION Business Models AND BUSINESSPartner INNOVATION Ecosystem Cloud-based Threat Analysis / Protection Data Control Application Big Data Analytics Integration Applications Systems Integration Network and Perimeter Application Interfaces Security Services IoT CONNECTIVITYUnified Platform
    [Show full text]
  • Demystifying Internet of Things Security Successful Iot Device/Edge and Platform Security Deployment — Sunil Cheruvu Anil Kumar Ned Smith David M
    Demystifying Internet of Things Security Successful IoT Device/Edge and Platform Security Deployment — Sunil Cheruvu Anil Kumar Ned Smith David M. Wheeler Demystifying Internet of Things Security Successful IoT Device/Edge and Platform Security Deployment Sunil Cheruvu Anil Kumar Ned Smith David M. Wheeler Demystifying Internet of Things Security: Successful IoT Device/Edge and Platform Security Deployment Sunil Cheruvu Anil Kumar Chandler, AZ, USA Chandler, AZ, USA Ned Smith David M. Wheeler Beaverton, OR, USA Gilbert, AZ, USA ISBN-13 (pbk): 978-1-4842-2895-1 ISBN-13 (electronic): 978-1-4842-2896-8 https://doi.org/10.1007/978-1-4842-2896-8 Copyright © 2020 by The Editor(s) (if applicable) and The Author(s) This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Open Access This book is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this book are included in the book’s Creative Commons license, unless indicated otherwise in a credit line to the material.
    [Show full text]
  • Water -M Project
    Water -M Project D1.3 IT State of the Art v2.2 History Date Version & Status Author Modifications 02/09/2015 v0.1 Kamal Singh (UJM) A Draft with state of the art on ICT 28/10/2015 V1.0 Berhane A draft with state of the art on ICT. Gebremedhin Merged the 2 drafts into a new one. (University of Oulu) Compiled the references 14/04/2016 V2.0 Kamal Singh (UJM), Added 2.4 OneM2M standard, added 2.5 Abderrahmen SoA on Data management analytics and Kammoun (City of 2.6 about IoT platforms and SOFIA2. Saint Etienne / UJM), Francois-Elie Calvier (UJM) 15/04/2016 V2.1 Francois-Elie Calvier Updated References (UJM) 08/05/2016 V2.2 Berhane Berhane did some modifications Gebremedhin (University of Oulu) Contents 1 Introduction ............................................................................................................................................... 4 1.1 Business Drivers ................................................................................................................................ 4 1.2 Required Technologies ...................................................................................................................... 4 1.3 Challenges ......................................................................................................................................... 4 1.4 Opportunities ..................................................................................................................................... 5 2 ICT technologies for Water management .................................................................................................
    [Show full text]
  • Standards for Constrained Iot Devices
    IoT Device Standards [email protected] – IoT Strategy 1 © 2014 ARM IoT is not a new idea THINGS around us become smart and connected . This is not a new idea .. it’s been going on for >20 years1 . 2010: Connected things > world population (6.8B) 1 Weiser, Mark (1991) “the Computer for the 21st Century” Ubiquitous computing: "The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it.” 2 © 2014 ARM Motorola pager watch – 17 years ago 3 © 2014 ARM Accelerating IoT Reach SILOS of Things Today Situation: • Application-specific connected devices • Closed supply chains, proprietary interconnects • Very limited plug-and-play Time 4 © 2014 ARM Accelerating IoT INTERNET of Things Analysts predictions for connected devices (2020): 30 billion? 50 billion? 75 billion? Current trends show strong growth Reach but analysts are more optimistic: SILOS of Things Today 17% .. 31% CAGR, 2012-2020 8.7B in 2012 (Cisco) http://newsroom.cisco.com/feature-content?articleId=1208342 Time 5 © 2014 ARM Accelerating IoT INTERNET of Things What will drive demand for many tens of billions more devices? Better IoT Platforms … that can “weave themselves into the fabric of everyday life” • Integrated wireless • Right-size processors, memory • Low cost, low power Applications • Secure, trustworthy • Easy software development Reach • Easy integration into “things” SILOS of Things Today Standards Internet-scale IoT ecosystems Bust the silos Devices • Standards-based connectivity • Standards-based provisioning • Open markets for devices, apps • End-to-end security Time 6 © 2014 ARM IoT SoC platform evolution . Wireless On-chip radios Optimized for IoT bandwidth, power .
    [Show full text]
  • Timing Comparison of the Real-Time Operating Systems for Small Microcontrollers
    S S symmetry Article Timing Comparison of the Real-Time Operating Systems for Small Microcontrollers Ioan Ungurean 1,2 1 Faculty of Electrical Engineering and Computer Science; Stefan cel Mare University of Suceava, 720229 Suceava, Romania; [email protected] 2 MANSiD Integrated Center, Stefan cel Mare University, 720229 Suceava, Romania Received: 9 March 2020; Accepted: 1 April 2020; Published: 8 April 2020 Abstract: In automatic systems used in the control and monitoring of industrial processes, fieldbuses with specific real-time requirements are used. Often, the sensors are connected to these fieldbuses through embedded systems, which also have real-time features specific to the industrial environment in which it operates. The embedded operating systems are very important in the design and development of embedded systems. A distinct class of these operating systems is real-time operating systems (RTOSs) that can be used to develop embedded systems, which have hard and/or soft real-time requirements on small microcontrollers (MCUs). RTOSs offer the basic support for developing embedded systems with applicability in a wide range of fields such as data acquisition, internet of things, data compression, pattern recognition, diversity, similarity, symmetry, and so on. The RTOSs provide basic services for multitasking applications with deterministic behavior on MCUs. The services provided by the RTOSs are task management and inter-task synchronization and communication. The selection of the RTOS is very important in the development of the embedded system with real-time requirements and it must be based on the latency in the handling of the critical operations triggered by internal or external events, predictability/determinism in the execution of the RTOS primitives, license costs, and memory footprint.
    [Show full text]