IoT and M2M for Software Developers

IoT and M2Mfor software developersPascal BODIN31-Jan-2015

V20150131https://creativecommons.org/

https://creativecommons.org/

2/147

contents

part 0 foreword

part 1 some use cases

part 2 some definitions

part 3 overall architecture

part 4 devices

part 5 central side

part 6 communication protocols

part 7 project leading perspective

3/147

0. foreword

part 0.1 who I am

part 0.2 why we won't speak about software only

4/147

who I am

Pascal Bodin – Orange Labs – Sophia-Antipolis, France

– Orange Software Expert– Orange Labs Products & Services Senior Software Developer

10 years as M2M and IoT project leader and software engineer at Orange Labs

before this:

– 4 years as co-founder + system developer + co-manager - home computing– 14 years as co-founder + system developer + manager - M2M/IoT– 4 years as team manager at France Telecom R&D– 10 years as software engineer (McDonnell Douglas, DEC)

(several periods with 2 simultaneous jobs...)

5/147

why we won't speak only about software

IoT/M2M system:

– devices– connections between devices and real world– various types of networks– huge number of different use cases– user needs often not well known– agility is OK for software, but what about hardware?

=> a global view is required

6/147

1. some use cases

7/147

container tracking

8/147

taxi dispatch

Taxis waiting at taxi stand

Cruising taxi

Central dispatch office

Sector 1

Sector 2 Customer

9/147

environmental monitoring

10/147

logistics

11/147

home automation

12/147

smart grid

13/147

remote monitoring of copy machines

14/147

2. some definitions

15/147

let's share same vocabulary

central sideremote side

machinevehicle

etc.

(embedded)device

gateway

centralsystem

useradministrator

enterpriseinformation

system

16/147

IoT/M2M definitions? - 1/3

The Internet of Things (IoT) is the interconnection of uniquely identifiable embedded computing devices within the existing Internet infrastructure. [Wikipedia - 13-Jan-2015]

The Internet of Things (IoT) is the network of physical objects that contain embedded technology to communicate and sense or interact with their internal states or the external environment. [Gartner - 13-Jan-2015]

A global infrastructure for the Information Society, enabling advanced services by interconnecting (physical and virtual) things based on, existing and evolving, interoperable information and communication technologies. [ITU-T - 04-Jul-2012]

Industrial IoT is a universe of intelligent industrial products, processes and services that communicate with each other and with people over a global network. [Accenture - 14-Oct-2006]

IoT could mean almost anything. In some ways it is better to think of it as the internet of everything. [The Guardian - 06-Nov-2014]

17/147


M2M refers to technologies that allow both wireless and wired systems to communicate with other devices of the same type. [...] M2M is considered an integral part of the Internet of Things. [Wikipedia - 15-Jan-2015]

M2M is about connecting a device to the cloud, managing that device, and collecting machine and sensor data. [...] IoT represents things connecting with systems, people and other things. [Axeda - 22-Jan-2014]

M2M is what provides The Internet of Things with the connectivity that enables capabilities, which would not be possible without it. [Telefónica - 14-Oct-2013]

Like M2M, most solutions that people call "IoT" are just SCADA-based solutions with a less technical interface and/or explanation. [Novotech - 24-Feb-2014]

18/147


to summarize many different definitionsmost of them focus on (communication) technologies

acronym means buzzIoT and M2M acronyms are relatively newIoT/M2M systems existed long before acronymsacronyms are successful because they simplify reality

reality on one side: (lot of) technologieson the other side: (large diversity of) user needs

always ask more details......to someone using IoT/M2M acronyms!

19/147

3. overall architecture

20/147

architecture

let's consider a feature-rich example, with some specific characteristics:

– (human perceived) real-time– asynchronous downlink messages– data + voice

looking at such a system lets understand architecture more easily

21/147

architecture

our example system: a taxi dispatch system

some functions:

– customer request allocated to the best taxi– taxi driver acknowledgement– taxi ride follow-up– credit card payments– general messages (e.g. « speed camera at... »)– personal messages (e.g. « call your wife back »)– security alarm, with audio monitoring– taxi locating– driver can display taxi distribution over the city– driver can display request distribution over the city– etc.

22/147

architecture

Taxis waiting at taxi stand

Cruising taxi

Central dispatch office

Simplified dispatch algorithm

· city is divided in sectors

· one taxi stand at most per sector

· taxis can be waiting at a stand, or cruising

· taxi request dispatch:• sector is selected (depending on customer

address)• if taxis waiting at stand, first taxi complying with

