IoT Device Platform -...
Transcript of IoT Device Platform -...
2
Outline
1. The Era of IoT
2. IoT Value
3. IoT Architecture
4. Samsung ARTIK
5. IoT Platform
6. IoT Protocols
6
Tesla …
■ Electric Car manufacturer .. That is all?
Gigafactory in Nevada, US
Solar roof tile from Solarcity
10
The Era of IoT – IIoT & CIoT
[Ref] Talk on Industrial Internet of Things @ Intelligent systems tech forum 2014
11
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…
Moore’s Law - A logarithmic scale on the Y-axis
Performance
Cost
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
12
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)
MetCalfe’s Law
Metcalfe’s law is really about network growth, value creation, and customer acquisition rather than about technological innovation
N: # of servicesM: # of devices
13
IoT Conceptual Architecture
Data AnalyticsServices
Internet
Gateway/Hub
Things(Sensors, Intelligence Appliances…)
■ Layered architecture consisting of Application, Network, Edge, and Perception layers
Perception Layer
Network Layer
Application Layer
Edge Layer
Clouds
High-valuedevices
Constraineddevices
14
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
15
IoT Platforms – Eco-system
People
데이터
■ 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
Internet of Everything !!
How can we get everything connected and get some meaningful value out of it?
Things Connection with various things, env.
Eco-system
16
Types of IoT Platforms
of
People &Things
Gateway
Data Gathering
Device Management
AI Analytics
Storage / Database
Messaging
Data Collection
Edge Intelligence
BSP
Connectivity
Co
mm
un
icat
ion
s
Device & Controllers
Cloud Services
Ecosystem
Security
Communications
Edge Computing
Cloud Platform
Edge Platform
Device Platform
Secu
rity
17
Platform Definition
■ Platform Technology (from Wikipedia)
– “제품” 개발을 가능하게 하는 기술이나, 현재 또는 미래의 개발을 지원하는 프로세스
17/8
18
Open Platform
■ 필요기능의 통합 플랫폼 개발의 끝이 아니다!
– “계속적으로 유용”하고 사용자 친화적인 경험 제공
■ 어떠한 플랫폼도 똑같이 만들어지지 않는다!
– 훨씬 더 강력하고 유용하며 “인기 있는 플랫폼”이 있기 마련
■ 고객을 알아야 강력한 Platform을 만든다!
– 플랫폼 오픈화를 통한 “소통 채널” 극대화! Do you know What your customers want?
Platform = “Technology + Ecosystem”
Ecosystem = “Community + Environment”
사용자 + Contributors + Partners
Platform 사용자
PartnersContributors
Evangelize
Feedbacks
Evangelize Contribute
Evangelize
Collaborate
Promote
Feedback
19
■ Current status of SW development resources
- Android developers > Web developers >> Embedded developers
Prospective IoT SW Developers
20
Samsung IoT ARTIK Family
■ Support E2E IoT use case scenario from sensor device to cloud
Clouds
Rich devices
Constraineddevices
ARTIK 05x (WiFi)
ARTIK 020 (BLE)ARTIK 030 (ZigBee)
ARTIK 5X0
[Ref.] https://www.artik.io
ARTIK 710
Cortex-M4/32KB/256KB
Cortex-M4/32KB/256KB
Cortex-R4/1.4MB/8MB
4xCortex-A9/GPU512MB|1GB/4GB
8xCortex-A53/GPU1GB/4GB
22
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
23
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
24
Device
ARK API
ML BP
API call
• Fragmented API
- Inconsistent Dev Exp. because of various API concepts
& styles
Decreasing usability, productivity, accessibility
• Coarse-grained Build Configurability
- Impossible image build with features tailored only for
device spec. or user-specific use cases
Over featuring and unnecessary memory usage
AS-IS
• Consistent API
- Providing consistent & developer friendly API
Excellent Dev. Exp. to increase usability, productivity,
accessibility
• Fine-grained Build Configurability
- Providing build-time feature configurability for OS,
network stack, connectivity, Services
Optimal memory footprint
TO-BE
Security
Platform
Device ML BP Security
ARK Platform
Release
Easy to develop services using one set of consistent APIs !!!
Already read the sensor data. How do I upload it to the Cloud?
Platform Requirements
25
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.
- Consisting of component modules:
OS, Network Stack , Service
Framework, Protocols, Lib.[Low-End]
No Thread OSBLECoAPGPIO
….
OS
Wi-FiBLE
IoTivityML Lib
IP
MQTT
HTTPCoAP
LWM2M
AppFrw
SensorFrw
CloudFrw
[High-End] Multi Thread OSWiFiCoAPTCP/UDPGPIO….
[Mid-End] Multi Thread OSWiFiCoAPUDPGPIOPWM ….
Image
Image
020
053
Footprint: ~수십KB
Footprint: ~수백KB
Footprint: ~수천KB
Platform
Build-time Configuration
Device-specific Memory Footprint
Image
Platform Requirements
26
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
27
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
ProprietaryAPI-based
• Small Memory Size• Fast Execution• Quick Interrupt Response
• No code compatibility and reusability (Esp. Linux-based codereuse)- Customer app. redevelopment- Retraining for new platform
• FreeRTOS• RIOT• Zephyr
POSIXAPI-based
• Code compatibility and reuse- existing Linux code reuse- Almost zero porting effort
• Existing Linux customer/developer-oriented
• Real-time OptionsUnpredictable interrupt latency & jitter
• Slow Booting Time• Large Memory Size
• ThreadX• QNX• VxWorks• Integrity• LynxOS• TizenRT
28
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
29
MQTT (Message Queue Telemetry Transport)
Official web site : http://mqtt.orgM2Mqtt project : http://www.m2mqtt.netMosquitto : http://mosquitto.orgHiveMQ : http://www.hivemq.comMQTT An implementer’s perspective : http://bit.ly/1koMZLFMQTT Another implementer’s perspective : http://bit.ly/1rHDnAN
30
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
31
MQTT Architecture
■ Broker-based communications
Publisher(Source)
BrokerSubscriber
(Sink)
Publish (topic, info)
Publish (topic, info)
Subscribe (topic)
32
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.
33
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
34
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
35
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
36
CoAP (Constrained Application Protocol)
Coap Technology : http://coap.technologyOfficial draft : https://datatracker.ietf.org/doc/rfc7252/CoRE Link format : http://tools.ietf.org/html/rfc6690#section-3.1CoAPSharp : http://www.coapsharp.comCopper : https://github.com/mkovatsc/Copper
37
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
38
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
39
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
40
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
41
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
42
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
43
IoTivity Open Connectivity Foundation
IoTivity Open Source Community: https://openconnectivity.orgOpen Connectivity Foundation: https://openconnectivity.org/
44
OCF and IoTivity Relationship
Specifications & Open Source ready simultaneously
OCF Specifications: https://openconnectivity.org/developer/specificationsIoTivity Open source: https://www.iotivity.org/downloads/iotivity-1.3.0
45
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
46
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
47
Definition of Various Things
• By defining resources of things and its properties
• By defining functions/operations of things
48
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
49
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
P2P Direct
OCF Client OCF Server
OCF Intermediary
XMPP/STUN/TURN/I
CE
Gateway
OCF Servers
OCF Client
Remote Access
Cloud
Gateway
OCF ServersCloud based intelligent Services
OCF Client
OCF Topologies Supported
CoAP over TCP
50
High Level Architecture
Base Layer
Sensing/ControlApplication
Base Layer
MessagingDiscovery
Service Layer
Device Management
Data Management
Security Discovery
Messaging
APIs(C/C++/Java/JS)
….
Security
Resource Encapsulation
Low-Power Management
Resource Container
Rich Device
Lite Device
Consumer
Enterprise
Industrial
Automotive
Health Key Goals
Common Solution
Established Protocols
Security & Identity
Standardized Profiles
Interoperability
Innovation Opportunities
Necessary connectivity
IoTivity Profiles
IoTivity Framework
IoTivity Connectivities*
51
Discovery Subsystem
Multicast announcement over Wi-Fi / Ethernet
OCF Server
OCF Client
announce resource“OCF/server”
multicastlisten
[ port 5683 ]
Multicast/Unicast over WiFi / Ethernet
OCF Server
OCF Client
multicastlisten
findresource
[ port 5683 ]
unicast response “OCF/server”
Advertise/Scan over BLE/BT
OCF Server
OCF Client
advertiseOCF service
scanOCF service
response “OCF/server”
find resource
IANA: Internet Assigned Numbers Authority
Server
Server
ClientC
CGateway
C
COAP
CCOAP
HTTP
C
COAP
Internet
Constrained Environment
Connectivity Discovery Mechanism Description
WiFi &Ethernet(over IP)
IP Multicast CoAP Multicast Port: 5683 (Assigned by IANA)CoAP Secure Port: 5684
IP Unicast over UDP Precondition:OIC Server Address & Port are known
Bluetooth(EDR &BLE)
Using Scan & Advertise OCF Specific Service UUID
Discovery within local network
52
Discovery – Finding a Resource
Application
C++ API (SDK)
C API (SDK)JSON/CBOR
Encode/Decoder
OCStack
CoAP
Connectivity Abstraction
2
1
IoTivityDevice
IoTivityDevice
IoTivityDevice
3
Multicast
4
5
6 OCPlatform::findResource(host, “/light/1”
, connectivityType, resourceHandlerCb);
OCDoResource(resourceHandle, OC_REST_GET, “/
light/1”, 0, payLoad, connectivityType, qos,
&cbData, headerOptions, numOptions);
CASendRequest(endPoint, reques
tInfo);
Send a multicast query
//Devices that matches the query answers as indicated below
OCF Client
Light192.168.1.11
Light192.168.1.12
Fan192.168.1.21
GET /oc/core?rt=light
(IP multicast)GET /oc/core?rt=light
(multicast)
GET /oc/core?rt=light
(multicast)
ACK,CONTENT
ACK, CONTENT
Function Call Flow Sequence Diagram
53
Messaging - Connectivity Abstraction
CA API
CA Control
NetworkConfig.
CoAPProtocol
InterfaceController
Transport Adapter
BLEAdapter
BTAdapter
Platform Adapter
Ubuntu Android Tizen Arduino
AndroidInterface
UbuntuInterface
TizenInterface
ArduinoInterface
TCPAdapter
IPAdapter
NFCAdapter
BlockwiseTransfer
Resource ModelCA Control Component
- Target network selection, interface control & monitoring
- CoAP message serialization & parsing
- Block-wise messaging flow control
Transport Adapter Component
- Data transmission over UDP, TCP, BLE(GATT), BT(SPP) & NFC
- Secure data exchanging using DTLS
Platform Adapter Component
- Wi-Fi, Ethernet and BLE
- Android Wi-Fi, BLE and BT
- Tizen Wi-Fi, BLE and BT
- Arduino Wi-Fi, Ethernet and BLELegend
CA Component CA Module External
Ubuntu Android Tizen Arduino
54
Messaging – CoAP over TCP
54
RD(**) ServerCoAP CI(*) Server
* CI
** RD
: Cloud Interface
: Resource Directory
3rd Service3rd Service
3rd Service3rd Service
TCP and TLS Transport for the CoAP
CoAP Default transport - UDP.
• Reliable delivery, simple congestion control & flow
control
• Provided by the message layer of CoAP
CoAP over TCP Benefits .
• To integrate well with existing enterprise
infrastructure,
• Ability to work with existing NAT boxes
• Advanced Congestion Control algorithms
• Integration with Web Environment
Resources should be registered to the Resource
Directory Service for discovery
CoAP over TCP for Cloud extension
55
Security Features & Architecture
Resource Server
(Provisioned)
Client(Provisioned)
ProvisioningManager
(Admin Device)
Ownership Transfer Credential(Key)/
ACL Provisioning
Resource Accessover DTLS
Ownership Transfer Credential(Key)
Provisioning
Client(Un-Provisioned)
AccessDeniedX
* Platform Hardening not part of the OCF Specs & IoTivity Implementation
DTLS modules, etc.DTLS modules, etc.
Connectivity Abstraction (CA) layer
Secure Resource Manager(SRM) layer
Resource Introspection (RI) layer
DTLS modules, etc.
Provisioning Manager (PM)
Ownership Transfer
Manager (OTM)
Secure Resource Provider (SRP)
ProvisioningDatabase Man
ager (PDM)Provisioning
Database
PM C API
Ownership Transfer & Provisioning ACL & Secure Communication
• Ownership Transfer (Unowned device Owned device)
• OCF device initial registration
(Administrator authentication, configuration of access control)
• Setting the credential for mutual authentication & access
policy into resource server
• Issued credential management
• Accept or Deny the Request according to the authority by check
the permission for GET/PUT/POST/DELETE request
• Status check of connected devices for mutual authentication
Resource Manager (RM)
Policy Engine (PE)
PersistentStorage
Interface (PSI)
Secure VirtualDatabase
Security Subsystem Architecture
56
LWM2M (Lightweight M2M)
LWM2M Open Mobile Alliance: http://openmobilealliance.org/iot/lightweight-m2m-lwm2mOMA Specifications: http://www.openmobilealliance.org/wp/
57
Common Needs for Device Management
57
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
58
LWM2M Overview
58
OMA (Open Mobile Alliance) Standard
Esp. targeted at constrained devices
- Low-power MCU and small amounts of flash and RAM
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
Secure data transfer standard CoAP based
LWM2MServer
LWM2MClient
59
LWM2M Architecture
59[Ref] Implementing LWM2M in Constrained IoT Devices at https://www.researchgate.net/publication/281524900
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
Client initiated & server initiated
Sensor Sensor#1 Value
60
Device S/W Stack
60[Ref] Implementing LWM2M in Constrained IoT Devices at https://www.researchgate.net/publication/281524900
61
LWM2M Message Flow
61[Ref] Implementing LWM2M in Constrained IoT Devices at https://www.researchgate.net/publication/281524900
62