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
■ Three levels of QoS . QoS Level 0: At most once delivery (non-persistent) No retry semantics are defined in the protocol
. QoS Level 1: At least once delivery (persistent, duplicates possible) Server acknowledges with a PUBACK Message is resent with DUP bit set if PUBACK is not received
34 MQTT QoS
■ Three levels of QoS . QoS Level 2: Exactly once delivery (persistent) Two stage processes to ensure there is no duplicate message delivery Server acknowledges with a PUBREC Client releases message with a PUBREL Server acknowledges completion with a PUBCOMP
https://www.slideshare.net/Hamdamboy/message-queuing-telemetry-transport-mqtt
35 CoAP (Constrained Application Protocol)
Coap Technology : http://coap.technology Official draft : https://datatracker.ietf.org/doc/rfc7252/ CoRE Link format : http://tools.ietf.org/html/rfc6690#section-3.1 CoAPSharp : http://www.coapsharp.com Copper : https://github.com/mkovatsc/Copper
36 Characteristics
■ IETF lightweight messaging Standard for constrained devices and networks
■ Client/server protocol
■ One-to-one “request/response” interaction model
■ Interoperate with HTTP and RESTful protocol (GET, POST, PUT, DEPETE)
■ Ideal for Specialized for M2M applications
■ Compact 4-byte header
■ UDP, SMS, (TCP) Support
■ Strong DTLS security
■ Asynchronous communication
■ Build-in discovery
http://www.electronicdesign.com/iot/mqtt-and-coap-underlying-protocols-iot
37 CoAP Architecture
■ Based on REST Architecture
■ Unlike HTTP based protocols, CoAP operates over UDP
■ To compensate for the unreliability of UDP, CoAP redefines a retransmission mechanism
38 Messaging Model
■ Supports 4 message types: CON (Confirmable), NON (Non-confirmable), ACK (Acknowledgement), RST (Reset) ■ Reliable message transport: ACK with the same message ID If fail to process message, responses by replacing ACK with RST
■ Unreliable message transport: using NON message type with message ID If fail to process message, server replies RST
39 Request/Response Model
■ Piggy-backed: ACK contain response message (identified by token)
■ Separate response Server not ready to response: empty ACK Server ready to response: a new CON, then client replies with ACK
40 Request/Response Model
■ Non Confirmable Request and response Client sends NON type message indicating no need to confirm Sever resend a NON type message with response
41 CoAP Security
■ DTLS for CoAP security Considers all of integrity, authentication, and confidentiality DTLS in application layer protects end-to-end communication
■ To protect CoAP transmission, DTLS provides three types of security Authentication Secure channel Key management
42 IoTivity Open Connectivity Foundation
IoTivity Open Source Community: https://openconnectivity.org Open Connectivity Foundation: https://openconnectivity.org/
43 OCF and IoTivity Relationship
Specifications & Open Source ready simultaneously
OCF Specifications: https://openconnectivity.org/developer/specifications IoTivity Open source: https://www.iotivity.org/downloads/iotivity-1.3.0
44 OCF (Open Connectivity Foundation)
■ Why OCF? – Dilemma of current IoT world . Fragmentation, Fragmentation, Fragmentation !! (No universal language for IoT) »Device makerLimiting market, increasing costs »End usersAlways check compatibility & interoperability ■ OIC (Open Interconnect Consortium) – Samsung & Intel proposed ■ OCF (Open Connectivity Foundation) – Board members (Qualcomm, MS,..) of AllJoyn joined OIC in 2016 ➛ OIC was renamed as OCF – Provides connectivity to any “things” regardless of their OS, connectivity technology
45 OCF Goals
■ Make it easy for developers to deal with the complexity of IoT communications
■ Provide a common data model that developers can use to interface with all IoT devices and their underlying data
■ Establish an architectural foundation that can achieve the necessary scalability
■ Focus the architecture around interoperability
■ Supports the needs of multiple vertical markets (since many use cases span multiple vertical markets)
■ Provide a path towards future consolidation of standards
46 Definition of Various Things
• By defining resources of • By defining functions/operations things and its properties of things
47 Support of Multiple Verticals
• Legacy vertical services usually designed as silos No common way to communicate among them
• A common platform provides a foundation for vertical services to collaborate and interwork by providing common services and data models
48 IoTivity Overview
. An open source software framework implementing OCF Standards . Seamless device-to-device connectivity to address emerging needs of IoT . Licensed under Apache License Version 2.0 . Available on TIZEN, Android, Arduino, Linux(Ubuntu) Platforms
OCF Client OCF Client OCF Topologies Supported XMPP/ STUN/ Cloud TURN/I CE CoAP over TCP OCF Intermediary Gateway Gateway OCF Client OCF Server P2P Direct
OCF Servers OCF Servers Cloud based int Remote Access elligent Services
Rich Device Consum Enterpris Industria Automoti Health Key Goals er e l ve…. . Common Solution APIs (C/C++/Java/JS) . Established Protocols Service Layer . Security & Identity Device Low-Power Data Mana Lite Device Standardized Profiles Management Management gement Sensing/Control . Application Resource Cont . Interoperability Resource Encapsulation ainer Base Layer . Innovation Opportunities Messagin Security Base Layer g . Necessary connectivity
Discovery Messaging Security Discovery IoTivity Profiles IoTivity Framework IoTivity Connectivities*
50 Discovery Subsystem
announce resource multicast “OCF/server” listen Client OCF OCF COAP C C Server [ port 5683 ] Client Server COAP HTTP Gateway C C Multicast announcement over Wi-Fi / Ethernet COAP C Server
Constrained Discovery within multicast find local network listen resource Environment OCF [ port 5683 ] OCF Server Client Internet unicast response “OCF/server” Connectivity Discovery Mechanism Description Multicast/Unicast over WiFi / Ethernet WiFi & IP Multicast CoAP Multicast Port: 5683 Ethernet (Assigned by IANA) (over IP) CoAP Secure Port: 5684 advertise scan OCF service OCF service IP Unicast over UDP Precondition: OIC Server Address & Port are known OCF find resource OCF Bluetooth Using Scan & Advertise OCF Specific Service UUID Server Client (EDR & response “OCF/server” BLE)
Advertise/Scan over BLE/BT IANA: Internet Assigned Numbers Authority
51 Discovery – Finding a Resource
Function Call Flow Sequence Diagram
Application
1 6 OCPlatform::findResource(host, “/light/1” OCF Light Light Fan , connectivityType, resourceHandlerCb); Client 192.168.1.11 192.168.1.12 192.168.1.21 C++ API (SDK) GET /oc/core?rt=light OCDoResource(resourceHandle, OC_REST_GET, “/ (IP multicast) 2 5 light/1”, 0, payLoad, connectivityType, qos, GET /oc/core?rt=light &cbData, headerOptions, numOptions); (multicast) C API (SDK) Send a CASendRequest(endPoint, reques multicast GET /oc/core?rt=light JSON/CBOR tInfo); query OCStack (multicast) Encode/ Decoder //Devices that matches the query answers as indicated below CoAP ACK,CONTENT Connectivity Abstraction IoTivity IoTivity IoTivity Device Device Device ACK, CONTENT
3 Multicast
4
52 Messaging - Connectivity Abstraction
CA Control Component Resource Model - Target network selection, interface control & monitoring CA API - CoAP message serialization & parsing CA Control - Block-wise messaging flow control Network CoAP Blockwise Interface Config. Protocol Transfer Controller Transport Adapter Component
Transport Adapter - Data transmission over UDP, TCP, BLE(GATT), BT(SPP) & NFC IP BLE BT TCP NFC Adapter Adapter Adapter Adapter Adapter - Secure data exchanging using DTLS Platform Adapter Component Platform Adapter
Ubuntu Android Tizen Arduino - Wi-Fi, Ethernet and BLE Interface Interface Interface Interface - Android Wi-Fi, BLE and BT
Ubuntu Android Tizen Arduino - Tizen Wi-Fi, BLE and BT - Arduino Wi-Fi, Ethernet and BLE Legend
CA Component CA Module External
Ubuntu Android Tizen Arduino
53 Messaging – CoAP over TCP
TCP and TLS Transport for the CoAP CoAP Default transport - UDP. 3rd Service 3rd Service • Reliable delivery, simple congestion control & flow 3rd Service 3rd Service control • Provided by the message layer of CoAP CoAP over TCP Benefits . CoAP CI(*) Server RD(**) Server • To integrate well with existing enterprise infrastructure, • Ability to work with existing NAT boxes • Advanced Congestion Control algorithms CoAP over TCP for Cloud extension • Integration with Web Environment Resources should be registered to the Resource Directory Service for discovery * CI : Cloud Interface ** RD : Resource Directory
54 54 Security Features & Architecture
Provisioning Manager Resource Introspection (RI) layer PM C API (Admin Device) Secure Resource Manager Provisioning Manager (PM) (SRM) layer Ownership Transfer Credential(Key)/ Ownership Provisioning Resource Policy Engine Transfer Database Man ACL Provisioning Provisioning Secure Virtual Manager (RM) (PE) Manager (OTM) ager (PDM) Ownership Transfer Database Database Credential(Key) Persistent Provisioning Storage Secure Resource Provider (SRP) Interface (PSI)
Resource Access Access Connectivity Abstraction (CA) layer over DTLS X Denied DTLSDTLS modules, modules, etc. etc. Resource DTLS modules, etc. Client Server Client (Provisioned) (Provisioned) (Un-Provisioned) Security Subsystem Architecture
Ownership Transfer & Provisioning ACL & Secure Communication
• Ownership Transfer (Unowned device Owned device) • Accept or Deny the Request according to the authority by check • OCF device initial registration the permission for GET/PUT/POST/DELETE request (Administrator authentication, configuration of access control) • Status check of connected devices for mutual authentication • Setting the credential for mutual authentication & access policy into resource server • Issued credential management * Platform Hardening not part of the OCF Specs & IoTivity Implementation
55 LWM2M (Lightweight M2M)
LWM2M Open Mobile Alliance: http://openmobilealliance.org/iot/lightweight-m2m-lwm2m OMA Specifications: http://www.openmobilealliance.org/wp/
56 Common Needs for Device Management
Bootstrapping (Security) - Service provisioning - Key management - Provisioning of access control lists Firmware Update - Updating application and system SW - Applying bug fixes and new features Remote management - Changes to settings - Trigger actuators Fault management - Reporting errors from devices - Querying status of devices Information reporting - Notifying changes in sensor values - Retrieving configuration settings and device status
57 57 LWM2M Overview
OMA (Open Mobile Alliance) Standard Esp. targeted at constrained devices LWM2M - Low-power MCU and small amounts of flash and RAM Server Device lifecycle management specification - Handling device management and application data - SW upgrade and device re-configuration - Device monitoring and sensed data reporting Client-server architecture Modern architecture design based on REST
Defines a simple resource model for extensibility LWM2M Client Secure data transfer standard CoAP based
58 58 LWM2M Architecture
Client initiated & server initiated
Four logical LWM2M interfaces - Bootstrap for managing access control and configuration - Client Registration for device existence and capability - Device management and service enablement - Information Reporting for reporting resource information Object model - Accessed with simple URI: /objectID/object instance/resourceID Sensor Sensor#1 Value [Ref] Implementing LWM2M in Constrained IoT Devices at https://www.researchgate.net/publication/281524900
59 59 Device S/W Stack
[Ref] Implementing LWM2M in Constrained IoT Devices at https://www.researchgate.net/publication/281524900
60 60 LWM2M Message Flow
[Ref] Implementing LWM2M in Constrained IoT Devices at https://www.researchgate.net/publication/281524900
61 61 62