1

2017.11.16.

Prof. Doohyun Kim, Ph.DDept. of Software, Konkuk Univ., Seoul

Korea

IoT Open Source Platform and Educational Development

Practices

2

Table of Contents

▣What is IoT?

▣IoT standard – oneM2M

▣Open Source Platform

▣Practices

◈Smart Mirror

◈GPIO

◈Device Drivers

◈ IoT Applications

3

WHAT IS IOT?

4

5

6

IoT Challenges

7

8

IoT – more than devices

9

Cloud Platform – AWS IoT

10

Cloud Platform – IBM Watson

11

Open Source HW(OSHW) Platform

▣Raspberry Pi

◈Series of small single-board computers developed by the Raspberry Pi

Foundation, UK

◈Open source hardware created to facilitate the teaching of basic computer

science at school

◈Raspbian OS(Debian-based Linux)

Raspberry Pi 3 model B

ProcessorARM Cortex-A53

Broadcom BCM2837 (64Bit QUAD Core)

Graphics Videocore IV

Speed 1.2 GHz

Memory 1GB LPDDR2 900MHz

Storage Micro SD

Power 5V/2.5A

GPIO 40 Pins

Ethernet 10/100 Ethernet

Port

HDMI, audio-video jack, 4xUSB 2.0, Ethernet, Camera Serial

Interface,

Display Serial Interface

WiFi 2.4GHz 802.11n Wireless LAN

Bluetooth Bluetooth 4.1 Classic, BLE

12

Open Source HW(OSHW) Platform

▣Arduino

◈ Open source hardware and software developed by IDII(Interaction Design Institute

lvera, Italy

◈ AVR-based single board microcontroller

◈ Firmware compiled via its own IDE can be easily uploaded via USB

◈ Focused on sensor and actuator control

Arduino UNO

Processor AVR Atmega 328p

Speed 16 MHz

Memory SRAM 2 KB (Atmega 328p)

Storage Flash memory 32 KB (Atmega 328p)

Power 7-12V

Voltage 5V

GPIO 20 Pins

OS None

13

Open Source HW(OSHW) Platform

14

Open Source SW Platform

▣Mobius 2.0 by KETI

◈The world’s first open source platform for oneM2M standard

◈Released in January 2015 through OCEAN community

(July 2017, 727 institutions use it)

15

IOT STANDARD – ONEM2M

16

Goal

▶ To have one common/standard platform

• generic to different IoT service domains

• so that the IoT market can be expanded

Vertical (silo)

Local NW

BusinessApplicatio

n

Device

CommunicationNetwork (wireline,

wireless, Powerline ..)

Gateway

CommunicationNetwork 1

CommunicationNetwork 2

Local NW

GatewayIP

provide common

application functions

as service layer

Application

A

Application Application Application

Common Service Layer

Device Device

Device

AS

AA Device

AS

S

ALocal NW

BusinessApplicatio

n

Device

CommunicationNetwork (wireline,

wireless, Powerline ..)

Gateway

Application

A

Horizontal (common/generic)Low cost, Time-to-market

17

Collaboration

▶ Collaboration with global SDOs

• Interworking with existing systems and utilization of existing protocols

MQT

T

DM

HTTP CoAP

TLS DTLS

uses interworks with

collaborates with

P2413

LWM2M

OCF

AllJoyn

SG20 WG10

DDS Rel-3 Work

18

Members

▶ IoT ecosystem stakeholders

• Operators, Venders, Solution Providers and Institutes

• 237 members (Aug-2016)

http://www.oneM2M.org

19

Structure

▶ Technical Plenary

• made up of Working Group(WG) and manages standard development

▶ Steering Committee

• Manages agency operations such as law, accounting, and marketing

http://member.oneM2M.org

20

Deliverables (1/2)

▶ WG1(Requirements)

• Use Case TR1), Requirements TS2), Terminology TS

▶ WG2(Architecture)

• Functional Architecture TS,

• LWM2M Interworking TS, AllJoyn Interworking TS, OCF Interworking TS

▶ WG3(Protocol)

• Core Protocol TS

• HTTP Binding TS, CoAP Binding TS, MQTT Binding TS, WebSocket Binding TS

1) Technical Report, 2) Technical Specification

21

Deliverables (2/2)

▶ WG4(Security)