services requirements is selected• if stand is empty, a cruising taxi is selected

(usually the nearest one)• if no cruising taxi in sector, search is broadened

to neighbouring sectors• etc.

· selected taxi driver must acknowledge the request

Sector 1

Sector 2

23/147

architecture

To device: are you really here? If yes, here is a request for the driver

From device to dispatch office: yes, I'm here

Displayed to driver:Service

requirements.Do you accept them?

Displayed to driver:Address.

Do you accept the request?

From driver to dispatch office: yes, I accept the request

Request allocated to taxi 1

Taxi 1

To other taxis at same stand: request allocated to taxi 1

customer request dispatch

24/147

architecture

at a technical point of view:

– uplink and downlink messages, in (human perceived) real-time– non trivial application code in embedded/onboard device– different data transport services:

– without acknowledge– with acknowledge– unicast– broadcast– voice

– tight coupling between embedded application and central application

25/147

architecture

Central sideRemote side

OS

embedded device

communication services - remote

application software - remote

OS

PC / serverperipherals

communication services - central

software components - centralsoftware components - remote

application software - central

OS API

communication services APIcommunication services API

OS API

components APIscomponents APIs

communication protocols

components protocols

application protocols Customer-dedicated integration

Technical components

Communication

Execution platforms

26/147

architecture

communication layer:

– bidirectional messaging, with/without ack, unicast, broadcast– voice call– « broadcast »– etc.

technical components layer (almost generic)

– mission dispatch handling– alarm with end to end acknowledgement– software odometer– etc.

application layer:

– adaptation to end-user needs this is an ideal view!

27/147

4. devices

part 4.1 architecture

part 4.2 important microcontroller characteristics

part 4.3 interfacing with peripherals

part 4.4 connectivity

part 4.5 positioning

part 4.6 software development

28/147

architecture

communicationmodule

microcontroller(memory)

(embedded) device

interfaceslocationmodule

user interface

communication network

29/147

example

microcontroller

communicationmodule

locationmodule

analog inputs

digital I/O

30/147

communication module - 1/2

communication module can be managed as a peripheral of the microcontroller

31/147

communication module - 2/2

communication module can host application software

32/147

4. devices







33/147

important microcontroller characteristics - 1/2

what is a microcontroller?

– on same chip: CPU + (some) memory + clock generator + peripherals architecture:

– von Neumann, Harvard, modified Harvard– one core or multicore

memory types and sizes:

– read-only memory (program): ROM/PROM/EPROM/EEPROM/Flash...– read/write memory (data): RAM/SRAM/DRAM/MRAM/FRAM...– data memory and program memory can be separated

memory width:

– 4-bit, 8-bit, 16-bit, 32-bit– 8-bit for data, 12-bit for program– etc.

34/147

important microcontroller characteristics - 2/2

processing power

– depends on clock speed and architecture– options: floating point operations, digital signal processing, etc.

power consumption

– various low-power modes cost

supporting hardware tools

– development board– programmer / debugger– open source schematic

supporting software tools

– integrated development environment– open source code

support

35/147

4. devices







36/147

interfacing with peripherals - 1/8

peripheral: any device not being part of the IoT/M2M device we are considering, and attached to it

sensors: pressure, temperature, light level, heat, magnetic field, airflow, tilt, acceleration, switch, push button, etc.

actuators: relay, motor, stepper motor, servomotor, etc.

other devices: printer, display, On-Board Diagnostics connector, RFId tag reader, etc.

interface can be wired or wireless.

37/147


general purpose digital input/output (GPIO):

– read or set a voltage (high / low)

38/147


analog to digital converter (ADC):

– converts an analog voltage to a digital value digital to analog converter (DAC):

– converts a digital value to an analog voltage

39/147


serial bus: serial interface / V.24 / RS-232

– minimum 3 wires: transmitted data, received data, signal ground– additional wires for control signals (request to send, ready for sending, data

set ready, calling indicator, etc.)– voltage level:

– V.28: -15V / +15V or– board voltage

– distance: < 15 m

40/147


serial bus: SPI (Serial Peripheral Interface)

– four-wire synchronous serial bus– master/slave– short distance– for sensors (temperature, pressure, etc.)– for LCDs– etc.

SPI Master

SCLK MOSI MISO SS1 SS2 SS3

SPI Slave

SCLK MOSI MISO SS

SPI Slave

SCLK MOSI MISO SS

SPI Slave

SCLK MOSI MISO SS

41/147


serial bus: I2C (Inter-Integrated Circuit)

– two-wire synchronous serial bus– multi-master– short distance– same applications than for SPI

