IoT Device Platform - ARTIK & IoT Protocols - 2017. 11. 8 최 욱 S/W 센터 (반도체연구소) 삼성전자 1 1 Outline 1. The Era of IoT 2. IoT Value 3. IoT Architecture 4. Samsung ARTIK 5. IoT Platform 6. IoT Protocols 2 4차 산업혁명… 확산 & 전환 3 Amazon ….. 4 Amazon ….. ■ Amazon Go 5 Tesla … ■ Electric Car manufacturer .. That is all? Gigafactory in Nevada, US Solar roof tile from Solarcity 6 Tesla … ■ Unveiling a new solar panel 7 IoT Hype Cycle Gartner Hyper Cycle 8 The Era of IoT - Why Now? ■ Internet Connectivity Evolution From Human-centric to Device-centric 9 The Era of IoT – IIoT & CIoT [Ref] Talk on Industrial Internet of Things @ Intelligent systems tech forum 2014 10 IoT Value – Moore’s Law ■ Gordon Moore predicted that transistor density is doubled every 2 years ■ Moore’s law has been driving IoT evolution from technical perspective… Performance Cost Moore’s Law - A logarithmic scale on the Y-axis processor evolution is following Moore’s law Mobile devices and machine-to-machine (M2M) communication modules are following similar performance and cost curves!!! Hardware miniaturization, decreasing sensor costs, and ambient device connectivity 11 IoT Value – Metcalfe’s Law ■ Targeting a value-driven business to meet its growth expectations ■ The network value grows by “the square of the number of network nodes” while costs follow a more or less linear function (by Bob Metcalfe, 3Com co-founder) N: # of services M: # of devices MetCalfe’s Law Metcalfe’s law is really about network growth, value creation, and customer acquisition rather than about technological innovation 12 IoT Conceptual Architecture ■ Layered architecture consisting of Application, Network, Edge, and Perception layers Clouds Data Application Layer Analytics Services Internet Network Layer High-value devices Gateway/Hub Edge Layer Things Perception Layer (Sensors, Intelligence Appliances…) Constrained devices 13 IoT Use Case Scenario - What a Diverse! ■ Various device architectures, service scenarios and use cases! – Various functions, standards, protocols, APIs ■ One platform dominates all, possible or not possible? – Flexible platform architecture for heterogeneity 14 IoT Platforms – Eco-system ■ IoT is a biz area that creates value out of data collected from “everything connected” must provide various connectivity & data collection technology and eco-system People Eco-system Things Connection with 데이터 various things, env. Internet of Everything !! How can we get everything connected and get some meaningful value out of it? 15 Types of IoT Platforms Cloud Platform Cloud Services Communications Storage / Database AI Analytics Device Management Edge Platform Edge Computing Edge Intelligence Security Gateway Data Collection Security of Messaging Communications Device Platform Data Gathering People & Device & Controllers Connectivity Things BSP Ecosystem 16 Platform Definition ■ Platform Technology (from Wikipedia) – “제품” 개발을 가능하게 하는 기술이나, 현재 또는 미래의 개발을 지원하는 프로세스 17 17/8 Open Platform ■ 필요기능의 통합 플랫폼 개발의 끝이 아니다! – “계속적으로 유용”하고 사용자 친화적인 경험 제공 ■ 어떠한 플랫폼도 똑같이 만들어지지 않는다! – 훨씬 더 강력하고 유용하며 “인기 있는 플랫폼”이 있기 마련 ■ 고객을 알아야 강력한 Platform을 만든다! – 플랫폼 오픈화를 통한 “소통 채널” 극대화! Do you know What your customers want? Evangelize Platform = “Technology + Ecosystem” Platform 사용자 Ecosystem = “Community + Environment” Feedbacks Promote Evangelize Feedback 사용자 + Contributors + Partners Contribute Collaborate Evangelize Contributors Partners 18 Prospective IoT SW Developers ■ Current status of SW development resources - Android developers > Web developers >> Embedded developers 19 Samsung IoT ARTIK Family ■ Support E2E IoT use case scenario from sensor device to cloud Clouds 4xCortex-A9/GPU 8xCortex-A53/GPU 512MB|1GB/4GB 1GB/4GB ARTIK 5X0 ARTIK 710 Rich devices ARTIK 05x (WiFi) Cortex-R4/ 1.4MB/8MB ARTIK 030 (ZigBee) ARTIK 020 (BLE) Constrained Cortex-M4/ Cortex-M4/ devices 32KB/256KB 32KB/256KB [Ref.] https://www.artik.io 20 ARTIK Key Differentiations 21 ARTIK Security ■ Providing differentiated end-to-end security solution ■ Proven security technologies combining HW and SW security [Ref.] https://www.tizen.org/sites/default/files/event/a1_tdc15_artik_-_the_ultimate_platform_solution_for_iot.pdf 22 ARTIK Cloud ■ Connect devices to be analyzed and visualized anytime, anywhere! [Ref.] https://www.tizen.org/sites/default/files/event/a1_tdc15_artik_-_the_ultimate_platform_solution_for_iot.pdf 23 Platform Requirements AS-IS TO-BE • Fragmented API • Consistent API - Inconsistent Dev Exp. because of various API concepts - Providing consistent & developer friendly API & styles Excellent Dev. Exp. to increase usability, productivity, Decreasing usability, productivity, accessibility accessibility • Coarse-grained Build Configurability • Fine-grained Build Configurability - Impossible image build with features tailored only for - Providing build-time feature configurability for OS, device spec. or user-specific use cases network stack, connectivity, Services Over featuring and unnecessary memory usage Optimal memory footprint Already read the sensor Easy to develop services data. How do I upload it using one set of to the Cloud? consistent APIs !!! ARK Platform Device ML BP Security Device ML BP Security Platform API call ARK API Release 24 Platform Requirements . ARTIK device use-case requirement specific image build . Build-time optimal memory footprint by selecting necessary features for OS, Network Stack, Connectivity, Service Framework, etc. Platform Device-specific Memory Footprint - Consisting of component modules: OS, Network Stack , Service Framework, Protocols, Lib. [Low-End] 020 No Thread OS BLE Image CoAP App Sensor Cloud Footprint: ~수십KB Frw Frw Frw GPIO …. ML Lib IoTivity LWM2M [Mid-End] Multi Thread OS 053 Build-time WiFi Configuration CoAP Image CoAP IP HTTP UDP Footprint: ~수백KB GPIO PWM …. BLE Wi-Fi MQTT [High-End] Multi Thread OS WiFi CoAP Image OS TCP/UDP Footprint: ~수천KB GPIO …. 25 Characteristics of TizenRT ■ RTOS-based lightweight platform ■ Fit into constrained devices with Cortex-M/R MPU and less than 2 MB RAM and 16 MB Flash. ■ Cannot load additional modules at runtime ■ POSIX API, BSD Socket API, Shell, and Kconfig build configuration ■ Adopt lightweight JavaScript environment that consists of JerryScript and IoT.js ■ Public open: May 10, 2017 https://github.com/Samsung/TizenRT 26 Platform API Classification ■ Proprietary vs. POSIX - Proprietary (Custom API): not compatible with other OSs - POSIX (Open API): IEEE Standard OS Interface (Linux/Windows/iOS/TizenRT) Ex Advantages Disadvantages Examples • Small Memory Size • No code compatibility and • FreeRTOS • Fast Execution reusability (Esp. Linux-based code • RIOT Proprietary • Quick Interrupt Response reuse) • Zephyr API-based - Customer app. redevelopment - Retraining for new platform • Code compatibility and reuse • Real-time Options • ThreadX - existing Linux code reuse Unpredictable interrupt latency & • QNX POSIX - Almost zero porting effort jitter • VxWorks API-based • Existing Linux • Slow Booting Time • Integrity customer/developer-oriented • Large Memory Size • LynxOS • TizenRT 27 TizenRT Architecture ■ NuttX-based RTOS, called TinyAra ■ Consisting of OS, Core components, framework, and application layers ■ IPv4/IPv6 network stack, file system, lightweight database, device monitor, and IoT protocols (IoTivity, MQTT, CoAP, and LWM2M) https://source.tizen.org/documentation/tizen-rt 28 MQTT (Message Queue Telemetry Transport) Official web site : http://mqtt.org M2Mqtt project : http://www.m2mqtt.net Mosquitto : http://mosquitto.org HiveMQ : http://www.hivemq.com MQTT An implementer’s perspective : http://bit.ly/1koMZLF MQTT Another implementer’s perspective : http://bit.ly/1rHDnAN 29 Characteristics ■ Easy Messaging Protocol ■ Minimal Overhead ■ Data agnostic ■ Publish / Subscribe ■ Push instead Pull ■ Reliable even when used with unreliable networks ■ Constrained Devices ■ Low bandwidth, high latency 30 MQTT Architecture ■ Broker-based communications Publisher Subscriber Broker (Source) (Sink) Subscribe (topic) Publish (topic, info) Publish (topic, info) 31 MQTT Brokering Basic Terms ■ Broker: The broker accepts messages from clients and then delivers them to any interested clients. – Key component of MQTT ■ Client: A “device” that either publishes a message to a topic, subscribes to a topic, or both ■ Topic: A namespace (or place) for messages on the broker. Clients subscribe and publish to a topic ■ Publish: A client sending a message to the broker, using a topic name ■ Subscribe: A client tells the broker which topics interest it. Once subscribed, the broker sends messages published to that topic. A client can subscribe to multiple topics ■ Unsubscribe: Tell the broker you are bored with this topic. In other words, the broker will stop sending messages on this topic. 32 MQTT Advantages in IoT . MQTT packet can be as small as 2 bytes compared to HTTP. MQTT uses binary messages to exchange information with a low overhead . Compared to HTTP which requires multiple POST actions to distribute a message to more than one client, MQTT distributes a message, or, only to a client interested . MQTT is inherently 1 to many communication . Publish-subscriber paradigm in contrast to HTTP based on request/response paradigm . Asynchronous protocol, that means that it does not block the client while it waits for the message no need to be connected at the same time (server & Client). HTTP protocol, that is mainly a synchronous protocol . Highly scalable 33 MQTT QoS ■ MQTT client sets QoS and broker honors the QoS level on each client end