• Security Solutions TS, Secure Environment Abstraction TS

▶ WG5(MAS)

• OMA Management Enablement TS, BBF Management Enablement TS,

• Home Appliances Information Model and Mapping TS, Base Ontology TS

▶ WG6(Testing)

• Testing Framework TS

• Interoperability Testing TS

• Implementation Conformance Statements TS, Test Suite Structure & Test Purposes

TS, Abstract Test Suite & Implementation eXtra information for Test TS

22

Service Platform

▶ Difficult to explain in OSI 7-layer model

• It focuses on traditional communication protocol stack concept

Application Layer

Presentation Layer

Session Layer

Transport Layer

Network Layer

Data Link Layer

Physical Layer

Service layer session concept in study

Out of scope

oneM2M scope

XML, JSON, CBOR

HTTP, CoAP, MQTT, WebSocket

OSI 7-layers

oneM2M protocols

IoT Applications

23

Service Platform

▶ Well explained in ITU-T IoT Reference Model

• oneM2M platform as a service platform provides common services, supporting

capabilities to IoT applications

Application Layer IoT

Applications

Gen

eric S

ecu

rity Cap

ab

ilities

Sp

ecific S

ecu

rity Cap

ab

ilities

Generic Support

Capabilities

SpecificSupport

Capabilities

NetworkingCapabilities

TransportCapabilities

Device Gateway Cloud

ServiceLayer

NetworkLayer

DeviceLayer

ApplicationSolution

ServicePlatform

ConnectivityPlatform

Sensor/Device

Security

Gen

eric M

an

ag

em

en

t Cap

ab

ilities

Sp

ecific M

an

ag

em

en

t Cap

ab

ilities

Mgmt.

ITU-T Y.2060 IoT Reference Model

Application Layer

Common Services

Layer

Network Services

Layer

oneM2M Layered Model

24

Service Platform

▶ oneM2M is generic service platform.

• that applies to device, gateway and server

– server specific functions are defined

• that provides standard/common APIs to applications

• stores data that is consumed by application

• is transport agnostic

– no dependency to any specific messaging protocol (e.g. CoAP)

– support both TCP and UDP

– basically over IP

Device Gateway Server App

oneM2M

protocol

oneM2M

protocol

oneM2M

protocol

25

RESTful API

▶ Platform provides APIs to applications

• Apps consist of– oneM2M API call

– application/service logic

Platformbase

res1

res2

res23

App

to: base

op: Retrieve

fc:

{filterUsage = discovery

limit = 10

resourceType = container}

• resourceType = container

• labels = room1

• resourceType = container

• labels = room2

• resourceType = contentInstance

• labels = temp

• size = 2

pc:

{

base/res1

base/res2

}

request

response

26

Architecture

▶ Two domains in the oneM2M system

• Infrastructure domain: oneM2M server and applications

• Field domain: oneM2M device, gateways and their applications

oneM2M Functional Architecture

AE AE

Mca Mca Mca

Mcc

Mcn Mcn

CSE CSE

NSE NSE

Field Domain Infrastructure Domain

To Infrastructure

Domain of other

Service Provider

Mcc’

27

▶ Hierarchical addressing method

• Structured resource address

▶ Non-hierarchical addressing method

• Unstructured resource address

Home

Room1

Temp

Humidity

2014-09-04

11amStructured address Home/Room1/Humidity/2014-09-04/11amUnstructured address inst1bc3d

Communication Scheme

28

OPEN SOURCE PLATFORM

29

OCEAN Open Sources

▶ OCEAN (Open allianCE for iot stANdard) established in Jan. 6th, 2015 by KETI

▶ The objective of OCEAN is to share open sources based on IoTstandards and to encourage co-working between its members

▶ The OCEAN supports early commercialize and vitalized ecosystem for IoT

▶ 3-Clause BSD license policy

▶ OCEAN adapts IPR policy of the standards referred by open

30

OCEAN Open Sources

▶ The OCEAN is now providing open sources of oneM2M-based IoTplatform called “Mobius“ and “&Cube“, and relevant documents.