42/147


serial bus: CAN (Controller Area Network)

– mainly for vehicles (e.g. OBD)– often: 4 wires (including power)– multi-master– distance: up to several hundreds of meters (with “low” bit rate)

43/147


Bluetooth:

– originally designed to replace serial cables – personal area network (PAN)– range: less than 100 m– many profiles– Bluetooth Low Energy (part of V4.0)

44/147

at a software point of view

writing low-level code to handle interfaces:

– serial interface: not too complex (see interrupts + ring buffer)– SPI, I2C: not too complex either– CAN: more complex– Bluetooth: forget about it! Use an existing driver.

45/147

what can we do with a microcontroller? - 1/2

taxi driver

taxi central dispatch office

taxi

repeater

46/147

what can we do with a microcontroller? - 2/2

with a Freescale 68HC11 (25+ years old, still in use)

– 8 KB RAM, 32 KB Flash, 8 bits, 2 MHz embedded code:

– drivers: LCD, transceiver and handset serial buses, GPS receiver, data storage, I/O

– cell-roaming– application-layer protocol stack– ride handling– lists of busy and free taxis per sector– lists of booked rides per sector– alarm handling (data + voice)– start and end of service– alarm pedal, taximeter– etc.

47/147

4. devices







48/147

connectivity

allows for data transfer with a remote system (≠ peripheral)

wireless:

– PMR (Private/Professional Mobile Radio)– low power / short range, on unlicensed frequencies– 2.5 G / 3G / 4G– satellites– Wi-Fi– Bluetooth, ZigBee, Z-Wave

wired:

– LAN (Local Area Network)– leased lines– PSTN (Public Switched Telephone Network)– ADSL (Asymmetric Digital Subscriber Line)

49/147

connectivity

communicationmodule

microcontroller(memory)interfaces

locationsystem

user interface


command + datainterface

50/147

connectivity

commands, events and data:

– configure– start connection– stop connection– connection status– send data– received data– incoming call– etc.

interface definition depends on

– communication module <=> network technology– device architecture (microcontroller + comm. module ≠

smartphone/programmable module)

51/147

connectivity - example 1

for an unlicensed RF module (Digi XTend)

– serial interface– commands and data sent in frames– binary protocol

0x7E

Start delimiterbyte 1

MSB LSB

Lengthbytes 2, 3

data

Frame databytes 4 - n

CS

Checksumbyte n + 1

data: transmit request, transmit status, received data, etc.

52/147

connectivity - example 2

AT commands:

– quite common: 3GPP communication modules, modems, etc.– ASCII protocol– command / response – intermediate result codes – unsolicited result codes– example for 3G:

– define context number 3 with given APN, requesting IP protocol:

communicationmodule


AT+CGDCONT=3,”IP”,”orange.m2m.sec”

OK

53/147

connectivity - 3GPP networks - 1/2

APN (Access Point Name):

– name of gateway between 2.5G / 3G / 4G network and another network (usually the Internet)

– defined by the operator– for the Internet, defines following gateway characteristics:

– static or dynamic IP address– public or private IP address– allowed protocols (TCP, UDP, etc.)– allowed ports

54/147

connectivity - 3GPP networks - 2/2

mobile network the Internet

APN

1 - register

2 – define and activate context

=> comm. module known to network

=> IP address assigned to comm. module

3 – start a PPP session

=> IP address assigned to remote device

communicationmodule

device

AT commands

55/147

connectivity - comparison - 1/2

Techno Shared Range Latency Setup time

PMR no from 30 km up to wide area

depends on architecture 0

low power yes up to 10 (40) km depends on architecture 0

2.5G/3G yes wide area from 100 ms up to 1 s from 2 s to 5 s

4G yes wide area 50 ms 1 s

satellites geo

yes global 800 ms to 60 s depends

satellites LEO

yes global min depends

Wi-Fi yes local ms s

56/147

connectivity - comparison - 2/2

Techno Addressability TX power Equipment cost Comm. cost

PMR full W 100s € 0 €

low power full mW 10s € 0 €

2.5G/3G restricted W 100s € flat rate

4G restricted W 100s € --> 10s € flat rate

satellites geo

restriced W 1000s € high

satellites LEO

restricted W 100s € high

Wi-Fi full mW 10s € 0 €

57/147

4. devices







58/147

positioning - 1/5

GNSS: Global Navigation Satellite System

USA: GPS

– 31 operational satellites (24-Dec-2013)– accuracy documented as better than 8 m with 95% confidence level

Russian Federation: GLONASS

