Recommended
More Related Content
What's hot
What's hot (20)
Similar to iot-component-dimensioning
Similar to iot-component-dimensioning (20)
Recently uploaded
Recently uploaded (20)
iot-component-dimensioning
- 1. Lecture 1 ESE 510: Internet of Things IoT Component Dimensioning Assoc. Prof. Dr. Asrulnizam Abd Mananf Collaborative Microelectronic Design Excellence Center (CEDEC) 013-4880232 eeasrulnizam@usm.my
- 2. We l e a d Learning Objectives • To describe deployment strategies for IoT systems • To explain the technical selection criteria for IoT Hardware Platform • To identify available Operating Systems for IoT • To differentiate among various Networking Technologies and their suitability for IoT 2 http://knowledgehub.cef-see.org/wp-content/uploads/2015/02/LearningObjectives.png
- 3. We l e a d Definitions • Dimensioning – Process of measuring either the area or the volume that an object occupies (Wikipedia) – Matching IoT use cases to appropriate hardware platforms, operating systems and networking technologies 3
- 4. We l e a d IoT Deployment Strategies • Deliberate (planned) – Controlled environments • e.g., homes, factories, offices • Ad Hoc (random) – Environmental monitoring, disaster response, etc. • Phased – Devices added to network over time to expand coverage • Remote locations, smart transportation – Active devices in network change over time • Devices with non-renewable power sources • Device failure in the field 4
- 5. We l e a d IoT Application Categories • Beacons and Identification – One-way communications (device to sink) – Location Beacons, Active Inventory Tags Active RFID devices, Bluetooth Low Energy (BLE) devices • Data collection and aggregation – Asymmetric two-way communications (mostly device to sink) – Environmental sensors, Smart utility meters WSN devices • Cyber Physical Systems – Symmetric two-way communications – Sensing and Actuation: Smart refrigerator, self-driving car General IoT devices 5
- 6. We l e a d Components of IoT Hardware Platform • Sensors/Inputs • Actuators/Outputs • Processing • Communications • Power Source Sensors/Inputs Actuators/ Outputs Processing Communications Power Source 6
- 7. We l e a d • Use-case dependent – E.g., Thermostat with room temperature sensor • Signal processing requirements – Scalar (e.g., temperature) or Complex (e.g., direction of movement) data – Raw or pre-processed data from sensor? • Sensing Frequency – No. of samples vs. time • Amount of data – Single reading or complex data • Unique or aggregate data? – On/off setting of a device vs. Temperature of a hall Sensors/ Inputs 7 Power Source Communications Processing Actuators/ Outputs Sensors/Inputs
- 8. We l e a d Actuators/Outputs • Use case dependent – E.g. Philips Hue lightbulb • Actuator controls LED light intensity and color • Open-loop vs. Closed-loop actuation – Does IoT device need to verify actuation status? – E.g., Fire alarm just activates alarm circuit – E.g., Thermostat needs to confirm heater/ air- conditioner has activated/ shut-off 8 Power Source Communications Processing Sensors/Inputs Actuators/ Outputs
- 9. We l e a d Processing • Microcontrollers (MCU) with various peripherals, RAM, ROM/EEPROM/Flash, power usage and size options are available – Prefer System on Chip (SoC) due to size and power constraints • Generally classified according to word sizes: 8/16/32 bits • Examples of MCU families: – 8051, PIC, AVR, MSP, MIPS, ColdFire, ARM, x86 • Examples of common MCU vendors: – Microchip, Atmel, TI, Freescale, NXP, Qualcomm, Intel • Examples of IoT Reference Boards – TI SDK (8051, ARM, MSP), Intel Edison (x86), Raspberry Pi (ARM), Beaglebone (ARM), NXP LPCxpresso (ARM) 9 Sensors/Inputs Power Source Communications Actuators/ Outputs Processing
- 10. We l e a d Data Processing Requirements • Data capturing and conditioning – Raw environmental data (temperature, humidity, air quality, etc.) • Data synthesis (from raw sensor input) – Accelerometer data -> no. of steps -> type of activity (walking, running, swimming, etc.) • Sensor fusion – Accelerometer + GPS + barometer – Distance travelled (walking vs. cycling), number of flights of stairs climbed, etc. 10 Sensors/Inputs Power Source Communications Actuators/ Outputs Processing
- 11. We l e a d Communications Processing Requirements • Data source (PUSH) – Periodic Scalar data, Alerts • Basic queries (PUSH-PULL) – SNMP, MQTT-S, CoAP • Interactive queries – Built-in HTTP server • IoT Relay / PAN Coordinator / Internet Gateway – Device Membership, Transmission Scheduling – Routing, Network Address Translation, Security Firewall 06/09/2017 (c) 2016-17 Tat-Chee Wan, USM 11 Sensors/Inputs Power Source Communications Actuators/ Outputs Processing
- 12. We l e a d Operating System Support for IoT (1) • Bare-bone IoT OS – Proprietary (non-TCP/IP) network stack • 802.15.4, Zigbee – Minimal TCP/IP network stack • Very limited capabilities (single active stream, no TCP buffering, etc.) • µIP Stack – None/ Custom/ Minimal OS • Raw-metal IoT programs • Hardware Platform specific (vendor provided?) • Contiki, TinyOS, LiteOS, etc. 12 Sensors/Inputs Power Source Communications Actuators/ Outputs Processing
- 13. We l e a d Operating System Support for IoT (2) • Lightweight IoT OS – Basic TCP/IP network stack • Lightweight IP (lwIP) library – Custom TCP/IP network stack • Various commercial & non-commercial vendors – Basic RTOS • Custom / Commercial & Non-commercial vendors • E.g., QNX, WindRiver, VxWorks, Nucleus, uCOS, FreeRTOS, etc. – IoT Centric • Contiki, RIOT, LiteOS, ThreadX, etc. 13 Sensors/Inputs Power Source Communications Actuators/ Outputs Processing
- 14. We l e a d Operating System Support for IoT (3) • Full OS – TCP/IP Stack provided by OS – Supports higher level networking functions • Internet Access, DHCP, NAT, firewall, etc. – RTOS • Commercial & Non-commercial vendors • E.g., QNX, WindRiver, VxWorks, Nucleus, uCOS, FreeTOS, etc. – Embedded Linux • uCLinux, RT Linux – Others (GUI-centric) • Android • Embedded Windows 14 Sensors/Inputs Power Source Communications Actuators/ Outputs Processing
- 15. We l e a d Microcontroller Dimensioning 15 8-bit MCU • Data Forwarding • Data Source / Basic Queries 16-bit MCU/ 32-bit Low Power (LP) MCU • Data synthesis • Basic Queries / Interactive Queries • IoT Relay / PAN Coordinator 32-bit MCU • Data synthesis • Sensor fusion • Interactive Queries • IoT Relay / PAN Controller / Internet Gateway 4-64 MIPs 1-4 KB RAM 1-128 KB ROM/Flash 8-80 MIPs 16-256 KB RAM 64-512 KB ROM/Flash 64-1000 MIPs 256 KB – 1 GB RAM 4-256 MB ROM/Flash Typical ranges for given IoT use cases http://www.futureelectronics.com/en/Microcontrollers/8-bit-microcontroller.aspx http://www.futureelectronics.com/en/Microcontrollers/16-bit-microcontroller.aspx http://www.futureelectronics.com/en/Microcontrollers/32-bit-microcontroller.aspx Sensors/Inputs Power Source Communications Actuators/ Outputs Processing
- 16. We l e a d Microcontroller Dimensioning 16 8-bit MCU 16-bit MCU/ 32-bit LP MCU 32-bit MCU 4-64 MIPs 1-4 KB RAM 1-128 KB ROM/Flash 8-80 MIPs 16-256 KB RAM 64-512 KB ROM/Flash 64-1000 MIPs 256 KB – 1 GB RAM 4-256 MB ROM/Flash Typical ranges for given IoT use cases http://savannah.nongnu.org/projects/lwip/ http://www.drdobbs.com/inside-the-uip-stack/184405971 TCP/IP: Lightweight IP Stack (lwIP) ~30 KB RAM; ~40 KB Code Custom TCP/IP Stack + HTTP server ~100 KB RAM; ~80 KB Code Non-TCP/IP based IoT Stack Embedded Linux (uCLinux, RT Linux) 8-32 MB RAM 4-16 MB Code IoT-centric OS 10 KB RAM; 30 KB Code TCP/IP: Micro IP Stack (µIP) ~1 KB RAM; ~6 KB Code Full RTOS 4-8 MB RAM; 2-4 MB Code Custom/Minimal RTOS 0.5 KB RAM; ~4 KB Code Basic RTOS 10 KB RAM; ~20 KB Code Custom TCP/IP Stack + HTTP server ~100 KB RAM; ~80 KB Code Default TCP/IP Stack Sensors/Inputs Power Source Communications Actuators/ Outputs Processing
- 17. We l e a d Communications Patterns • Type of traffic – Data rate (in terms of bps) – Reliable/Unreliable transmission – Quality of Service (QoS) requirements • Traffic Patterns – Many-to-one (data monitoring) – One-to-many (data broadcast) – Peer-to-peer (M2M applications) • Distance / Coverage Area – PAN: Indoor (1 – 25 m) – LAN: Indoor / NAN: Outdoors (25 m – 1000 m) – MAN: Outdoors / WAN: Rural (1 km – 20 km) 17 Sensors/Inputs Power Source Actuators/ Outputs Processing Communications
- 18. We l e a d Factors Affecting Communications • Battery-operated Devices – Low hardware complexity (device limitations) – Low transmit power – Low protocol overheads – Unique and large device identification space • Choice of Networking Technology – Coverage/ Transmission Distance – Duty cycle – Number of devices in Network – Network Topology and MAC Configuration • Data encryption and authentication – Processing overhead – SoC support for Encryption algorithm 18 Sensors/Inputs Power Source Actuators/ Outputs Processing Communications
- 19. We l e a d Communications Bandwidth Dimensioning 19 Very Low Bit Rates • Proprietary (SigFox, LoRa) • Two-way Radio (TETRA) • Cellular (EC-GSM) Low Bit Rates • 802.15.4 • Cellular (LTE-M, NB-IoT) • 802.15.4g (WiSUN) • Bluetooth Low Energy • Z-Wave Moderate/High Bit Rates • WiFi (802.11 Family) • Cellular (LTE) • Max 1 Mbps • Bluetooth Low Energy • 802.15.4g (WiSUN) • LTE-M < 1 – 50 kbps 10 – 250 kbps 1 Mbps + Sensors/Inputs Power Source Actuators/ Outputs Processing Communications
- 20. We l e a d Communications Range Dimensioning 20 PAN • Active RFID • Bluetooth Low Energy • 802.15.4 (Zigbee) • Z-Wave LAN/NAN • WiFi (802.11 a,b,g,n,ac) • Long Range WiFi (802.11 af, ah) • WAVE (802.11p) • WiSUN (802.15.4g) MAN/WAN • 802.11ah • Two-way Radio (TETRA) • Cellular (GSM, LTE) • Cellular (LTE-M, NB-IoT) • Proprietary (Sigfox, LoRa) 1 – 25 m 25 – 1000 m 1 – 20 km Sensors/Inputs Power Source Actuators/ Outputs Processing Communications
- 21. We l e a d Power Sources • Dependent on communications requirements – Transmission uses significant energy • Non-Rechargeable Battery • Rechargeable Battery • Renewable energy source – Recharging of battery (solar, wind, etc.) – Energy harvesting • Uninterrupted Power Supply (UPS) with Mains Power 21 Sensors/Inputs Actuators/ Outputs Processing Communications Power Source
- 22. We l e a d Power Source Dimensioning 22 Trickle Load • Non-rechargeable Battery • Energy Harvesting Low Load • Coin cell • Non-rechargeable Battery • Rechargeable Battery • Renewable Power Source with Rechargeable Battery High Load • Rechargeable Battery • UPS with Mains Power 5 – 10 years? Weeks – Years Hours – Days Typical ranges for given IoT use cases Sensors/Inputs Actuators/ Outputs Processing Communications Power Source
- 23. We l e a d References • Arshdeep Bahga, Vijay Madisetti, Internet of Things (A Hands-on-Approach), VPT, 2014. ISBN 978- 0996025515 • Adrian McEwen, Hakim Cassimally, Designing the Internet of Things, Wiley, 2013. ISBN 978-1118430620 • Micriµm, Inc., “IoT for Embedded Systems: The New Industrial Revolution,” White Papers. https://www.micrium.com/iot/overview/ • T. N. B. Anh and S. L. Tan, "Real-Time Operating Systems for Small Microcontrollers," IEEE Micro, vol. 29, no. 5, pp. 30-45, Sept.-Oct. 2009. http://dx.doi.org/10.1109/MM.2009.86 • Milinković, Aleksandar, Stevan Milinković, and Ljubomir Lazić. "Choosing the right RTOS for IoT platform." Infoteh Jahorina, Vol. 14, Mar. 2015 • Bernard Cole, “Picking the Right RTOS for your Next-Gen Embedded IoT Design,” Online Article, Embedded.com. URL: http://www.embedded.com/electronics-blogs/cole-bin/4431815/Picking-the-right- RTOS-for-your-next-gen-embedded-IoT-design • Table of RTOS: https://en.wikipedia.org/wiki/Comparison_of_real-time_operating_systems • Contiki OS: http://www.contiki-os.org/ • RIOT: https://www.riot-os.org/ • LiteOS: http://www.liteos.net/ • uCLinux: http://www.uclinux.org/ • RT Linux: https://rt.wiki.kernel.org/index.php/Main_Page • C. Buratti, A. Conti, D. Dardari, R. Verdone, “An Overview on Wireless Sensor Networks Technology and Evolution,” Sensors. 2009; Vol. 9, No. 9, pp. 6869-6896. http://dx.doi.org/10.3390/s90906869 23
Editor's Notes
- This module is primarily focused on helping us understand the tradeoffs involved in choosing relevant hardware, software and networking components for designing IoT systems.
- The specific use of the term Dimensioning refers to physical measurements of the object of interest Dimensioning in this module refers to choosing appropriate sizes of system components to meet the requirements of the IoT System. We will use three basic categories, small, medium and large, as rule of thumb design criteria for each component being studied. More fine-grained categories are of course possible, but that is overkill for our analysis
- The first consideration for IoT Systems design is the type of problem and how the devices would be deployed in the field Deliberate or planned deployment affords the most in terms of optimization opportunities and the choice of components can be determined precisely if necessary Examples of planned deployment involve indoor or controlled environments where placement locations and power sources can be selected, and outdoor deployments such as precision agriculture. Random or ad hoc deployment offers the least opportunities for optimization, since non-ideal placement of devices will greatly affect the performance and reliability of the IoT system Devices have to be overprovisioned in terms of the energy storage, processing capabilities and network transmission ranges and bandwidths required Examples of ad hoc deployment include environmental monitoring during emergencies such as flooding and forest fires, disaster response where for search and rescue operations, etc. Phased deployment target IoT systems that need to operate over long durations but which offer minimal opportunity or high cost to perform maintenance and servicing of individual devices (e.g., battery replacement is not viable). Devices may be added to expand coverage areas, or else replace non-functional devices due to battery exhaustion and device failures Since active devices and their specific locations will change over time, in-field device reconfiguration and firmware updates should be supported. The system should also be dynamically configurable to support the addition/removal of IoT devices
- The types of IoT applications can generally be classified as follows: Beacons for Advertisment and Identification These IoT devices are mainly broadcast only, and do not interact (much) with other devices Examples are Active RFID Tags, and Bluetooth Low Energy (BLE) devices used for advertisment and indoor location determination Sensors for data collection Data transmission is mainly from sensors to Gateway (sink), hence asymmetric since most of the data is flowing towards the sink Examples include smart utility meters which report utility usage to the central data collection center, environment sensors, etc. Closed Loop Control and Cyber Physical Systems Found in Cyber Physical Systems (CPS) which require feedback from sensors to enable the controller to send commands to the actuators and other IoT devices to perform its function Data communications protocols and latency are more critical in such situations, including QoS support The capabilities and system performance of this category of IoT devices is higher than for the other categories, since they have to both perform data collection as well as respond in a timely manner to inputs from the control center
- A typical IoT device is built from a hardware platform which provide the following functions: Inputs and Sensors for data collection Outputs and Actuators for interacting with the environment or other devices Processing capability for performing input normalization, signal conditioning, data storage and event detection Communications module for sending and receiving data from Controller or Monitoring station, or else from the Internet via Gateways Power Source to operate the device, whether non-renewable or renewable This discussion will focus on the processing and communications components that makes up a typical IoT hardware platform
- The type of sensors that should be included in the IoT device is use-case dependent Sensors may return basic (scalar) data, such as temperature, humidity, light intensity, sound level, etc. to vector or complex data, such as acceleration, direction of movement, signal waveforms, etc. Depending on whether the sensor returns raw (unprocessed) data, or pre-processed data such as event-triggered inputs, the processor may have to perform further signal conditioning The number of samples (sensing frequency) will also affect processor dimensioning The amount of data to be collected, and transmitted per time interval will affect device storage and communications dimensioning Whether each data point for individual devices need to be separately stored, or if it is sufficient to store the aggregated value of data from multiple devices will also affect processing, storage and communications dimensioning
- Similarly, actuators and outputs are use-case dependent Some actuation is binary (on-off) while others may include selection/specification of a range of possible output values (e.g., different color/intensity settings) The requirement for open-loop or closed-loop actuation affect input/sensors, processor and communications dimensioning Open loop actuation just needs to initiate the actuator action Closed loop actuation requires both initiation of the actuator as well as checking/sensing of the results of the actuation The control response speed for closed loop actuation affects processor dimensioning, if the control algorithm is complex Communications may be affected by the need to perform remote real-time monitoring of the closed-loop actuation process
- Processing is often done using Microcontrollers (MCU) which incorporate all or most of the required support circuits in a single package. Basic microcontroller features include built-in RAM, non-volatile storage (ROM/EEPROM/Flash), peripheral logic support, and even communications modules The trend is to use System on Chip (SoC) MCU devices to minimize size and power usage since IoT devices are mostly battery operated MCU for IoT applications range from 8-bit to 32-bit devices depending on processing requirements There are numerous MCU designs and vendors, but the major MCU families are 8051 (originated from Intel, but available from multiple vendors), PIC (Microchip), AVR (Atmel), MSP (TI), MIPS (various vendors), ColdFire (Freescale), ARM (various vendors, include NXP, Qualcomm), and x86 (Intel) 8-bit MCUs are mature and been available commercially for a long time, so tools and supporting software ecosystem are widely available. Furthermore, 8-bit MCUs fabricated on up-to-date silicon processes are much more energy efficient compared with older generations of 8-bit devices and even modern higher end (32-bit) devices. This is important in terms of battery capacity and extensive operational lifetimes for IoT devices Nonetheless, the trend is moving towards 32-bit MCUs due to the availability of mature Real Time Operating Systems (RTOS) and increasing trend of adding Internet Protocol support and other services directly on the device Various IoT reference boards are available from the major vendors. The list given here are just the most common vendors for the IoT space
- The MCU processing capability depends on the workload placed on it Minimally, the workload include sensor input capturing, and signal conditioning in preparation for forwarding data to the sink Raw inputs may have noise and need to be filtered to remove invalid input values Some inputs may be presented as analog voltages corresponding to some real world input (e.g., voltage in response to light intensity), that must be converted into meaningful units (e.g., lux) for forwarding to the sink Data synthesis involves converting raw sensor inputs into higher level data A fitness tracker has an accelerometer that measures the changes in acceleration due to various activities The accelerometer data by itself cannot provide information regarding the number of steps taken or the type of activity Data synthesis processes the raw sensor input to extract the desired data (steps, activity type) Sensor fusion takes inputs from multiple sensors to derive new data values Calorie expenditure from exercise depends on the type of exercise and duration and distance travelled. E.g., combining inputs from the accelerometer, GPS and barometer sensors can provide this data All these tasks involve various degree of processing resources depending on the algorithms used. E.g., Face detection from an image sensor will use more processing resources compared with measuring the temperature from a temperature sensor
- Another set of tasks requiring processor resources is the communications stack IoT devices have inherent communications tasks for sending data to the sink, as well as responding to data queries, configuration updates, and other commands from the sink The communications patterns can be classified as: PUSH: data is sent by the IoT device automatically based on set schedule (periodic), or triggered by specific events (Alerts). PUSH-PULL: Sink or monitoring station requests for data based on specific criteria (PULL pattern). Typically these communications are based on established application layer protocols such as SNMP, MQTT-S, or CoAP. IoT devices can initiate multiple data message transmissions based on a given request (PUSH pattern) Interactive: IoT device interact directly with user to respond to data queries via web-based protocols (HTTP, etc.) In such situations, a built-in web service is running directly on the IoT device (This requires a good power source, since supporting HTTP queries directly incurs processing overheads, as well as limiting opportunities for the IoT device to enter sleep mode) Devices that act as Relays, Coordinators and Gateways have additional communications tasks Node membership management (join/leave/reject) and data transmission scheduling Path discovery, maintenance and routing management for connected devices via routing protocols Gateway and proxy services to interface with external networks (e.g., supporting Neighborhood Discovery for IPv6 network, packet forwarding and conversion (6LoWPAN, Network Address Translation, etc.)
- The discussion here is based on small/medium/large classification of OS requirements, and is inherently tied to the MCU platform under consideration Desktop based operating systems (OS) are ’extra large,’ and not suitable for IoT devices due to: OS Size and memory & processing requirements: Modern OS assumes multi-GB of RAM and extensive permanent storage (10’s of GB) 8-bit MCUs cannot provide the RAM buffers required by TCP/IP network stacks developed for desktop OSes In the past, embedded systems development was based on custom software running on ‘bare metal’, without any portable operating system services to support tasks such as scheduling, I/O and communications However, due to the standardization of hardware platforms and Internet connectivity requirements, bare metal systems are not viable from commercial and development standpoint Typically, Bare-bone OSes for IoT devices target 8-bit MCUs, providing only essential support for task scheduling, I/O drivers and interrupt processing, and little or no memory management. A lot of custom OSes have been developed, both by MCU vendors as hardware platform specific OSes, and RTOS vendors targeting multiple MCUs Bare-bone OSes assume single tasks or minimal number of tasks to be executed concurrently Networking support is focused on non-IP based protocols, such as 802.15.4, Zigbee or other proprietary network stacks which require very small memory footprints Nonetheless, very minimal TCP/IP network support such as µIP, has been implemented on 8-bit MCUs, with very minimal support single stream connections running in application space Recently, efforts to create de-facto OS platforms have resulted in Open Source OS such as Contiki, TinyOS, and LiteOS, which began as research projects and subsequently enhanced to have cross-platform support from multiple vendors
- Lightweight IoT OS belongs to the Medium category In addition to basic OS functions such as scheduling, I/O drivers and Interrupt processing, and mutual exclusion primitives, Lightweight IoT OSes support memory management and provide kernel vs. user space separation, process threads, inter-process communications as well as process synchronization support They target 16-bit or 32-bit MCUs and have the largest number of commercial and non-commercial offerings due to historical reasons, mainly focused on the extensive real-time embedded systems market Most of these embedded RTOS can be used for IoT applications given the appropriate networking support Networking support may provided by the RTOS, nonetheless they are optional and do not need to be included unless required Alternate network stacks include Lightweight IP Library (lwIP), and multiple commercial and non-commercial offerings for specific hardware platforms, feature sets and procotol compatibility requirements Various RTOS offerings include optional Graphical User Interface modules to build complete embedded systems with user interaction requirements Examples of commercial RTOS vendors include QNX (automotive sector), WindRiver, VxWorks, Nucleus and uCOS Examples of non-commercial RTOSes include FreeRTOS and its variants IoT centric RTOS which focus on supporting IoT related communication protocols include: Contiki, RIOT, and ThreadX
- Full IoT OSes belong to the Large category Target MCUs are 32-bit devices acting as Access Points, Coordinators and Internet Gateways In addition to the hardware and process management features, Full IoT OSes have to support relevant IoT as well as TCP/IP protocols for interacting with external networks Features such as Dynamic Host Configuration Protocol (DHCP), Network Address Translation (NAT), Domain Name Service (DNS) host name resolution, security firewalls, IPv6-IPv4 protocol tunneling, etc. should be supported by the Full IoT OS Due to their modular nature, many commercial RTOS offerings described previously also qualify as Full IoT OSes The major focus today is on embedded Linux as a Full IoT OS, due to its widespread adoption in place of commercial embedded OS uCLinux is a reduced version of Linux running on many embedded platforms such as APs and SOHO routers Although Linux is used as an Embedded OS, it does not have actual Real Time support. Real Time (RT) Linux was developed to address this requirement Linux-based IoT OS is competing with commercial RTOS for market share due to the large and open ecosystem The following OSes are not strictly for IoT applications, but is found in various high end devices due to their popularity Android is Google’s user-space libraries built on top of a Linux kernel Embedded Windows from Microsoft is designed for use in embedded systems such as Media Centers
- The specific configurations and options for each MCU varies and depends on the manufacturer, since new variants are released frequently The specific combination of I/O logic, memory and clock speeds should be tailored to the use case under consideration The general classifications of processing power (Millions of Instructions Per Second MIPS), volatile memory (RAM), and non-volatile memory (ROM/EEPROM/Flash) are given as guidelines regarding capabilities of the different classes of MCUs The feature set of each MCU class is provided as a guideline regarding what type of general features that can be expected from the particular type of device: 8-bit MCUs are generally data sources 16-bit and low power 32-bit MCUs can perform more advanced processing and network coordination functions Higher end 32-bit MCUs can be used for high level sensor data processing and aggregation, as well as support Gateway and Controller functions The choice of MCU is dependent on the data and communications processing requirements (discussed previously), and also the available power sources The metric used today is not just Performance per Clock (measured as MIPS), but Performance per Watt (MIPS/Watt) which measures how much work is done for the least energy usage More efficient MCUs that can address the given IoT use-cases are preferred since batteries have limited energy storage capacities, and IoT use-cases are constrained by battery life
- Here the type of OS and volatile/non-volatile memory requirements to support them are compared The core OS footprint refers to the minimal amount of RAM and storage needed to even run the OS. Additional storage and RAM will be needed for the actual IoT application Due to the very limited RAM and storage provided by 8-bit MCUs, support for IP-based network protocols is not recommended Although basic IP protocol response can be implemented, the 8-bit MCU does not support error recovery and advanced transport protocol features well In addition to the limited protocol support, security considerations such as the use of encryption is not well addressed by 8-bit MCUs Although 16-bit MCUs have been in the market for a long time, their niche is being overtaken by Low Power 32-bit MCUs manufactured on up-to-date silicon processes The advantage of using identical instruction sets with established 32-bit MCU architectures make Low Power 32-bit MCUs attractive for the mid-tier category The advantage of using Lower Power 32-bit MCUs is that if there is a need to scale the MCU up, switching to a 32-bit MCU from the same family is much easier and reduces development time
- The choice of communications subsystem for IoT devices has to account for the type of traffic, as well as traffic patterns Traffic can be classified using basic QoS metrics, i.e., data rate (measured in bits per second), delay requirements (mainly one-way end-to-end delay), packet loss rate (measured in probability of packet lost over total packets transmitted), as well as whether the data needs to be received in its entirety without error or otherwise Traffic patterns are based on the IoT use-case. Examples are data monitoring applications which consists of many-to-one transmissions, data broadcast applications which have one-to-many transmissions, as well as peer-to-peer which is used primarily by Machine to Machine (M2M) communications The third consideration in choice of communications subsystem relates to the distance and coverage area under consideration The distances are divided into the following categories (there are overlaps in definitions; the distances given are generalized): Personal Area Network (PAN) which are mostly indoor coverage from 1 to 25 m Local Area Network (LAN) which can be indoor or Neighborhood Area Network (NAN) outdoor coverage from 25 m to 1000 m Metropolitan Area Network (MAN), and Wide Area Network (WAN) which covers 1 km to 20 km
- Communications have an even larger impact on energy consumption compared with the MCU The design criteria for battery operated devices is to favor: Low hardware complexity, since low end IoT devices cannot support complex communications protocols that depend on advanced hardware features (e.g., MIMO) Low transmission power: Transmission Power is directly dependent on energy consumption, the higher the transmission power, the greater the energy requirement Low protocol overheads: ‘Chatty’ Protocols with significant handshaking will consume a lot of energy. Simpler protocols which minimize the number of frames or messages sent are preferred A large number of devices supported via unique device identifiers. This primarily affects IP-based communications; IPv4 lacks sufficient number of unique addresses, whereas IPv6 is able to support a significantly larger number of devices with unique IPv6 addresses Choice of Networking Technology The coverage area is important. E.g., 802.15.4 was designed to operate in low power mode over relatively short distances. 802.15.4 by itself would not be suitable for rural SCADA applications The duty cycle of the MAC protocol affects the device lifetime. E. g., the Active Period for 802.15.4 compared to the Beacon Interval affects the percentage of time devices are awake vs. asleep The supported number of devices in the network differs. E.g., classical Bluetooth can only support 7 devices + Master in a given Piconet, whereas 802.15.4 can support tens to hundreds of devices The topology and MAC protocol behavior affects battery life. E.g., Centralized PAN-Coordinator 802.15.4 network using Guaranteed Time Slot (GTS) polling, enables devices to sleep when not being polled, whereas Decentralized 802.15.4 Ad-Hoc mode require devices to be active for longer Data Encryption and Authentication requirements Security of data transmission depends on encryption protocols used Advanced Encryption Standard (AES) needs dedicated hardware support to operate efficiently SoCs with built-in AES cryptography module would be preferred for supporting such applications Authentication protocols can require multiple message exchanges. Protocols with minimal number of exchanges are preferred in IoT applications
- The first consideration for selection of networking technology is the minimum data rate needed for the IoT use case This maximum bit rate supported by a given technology needs to be balanced with the transmission range requirements (discussed in the next slide) The available bandwidths are divided into low, medium and high bit rate categories There is some overlap due to the available MAC technology for Very Low Bit Rate (1-50 kbps) and Low Bit Rate (10-250 kbps) technologies To limit the number of categories to three (in line with the discussion of the other parameters), the moderate and high bit rate technologies are grouped together. Moderate Bit Rate technologies support up to 1 Mbps, whereas High Bit Rate technologies support even higher data xrates Although the Moderate/High Bit Rate technologies can support lower bit rate requirements, they may require more power to operate and may therefore be less energy efficient compared with technologies designed for the given bit rates
- Transmission range is directly related to the transmit power used The higher the transmit power, the further the reach The range is divided into 3 categories: Personal Area Networks (PAN) of 1 to 25 m of transmission radius Local Area Networks (LAN) and Neighborhood Area Networks (NAN) which cover from 25 m to 1000 m of transmission radius Metropolitan Area Networks (MAN) and Wide Area Networks (WAN) wich cover 1 to 20 km of transmission radius Typically selection of suitable networking technology is done by plotting the data rate requirements and distance requirements on a two-dimensional graph and determining which technologies fit the given use case Hybrid network topologies such as using short-range technology for data sources communicating with IoT Gateways equipped with long-range networking technology to forward the data towards the sink can also be implemented to optimize the energy consumption and cost of the system
- The largest impact on energy requirements of IoT devices is the communications requirement, since data transmission uses significant amount of energy Choices of power sources range from non-renewal energy sources using non-rechargeable batteries, to renewable energy sources such as rechargeable batteries and energy harvesting from the environment Non-rechargeable batteries generally have higher energy capacity compared with rechargeable batteries Typically used where devices are low cost and easily replaceable or expendable, or else difficult to access (e.g., environmental sensors in remote areas) Rechargeable batteries are more environmentally friendly in terms of resource consumption, but still need replacement when the number of recharging cycles reach the lifecycle of the batteries Renewable energy sources generally refer to solar, wind and other technologies that can convert energy directly to electricity without the use of chemical reactions Nonetheless, renewable energy sources are not dependable enough to power IoT devices without additional rechargeable batteries to smooth out the availability periods Generally, renewable energy sources are used to replenish the rechargeable batteries’ energy store Energy Harvesting is an emerging technology where energy is extracted from ambient energy such as RF transmissions or kinetic energy to power very low power devices (µA) For devices which consume significant energy, mains power with Uninterrupted Power Supplies (UPS) should be used to minimize disruptions due to power supply interruptions
- The choice of power sources is dependent on the energy consumption rate of the device, as well as the capacity of the battery The energy consumption rate has been separated into three categories: Trickle Loads which consume very little energy (in the range of µA), where the working lifespan of the device is measured in multiple number of years (5-10 years is projected battery lifespan, no known commercial product with this capability have been demonstrated) Low Loads which consume 10’s to 100’s of mA, and are expected to last weeks to years on non-renewable batteries High Loads which consume 100’s of mA and more, than can operate for hours to days on a single charge Energy Harvesting is being pursued as a major energy source for trickle load devices Low load devices can either use coin cells, non-rechargeable batteries, or else rechargeable batteries with renewable power source to support their operational lifespans High load devices mostly depend on rechargeable lithium batteries or mains power with UPS battery backup for continued operation