▶ For download of the open source, users should join to OCEAN web site (http://www.iotocean.org).

OCEAN (Open alliance for iot standard)

2014 2015 2016 2017

oneM2M 1.0 oneM2M 2.0

~2015IEEE …

oneM2M 2.0

IETF

2016~

Expand

Other Alliance

Interworking

31

How IoT Devices Work

32

Device Development Procedure

33

Development Method

34

Basic State

TAS

&CubeThyme

ADN-AE

&Cube Interface

Thing Interfaces

AE-SmartPot Configuration CSEBasemca

ADN-AE

IN-CSE

mca

35

Device Registration

TAS

&CubeThyme

ADN-AE

&Cube Interface

Thing Interfaces

AE-SmartPot Configurationmca

AE create

ADN-AE

CSEBase

AE-

SmartPot

IN-CSE

mca

36

&CubeThyme

ADN-AE

AE-SmartPot Configurationmca

container create

CSEBase

AE-

SmartPot

container-

Temperature

IN-CSE

TAS

&Cube Interface

Thing Interfaces

ADN-AE

mca

Thing(sensor) Registration

37

Thing(actuator) Registration

*nu: notification URI

&CubeThyme

ADN-AE

AE-SmartPot Configurationmca

container create

subscription create (nu*)

CSEBase

AE-

SmartPot

container-

Temperature

container-light

subscription-

light_sub

IN-CSE

TAS

&Cube Interface

Thing Interfaces

ADN-AE

mca

38

Thing(sensor) Data Upload

TAS

&CubeThyme

ADN-AE

&Cube Interface

Thing Interfaces

AE-SmartPot Configurationmca

contentInstance create

CSEBase

AE-

SmartPot

container-

Temperature

container-light

subscription-

light_sub

Sen

sor

dat

aCIN-1

IN-CSE

ADN-AE

mca

39

Thing(sensor) Data Retrieve

&CubeThyme

ADN-AE

AE-SmartPot Configurationmca

CSEBase

AE-

SmartPot

container-

Temperature

container-light

subscription-

light_sub

CIN-1

ADN-AE

con

ten

tIn

stan

cere

trie

ve

Resp

on

se

IN-CSE

mca

TAS

&Cube Interface

Thing Interfaces

40

Thing(sensor) Control

TAS

&CubeThyme

ADN-AE

&Cube Interface

Thing Interfaces

AE-SmartPot Configurationmca

CSEBase

AE-

SmartPot

container-

Temperature

container-light

subscription-

light_sub

CIN-1

ADN-AE

con

ten

tIn

stan

cecr

eate

CIN-ON

notification to nu

Act

uat

or

con

tro

l

IN-CSE

mca

41

SMART MIRROR

Practices of IoT Dev. with Raspberry Pi 3

42

Making Smart Mirror

43

Making Smart Mirror

44

Making Smart Mirror

▣Digital Clock

Connecting with F-M line

45

Making Smart Mirror

▣Digital Clock App.

◈Weather information Service

◈GUI designed with Qt-designer

◈Coding with Python3

46

DEVICE CONTROL WITH GPIO

Practices of IoT Dev. with Raspberry Pi 3

47

GPIO (General Purpose Input Output)

▣General-purpose input/output terminal that can be selectively used without fixing single connection terminal as an input or output

◈Supports at least several tens to hundreds of GPIO ports depending an ARM

CPU

◈Supports 54 GPIO ports for the BCM2835 CPU of Raspberry Pi

▣GPIO connection pin can be wired directly to the outside of the chip and provides enough power to drive the LED

48

Raspberry Pi GPIO

▣GPIO Pin Map (Raspberry Pi3 B)

3.3V

GPIO02

GPIO03

GPIO04

(GND)

GPIO17

GPIO27

GPIO22

(3.3V)

GPIO10

GPIO09

GPIO11

(GND)

ID_SD

GPIO5

GPIO6

GPIO13

GPIO19

GPIO26

(GND)

5V

(5V)

GND

GPIO14

GPIO15

GPIO18

(GND)

GPIO23

GPIO24

(GND)

GPIO25

GPIO08

GPIO07

ID_SD

(GND)

GPIO12

(GND)

GPIO16

GPIO20

GPIO21

I2C SDA

I2C SCL

GPCLK0

SPI MOSI

SPI MISO

SPI SCLK

1

39

2

40

UART TXD

UART RXD

PCMCLK

SPI CE0

SPI CE1

49

GPIO Practice – Temperature-Humidity sensor

▣Control DHT11 Sensor

◈Circuit configuration Red: VCC

Orange: GND

Yellow: Sensor value

50

GPIO Practice – Button Event

▣Pull-Up◈ A circuit configuration scheme that

keeps the basic input state as a high

through the resistor

▣Pull-Down◈ A circuit configuration scheme that

keeps the basic input state as a low

through the resistor

High

Low

High

Low

51

GPIO Practice

▣Button input by Pull–Up method (Circuit)

Rising moment

LOW

HIGH

52

GPIO Practice

▣Button input by Pull–Up method (Python code)◈ Callback is called at the moment the button is released (if GPIO.RISING is set)

53

GPIO Practice

▣Button input by Pull–Down method (Circuit)

Rising moment

LOW

HIGH

54

GPIO Practice

▣Ex6. Button input by Pull –Down method (Python code)◈ Callback is called at the moment button is pressed (if GPIO.RISING is set)

55

▣ Picamera Python Module

◈ Capturing still images

picam coding - capture

test.jpg

import time

import picamera

picam = picamera.PiCamera()

picam.capture(‘test.jpg’)

time.sleep(2)

56

picam coding – Video recording

▣ Picamera Python Module

◈ Recording video

from picamera import PiCamera

camera = PiCamera()

camera.resolution = (640, 480)

camera.start_recording(‘hello.h264')

camera.wait_recording(60)

camera.stop_recording()

hello.mp4

57

picam coding – using GPIO button

▣Take an image using the button

58

picam coding – using GPIO button

▣Take an image using the button

21

20

GND21

20

59

picam coding – using buttons

▣Take an image using the button (with callback)import picamera

import RPi.GPIO as GPIO

import time

from time import sleep

Vol = 21

Button = 20

camera = picamera.PiCamera()

def setup():

GPIO.setmode(GPIO.BCM)

GPIO.setup(Vol, GPIO.OUT)

GPIO.setup(Button, GPIO.IN, pull_up_down=GPIO.PUD_UP)

GPIO.add_event_detect(Button, GPIO.RISING, callback=handler)

VoltageStatus()

def VoltageStatus():

GPIO.output(Vol, True)

def handler(channel):

print('--- I am taking a picture now ---')

camera.capture('button.jpg')

print('finish')

print('Waiting for Button to Press')

if __name__ == "__main__":

setup()

try:

while True:

time.sleep(0.1)

except KeyboardInterrupt:

camera.close()

GPIO.cleanup()

60

DEVICE DRIVER PRACTICE WITH GPIO

Practices of IoT Dev. On Raspberry Pi 3

61

Character device driver Skeleton

#include <linux/kernel.h>

#include <linux/module.h>#include <linux/init.h>

Header Files

int device_open( … ) { … }

int device_release( … ) { … }

ssize_t device_write( … ) { … }

ssize_t device_read( … ) { … }

…

Function Prototypes

static struct file_operations device_fops = { …ssize_t (*read) (…);ssize_t (*write) (…); …int (*open) (…);int (*release) (…);…

};

File Operation

int init_module(void) { … } Module Initialization

void cleanup_module(void) { … } Module removed.

62

ioctl

▣ Device Driver function for I/O Control

▣ must be declared and used uniquely for each device

▣ Encoding and Decoding cmd by using Macro

int dev_ioctl(…, struct file *filp, unsigned int cmd, unsigned long arg)

{ …

switch(cmd){ … }

}

Data exchange on request

ret = ioctl ( int fd, int request, char *argp);

cmd decoding using macro

cmd encoding using macro

63

ioctl

▣cmd◈ passed to the ioctl() function of the device driver is used to distinguish the processing

requested by the application from the device driver.

◈ consists of 32-bit fields, which contain unique value for identification and additional

information that benefits the program processing

◈ Device driver operates with a switch statement according to the contents of the

received cmd

64

ioctl

▣ Cmd bit field configuration

◈ Predefined kernel macros like _IO, _IOR, _IOW is provided for encoding cmd➢ /usr/include/asm-generic/ioctl.h

Name of Field

Notes

Dir (30:31)

Direction of the data from/to application_IOC_NONE : No data transfer_IOC_READ , _IOC_WRITE : one-way transmission_IOC_ READ | _IOC_WIRTE : two-way transmission

Size (16:29) Number of bytes passed through the arg parameter

Type (8:15)Magic Number: (0~255, configure it to be different from other device drivers.)- can be extracted using the IOC_TYPE macro

Nr (0:7)Sequential number distinguishing commands. (usually starting at 0)- can be extracted using the _IOC_NR macro

65

ioctl

▣Macros for encoding cmd

◈_IO( type, nr) : command without parameters

◈_IOR( type, nr, datatype) : reading data from the driver

◈_IOW( type, nr, datatype) : writing data

◈_IOWR( type, nr, datatype) : passing parameters two-ways

➢type, nr are passed as a parameter

➢Datatype is calculated by applying sizeof()

▣Macros for decoding cmd

◈_IOC_DIR() : to read the direction value

◈_IOC_TYPE() : to read the magic number value

◈_IOC_SIZE() : to read the data size value

◈_IOC_NR() : to read the sequential number value

66

ioremap / iounmap

▣Since Linux uses virtual memory addresses, the physical and virtual addresses must be mapped to directly control I/O

▣ In device drivers, the physical and virtual addresses are mapped by the functions provided by <asm/io.h>

#include <asm/io.h>void __iomem *led_addr_data;

virtual_addr_data = ioremap(phycal_address, mapping_size);

iounmap(virtual_addr_data);

67

ioctl() in Device Driver

long simple_ioctl ( struct file *filp, unsigned int cmd, unsigned long arg) {

if(_IOC_TYPE(cmd) != MY_IOC_MAGIC)return -EINVAL;

// Check if Magic Number of cmd is correct

if(_IOC_NR(cmd) >= MY_IOC_MAXNR)return -EINVAL;

// Check if the sequence number of cmd is a valid value that does not exceed MAX

// Next page

#define MY_IOC_MAGIC 'c‘

#define MY_IOCSQSET _IOW(MY_IOC_MAGIC, 0, ledCtl)#define MY_IOCSQ_GPIO_SETFUNC _IO(MY_IOC_MAGIC, 1)#define MY_IOCSQ_GPIO_ACTIVE _IO(MY_IOC_MAGIC, 2)

68

ioctl() in Device Driver

// Continued

switch(cmd){case MY_IOCSQSET:{

int ret = copy_from_user((void *)&ledctl,(void *)arg, sizeof(ledctl));

// Copy to the ledctl address // by the ledctl size from the address // of the received arg variable address

}case MY_IOCSQ_GPIO_SETFUNC:{

unsigned long offset = ledctl.pin/10;unsigned long val =

ioread32(&(pRegs->GPFSEL[offset]));int item = ledctl.pin % 10;

val &= ~(0x7 << (item*3));val |= ((ledctl.funcNum & 0x7) << (item*3));iowrite32(val, &(pRegs->GPFSEL[offset]));break;

}

Reads 32-bit from the address of

GPFSEL[offset]

GPFSEL means GPIO Pin Select register.

Since 10 GPIOs are allocated and

managed by 3 bits in one register, the

input pin number is divided by 10 and

used as an index of the GPFSEL register

Write the value of val to the address of

GPFSEL[offset] by 32-bits.

To prevent portability problems, read /

write are performed using a separate

memory access function called ioread32 /

iowrite32

69

ioctl() in Device Driver

case MY_IOCSQ_GPIO_ACTIVE:{

unsigned long offset = ledctl.pin/32;unsigned long mask = (1<<(ledctl.pin%32));unsigned int count = ledctl.act.count;

while(count--){

iowrite32((u32)mask, &(pRegs->GPSET[offset]));

msleep_interruptible(100);

iowrite32((u32)mask, &(pRegs->GPCLR[offset]));

msleep_interruptible(ledctl.act.interval*500);

}break;

}} return 0;

}

Since each bit in the GPSET / GPCLR

register means the GPIO pin, the quotient

divided by 32 is used as an index

Write the value of mask to the pRegs-

>GPSET[offset] position by 32 bits(write)

The reason for casting the mask variable

to u32 is to make the data unsigned 32-bit

to prevent any problems

It is a function for sleep() / delay() that

can be used in the device driver, and used

to delay the LED blinking.

A long delay in the device driver is not

desirable

70

PRACTICES ARE ON GOING…

Q&A