– 23 operational satellites (22-Feb-2014) Europe: Galileo

– 6 satellites with 2 on incorrect orbits (22-Aug-2014) - first fix: 12-Mar-2013

– target: 30 satellites China: BeiDou (北斗 )

– 10 satellites – operational over China– target: 5 GEO satellites + 30 MEO satellites

Japan: QZSS, India: IRNSS

59/147

positioning - 2/5

example of accuracy:

– GPS receiver indoor, not far from a window => lower reception quality– one location every 2 s, for 15 minutes– several locations are more than 60 m far from the real location

60/147

positioning - 3/5

communicationmodule

microcontroller(memory)interfaces

locationsystem

user interface


command + datainterface

61/147

positioning - 4/5

interface:

– usually: serial (V.28 or board voltage)– usually: implements subset of NMEA 0183 standard

– most manufacturers provide their own protocol:– SiRF (then CSR, now Samsung) – u-blox - SkyTraq – ST – Broadcom – etc.

$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47

Where: GGA Global Positioning System Fix Data 123519 Fix taken at 12:35:19 UTC 4807.038,N Latitude 48 deg 07.038' N 01131.000,E Longitude 11 deg 31.000' E 1 Fix quality: 0 = invalid 1 = GPS fix (SPS) 2 = DGPS fix 3 = PPS fix 4 = Real Time Kinematic 5 = Float RTK 6 = estimated (dead reckoning) (2.3 feature) 7 = Manual input mode 8 = Simulation mode 08 Number of satellites being tracked 0.9 Horizontal dilution of position 545.4,M Altitude, Meters, above mean sea level 46.9,M Height of geoid (mean sea level) above WGS84 ellipsoid (empty field) time in seconds since last DGPS update

62/147

positioning - 5/5

it's possible to increase GNSS accuracy

– differential GPS, SBAS (WAAS, EGNOS, GAGAN, MSAS), A-GPS, RTK network positioning:

– trilateration (several time measures)– triangulation (several angle measures)– cell identification– “fingerprinting”– more ?

dead reckoning: first known position then inertial sensor fusion (accelerometer + magnetometer and filtering)

outdoor / indoor?

63/147

4. devices







64/147

development environment

● source code edition● compilation / link● simulation● debugging

● load / run● emulation● debugging

LPCXpresso

VxWorks GNU toolchainTASKING ...

PC running Linux, OSX, Windows

microcontroller board

Atmel Studio

65/147

execution environment

Morpheus3

VxWorks

RTX

OS

RTOS

specific runtime

interrupt handlers + background task

...

...

...

Esterel

Lustre

bare metal

Ada

66/147

bare metal - 1/9 let's look more closely at a microcontroller architecture

67/147

bare metal - 2/9 some events generated by peripherals

input level changed

character sentcharacter received

counter limit reached

end of conversion

bit receivedframe receivedframe sent

watchdog timeout

68/147

bare metal - 3/9

an event generates an interrupt

attach an interrupt handler to the interrupt you want to handle

example: analog to digital conversion

time

background task

end of conversion

interrupt handler

background task

interruption

savecontext

restorecontext

start conversion

69/147

bare metal - 4/9

usual OS services not available:

– process– thread– synchronized access to shared resources (memory, peripherals)– inter-thread communication– device drivers– file system– etc.

70/147

bare metal - 5/9

it's less complex than it appears for small applications

very useful for some classes of requirements:

– (very) small memory footprint– low power consumption– low cost

available tools:

– some commercial or open source code is available (flash file system, TCP/IP stack, etc.)

– macro definitions preventing use of assembly language– hardware debugger with trace capture

71/147

bare metal - 6/9

available tools (cont'd):

– well known design patterns:– ring buffer– finite state machine (FSM)– etc.

– ring buffer and FSM can be used even in OS context

72/147

outPtr inPtr

data

bare metal - 7/9

ring buffer (or circular buffer):

– fixed-size memory array, used as an interface between a producer and a consumer

– pointer outPtr points to first non empty element– pointer inPtr points to first empty element– to get next element: read outPtr, read data, increment outPtr– to put a new element: read inPtr, write data, increment inPtr– when at the end of the array, pointer is reset to start of array

73/147

bare metal - 8/9

ring buffer (cont'd):

– a ring buffer is a FIFO (First In, First Out)– when put rate is greater than get rate, buffer gets full:

– new data overwrites oldest one, or– put is not performed

– beware: put and get operations must be atomic examples of use:

– receive buffer for a serial interface– message queue for communication between two different pieces of code

74/147

state S1

state S2

event E1 (+ condition C1)

actions A to perform

bare metal - 9/9

finite state machine:

– an abstract machine that can be in one of a finite number of states– the machine is in only one state at a time (current state)– transition from one state to another one is triggered by an event (possibly

guarded by a condition)– one possible way to graphically depict an FSM:

75/147

RTOS

an RTOS (or an OS) provides many services:

– tasks– task notifications– queues– semaphores– mutexes– timers– memory protection– etc.

easier to write feature-rich applications but:

– experience is still required– debugging can be more complex (but easier as well!)– an RTOS must be configured for the hardware platform– larger footprint– etc.

76/147

5. central side

part 5.1 architectures

– functional view– architectures– communication server– databases– GIS– User Interface

part 5.2 platforms

part 5.3 developing with platforms

77/147

functional view


communication server

application software

data persistence

UI (user interface)

GIS (Geographic Information System)

device management

user management

78/147

architectures

previous architecture is not a reference one!

architecture view is always influenced by architect's experience and activity

– mine is the one of an integrator having to build full vertical systems– platform architects have a different view– standardization organisations have another one– telecom operators have another one– etc.

functional and physical architectures depends on:

– number of devices– security requirements– position in value chain (to be seen later)– etc.

79/147

communication server - 1/4

communication server:

– provides an interface to communicate with devices– may handle several different network technologies– switching to another network technology or supporting a new one should be

easy and rapid– other usual requirements:

– security concerns: authentication, integrity, privacy, (non-repudiation)– reliability– scalability– etc.

80/147


example:

– for PMR or unlicensed radio

antennas transceivers + modems


81/147


example:

– for 3GPP


Internet

82/147


3GPP example (cont'd):

– uplink (from devices to server):– server IP address must be reachable => public or VPN

– downlink:– device IP address characteristics depend on APN

– static or dynamic?– public or private?

– several solutions depending on user need and required genericity:– device initiates and maintains a TCP session– server sends an SMS to device, requesting its connection– devices connects periodically– private APN => VPN– etc.

83/147

databases

3 main technologies:

– relational database– object database– NoSQL database

another dimension to be considered sometimes:

– spatial database (but GIS function can be provided as a service) a question may arise:

– do application data have to be separated from “technical” data?– there is no one right answer

another question:

– should all device generated data be mirrored in the central database?– again: there is no one right answer

84/147

Geographic Information Systems - 1/4

some applications need

– to perform spatial operations and / or– to display spatial information

at a technical point of view, two different elements:

– functions:– spatial queries against spatial database– spatial libraries

– data:– digital maps– georeferenced data

at an architectural point of view:

– web GIS– rich client

85/147


all-in-one (functions + data) web GIS:

– Google Maps JavaScript API– Bing Maps APIs– etc.

functions only web GIS:

– MapServer (Open Source)– GeoServer (Open Source)– etc.

functions only rich client GIS:

– GRASS GIS (Open Source)– QGIS (Open Source)– uDig (Open Source)– etc.

86/147


data:

– OpenStreetMap (Open Source)

87/147


many providers of commercial products:

– rich client / desktop GIS– web GIS– data (vector, bitmap, additional layers)

GIS is a complex matter:

– do not try to reinvent the wheel– take some time to get some experience

88/147

User Interface

as for GIS: web or rich client

web:

– ⊕ good for large number of distributed users– ⊕ can be good for supporting multi-device / multi-OS– ⊕ good for software updates– ⊖ usually bad for user-perceived response time– ⊖ usually bad for « real-time » or complex user interfaces– ⊖ usually bad for license cost– etc.

rich client:

– almost the other way round... mixing the two of them can be a good solution

89/147

central side


– functional view view– architectures– communication server– databases– GIS– User Interface

part 5.2 platforms


90/147

platforms - 1/4

beware: the word « platform » may have different meanings

– software development framework– software application providing communication (and possibly management and

storage) services– a hosted application providing above services– hardware system– hardware system and associated software stack– etc.

in what follows: hosted application

91/147

platforms - 2/4

functions usually provided by a platform (as seen by a user):

– device provisioning– device management– device authentication– support of some communication protocols– user authentication– data persistence (raw data or decoded data?)– device groups– user groups– easy way to add new communication protocols– etc.

two logical interfaces: one for devices, one for applications

92/147

platforms - 3/4

remote system central system

platformplatform

layers solvingcustomer problem

layers solvingcustomer problem

customerpays for this,

not for the platform

relative sizes of software layers,

for a complex system

93/147

platforms - 4/4

perceived value is often not in the platform

a platform may prevent from using some devices (which do not implement a supported protocol)

a platform creates a protocol break

when updating the platform, ALL users are impacted

developing a communication layer + minimum device management is not complex for an experienced team

=> think twice before deciding on using a platform

anyway, using a platform may be very nice, for some (simple) applications, to demonstrate a new service, or for very large sets of devices

at least 60 platforms today on the market (including some Open Source'd)

– http://www.monblocnotes.com/node/1979

94/147

central side


– functional view view– architectures– communication server– databases– GIS– User Interface

part 5.2 platforms


95/147

platforms - 1/2

often, two different logical interfaces:

– devices– central application

96/147

platforms - 2/2

usual steps, to use a platform for a new development:

– register

– check list of supported devices, and select one– download client source code or library– build an « Hello World » client (send/receive data)– test it

– check send/receive data using available web application– download central application source code or library– build an « Hello World » application (send/receive data)– test it

– test the whole system

97/147

6. communication protocols

part 6.1 introduction

part 6.2 UDP, TCP

part 6.3 MQTT

part 6.4 CoAP

part 6.5 other protocols

98/147

introduction

communication protocol:

a system of digital rules for data exchange within or between computers [Wikipedia]

remember connectivity part? We saw two protocols:

– Digi XTend– AT commands

used to control communication module

once communication module (and communication link) is in the right state, data can be exchanged with remote application

99/147

introduction

some characteristics of protocols:

– stream-oriented or message-oriented– data integrity– ordered delivery– duplicate detection– error detection– error recovery– addressing– etc.

protocol stack: piece of software that implements a protocol

100/147

protocols - 1/5

piece of advice:

– reuse existing protocol and associated stack as often as possible– be sure that chosen protocol fulfils your needs– be sure you use the protocol in the correct way

example: TCP

– TCP is a stream-oriented protocol:– “Hello world” can be received as “Hell” and then “o world”– “Hello” and then “ world” can be received as “Hello world”

– => framing is required (see next slide)

– to transmit a file, rely on TCP integrity mechanism: do not use application ack for every n bytes

– TCP disconnection is not signalled: use a keep-alive mechanism if required

101/147

frame

frame coding/decoding:

– ASN.1: defined 30 years ago by CCITT (now ITU-T) – not so used in M2M/IoT...

– Google re-invented a solution in 2008: Protocol Buffers – not so used either in M2M/IoT...

– advantages:– reliable solutions– data endianness independency– transparent serialization/deserialization– forward compatibility

– drawbacks:– some complexity– Protocol Buffers needs framing

– libraries in various languages to encode / decode frames– not so difficult to define your own mechanism

102/147



part 6.2 UDP, TCP

part 6.3 MQTT

part 6.4 CoAP


103/147

UDP, TCP

UDP, TCP:

– not specific to IoT/M2M– acronyms well known, functions not so well known

– remember: TCP is a stream-oriented protocol, not a message-oriented one (framing is required)

– TCP disconnections are not signalled– addressability:

– port and protocol filtering (3GPP networks for instance)– public or private IP addresses– static or dynamic IP addresses

104/147



part 6.2 UDP, TCP

part 6.3 MQTT

part 6.4 CoAP


105/147

MQTT

MQTT:

– name comes from Message Queue Telemetry Transport– but MQTT does not really queue messages, and is not restricted to telemetry – current version: 3.1.1 (29-Oct-2014)– originated from IBM and Arcom (now Eurotech) (1999)– now maintained by OASIS Consortium (Organization for the Advancement of Structured

Information Standards)

106/147

MQTT

characteristics:

– client server publish/subscribe messaging transport protocol– server side defines a message broker

– requires TCP as underlying protocol, or a protocol providing ordered, lossless, bi-directional connections

– quality of service for message delivery:– at most once, at least once, exactly once

– notifies abnormal disconnections– according to its specification:

– light weight, open, simple, easy to implement– small code footprint

– security, if required:– username and password– SSL– application-level encryption

107/147

MQTT

example of use case

108/147

MQTT

MQTT implementations:

– Eclipse IoT - Paho project (open source)– C/C++ clients– MQTT-SN (Sensor Networks) C client– Java J2SE client– Android client (service)– JavaScript client (uses WebSockets)– Python client– Go client– C# client (.Net and WinRT)– a sandbox server is available

– Eclipse IoT - Mosquitto project (open source)– MQTT and MQTT-SN C server

109/147

MQTT

MQTT implementations (cont'd):

– HiveMQ:– server– interesting list of MQTT client tools

– etc.

110/147



part 6.2 UDP, TCP

part 6.3 MQTT

part 6.4 CoAP


111/147

CoAP

CoAP:

– Constrained Application Protocol– current version: June 2014– designed and maintained by IETF (Internet Engineering Task Force) - RFC7252

112/147

CoAP

characteristics:

– designed for constrained nodes (8-bit microcontrollers)– relies on UDP– low header overhead– low parsing complexity– « web protocol »

– complies with REST architecture– stateless HTTP mapping– support URIs and content-type– simple proxy and caching capabilities

– supports multicast– security:

– DTLS (Datagram Transport Layer Security) bindings

113/147

CoAP

114/147

CoAP

CoAP implementations:

– Eclipse IoT - Californium project (open source)– core– Scandium project: security– Actinium project: server– tools– connector– a sandbox server is available

– other implementations: check Wikipedia

115/147



part 6.2 UDP, TCP

part 6.3 MQTT

part 6.4 CoAP


116/147

other protocols

Open Wireless Telematics Protocol

– designed by Mobile Devices– for CloudConnect platform– uses ASN.1

M3DA

– open source protocol– used by AirVantage platform (Sierra Wireless)– uses Bysant serializer

Cloud Connector

– designed by Digi– for Etherios platform

LWM2M (LightweightM2M)

– from OMA (Open Mobile Alliance) - for device management etc.

And XML/HTTP or JSON/HTTP?!Why not? But think at data volume

and power consumption...

117/147

other protocols

LWM2M implementations:

– Eclipse IoT - Wakaama project (open source)– C client and server– a sandbox server is available

118/147

project leading perspective

part 7.1 open or free or low cost hardware and software

part 7.2 ecosystem

part 7.3 standards

part 7.4 some concrete examples

119/147

open or free hardware/software - 1/3

many, many, many open source and/or free (or low cost) materials

microcontroller boards:

– BeagleBone 46 € (Black)– Arduino 36 € (Due)– NXP LPCXpresso 20 € (LPC1115)– Freescale FRDM KLxx 10 € (KL05Z)– etc. (check http://monblocnotes.com/node/1849)

electronics:

– http://www.cooking-hacks.com/– http://www.seeedstudio.com/– https://www.tindie.com/– Farnell, Mouser, RS– etc.

120/147


software development tools for devices:

– BeagleBone Black: Linux usual toolchain– Arduino: Arduino IDE– LPCXpresso: LPCXpresso IDE (Eclipse based)

– some components are closed– FRDM KLxx: Kinetis Design Studio IDE– etc.

various software stacks:

– protocols (refer to previous slides)– etc.

121/147


software (for central application):

– open source platforms– FI-WARE– IoTivity– nimbits– OpenIoT– OpenRemote– etc.

– protocol stacks: see previous slides– additionally: GIS (see previous slides), relational databases (MySQL,

PostgreSQL, etc.), noSQL databases (Cassandra, CouchDB, etc.)– etc.

122/147



part 7.2 ecosystem

part 7.3 standards


123/147

ecosystem - 1/4

what we saw:

– many different use cases– several different technologies

=> ecosystem and value chain are complex

124/147

ecosystem - 2/4

usually, value chain is depicted like this:

125/147

ecosystem - 3/4

more realistic view:

Software editor Middleware editor

Application software component editor Object manufacturer

Positioning technology provider

Radio terminal manufacturer

Network operator Integrator Installer Geocoded data provider

Customer Service provider

Embedded OS editor

Customer's customers

delivers to

not all links are presentedoriginally drawn for B2B systems

126/147

ecosystem - 4/4

many different type of activities

– it's quite common that one company runs several activities important activity: integration

– the integrator tries to get a working system! another important activity, often forgotten about:

– installation (at home, in a vehicle, in a factory...)– bad installation => lot of glitches, very difficult to diagnose

127/147



part 7.2 ecosystem

part 7.3 standards


128/147

standards - 1/6

some “old” standards:

– V.24, V.28, etc.– MODBUS, Fieldbus, etc.– SPI, I2C, etc.

but that's really far from being enough

let's dream:

– any remote system should be able to communicate with any central system

– any central system should be able to communicate with any central system

– any system receiving a new type of data should be able to know whether it has to process this data, and/or what it means (semantics, ontology)

129/147

standards - 2/6

in Europe: ETSI (European Telecommunications Standards Institute)

– M2M communications

130/147

standards - 3/6

most of ETSI standardization work has been transferred to oneM2M in 2012

oneM2M is a global partnership project (China, Japan, Europe, North America, etc.)

OMA (Open Mobile Alliance) is member of oneM2M

goal:

develop technical specifications which address the need for a common M2M Service Layer that can be readily embedded within various hardware and software

131/147

standards - 4/6

many other standardization organizations:

– Open Interconnect Consortium (OIC)– Thread Group– AllSeen Alliance– Hypercat Consortium– Industrial Internet Consortium (IIC)– Global Standards Initiative on Internet of Things (IoT-GSI)– ITU Joint Coordination Activity on IoT (JCA-IoT)– oneM2M– TIA TR-50– Open Mobile Alliance (OMA)– OMG Data-Distribution Service for Real-Time Systems (DDS)– IEEE IoT Architecture Working Group

132/147

standards - 5/6

many other standardization organizations (cont'd):

– Internet Engineering Task Force (IETF)– IPSO Alliance– W3C Web of Things Community Group– W3C Semantic Sensor Network Incubator Group– ZigBee Alliance– ULE Alliance– Z-Wave Alliance– etc. (see http://www.monblocnotes.com/node/2034)

133/147

standards - 6/6

Q: so many standards... What to do with them?

A: what you want

more seriously:

– for an integrator:– try to use standardized interfaces and products– stay informed

134/147



part 7.2 ecosystem

part 7.3 standards


135/147

usual difficulties

a project must deliver a technical solution that matches user needs

difficulties:

– user needs not defined correctly– complex ecosystem– unreliable communication network– too many standards / lack of standards– system distributed over several physical components– electronics and software do not obey same life cycles– some specific software expertise required– high reliability sometimes required– etc.

following examples: how some difficulties were handled (or not)

136/147

example - user needs - 1/3

project: RFP for a waste collection management system

time spent talking with the customer led project team to understand that there was no need for real-time data transmission

proposal: truck data downloaded by wire at the end of the day

– => lower operating cost than competitors' proposals– contract signed, while the provider had no experience about waste

collection management system

understand customer needs better than himself

137/147


project: RFP for a taxi dispatch system

taxi drivers had no experience of a dispatch system

neither the provider

agreement about « agility »:

– minimum viable product delivered as soon as possible– feedback from drivers and dispatch people

– => modification of some delivered functions– => decision about new ones to be added– => new version

– several successive versions

be agile

138/147


project: RFP for a bus schedule checking system

« big brother » feeling: bus drivers could decide to go on strike

– => first delivered functions were providing immediate value to bus drivers (free voice calls, attack alarm)

– => no more problem with trade unions

rapidly deliver value to the users

139/147

example - technology - 1/4

GPRS was documented as THE solution for packet data over GSM networks

one undocumented trap:

– connectivity reset by the operator on a periodic basis not a big deal for developers used to wireless technology

but a problem for many developers used to LAN

never assume things work as documented

140/147


for a taxi dispatch system:

– the provider ordered an onboard device from a very well known company (new product)

– two design flaws appeared after first tests (HW + SW) no time for correction: a software workaround had to be implemented

never assume things work as documented (bis)

plan for contingencies

141/147


for corrected version of previous device, manufacturer introduced new functions required by other customers

– => design too complex– => cost too high

it was decided to perform design in-house.

costly effort:

– => skills ramp-up– => development of an SDK + testing tools

but return on investment:

– control over roadmap– cost reduction by using device for all projects (some components not

assembled, depending on project)– etc.

control core technology

142/147


request to an electronic design company: design a low power consumption device, sending some sensor data to a central application, on a periodic basis.

they designed a board with:

– a low power microcontroller– a low power communication module

but, to upload the few KB of data on a periodic basis, they used FTP (instead of byte streaming over TCP for instance)

– => longer connections– => data overhead– => more power used!

keep the broad view in mind

143/147

example - legal aspects

project: first french « Pay As You Drive » service, for a car insurance company

the system was designed and developed

then, authorization was requested from CNIL (French Personal Data Protection Agency)

– answer was: « no » system had to be re-designed

think about legal aspects before it's too late

144/147

conclusion

145/147

conclusion - 1/2

developing software for an IoT/M2M system can be challenging because:

– large diversity of user needs– sometimes difficult to get real user needs– different software development paradigms– integration of technologies from different fields

146/147

conclusion - 2/2

perhaps more than in other domains:

– spend time with users– get (really) experienced with involved technologies– get the overall view– be agile– design/use hardware that allows for agility (easy (remote) update)

but, in any case, have fun!!

147/147

thanks

[email protected]

www.monblocnotes.com

@PascalBod06

fr.linkedin.com/in/pascalbodin/