This is the presentation I use as a support to my 9 hour-long talk to postgraduate students of a French Telecom and Electronics Master. The idea is to provide them with a broad view, including some non-technical domains.
2. 2/272
contents
functional
technical
business
project management
part 0 foreword
part 1 defnition?
part 2 functional vs technical
part 3 demo system
part 4 architecture
part 5 devices
part 6 positioning
part 7 identifcation
part 8 communications
part 9 platforms
part 10 central side
part 11 big data
part 12 security
part 13 standardization
part 14 ecosystem
part 15 project perspective
part 16 case studies
part 17 want to play?
part 18 conclusion
4. 4/272
who I am
Systev – Independent contractor – connected devices (Sep-2016)
Orange Labs – Senior Software Engineer (Jan-2015)
before:
– 2007 - 2011 - co-founder Systev - home computing
– 2004 - 2014 - project manager and developer at Orange Labs (M2M / IoT)
– 1997 - 2001 - team manager at France Telecom R&D
– 1990 - 2004 - co-founder ITEC (systems for moving connected objects)
– 1983 - 1993 - software engineer and project leader (McDonnell Douglas, DEC)
(several periods with 2 simultaneous jobs...)
Telecom Bretagne (now IMT Atlantique) 1982
5. 5/272
point of view
integrator's point of view:
– structuring constraints:
– to deliver on committed date and committed budget
– to deliver a working system
– to integrate / rely on legacy subsystems
– to have the broad view
– target is customer satisfaction
– solving technical problems is only a means
13. 13/272
one defnition
Internet of things: the network of physical devices, vehicles, home
appliances and other items embedded with electronics, software, sensors,
actuators, and network connectivity which enables these objects to connect
and exchange data. Each thing is uniquely identifable through its
embedded computing system but is able to inter-operate within the existing
Internet infrastructure. [Wikipedia]
many other ones exist
[Def03]
14. 14/272
conclusion
many diferent defnitions
related systems have been in use long before IoT acronym was invented
acronyms are successful because they simplify reality
reality:
– on one side: (large diversity of) user needs
– on the other side: (lot of) technologies
16. 16/272
some use cases – smart cities
Controlling shipping trafc in the
Netherlands canals with wireless sensors
Saving water with Smart Irrigation System
in Barcelona
Trafc and Road Conditions Monitoring in
Malaga
[Fct01]
17. 17/272
some use cases – smart agriculture
Precision Farming to control irrigation and
improve fertilization strategies on corn
crops
Improving banana crops production and
agricultural sustainability in Colombia
Preventing environmental impact in
wastewater irrigation area for the largest
meat industry in Australia
18. 18/272
some use cases – smart environment
Rain forest monitoring for climate change
control in Peru
Water and Air Quality Monitoring in Civil
Works
Monitoring Bee Health and Global
Pollination
19. 19/272
some use cases – smart home
Smart appliances: remote diagnostics,
proactive alerts, etc.
Water treatment: automated consumable
ordering, etc.
Fire and safety: property monitoring,
emergency alert, etc.
[Fct02]
21. 21/272
analysis
many diferent use cases, with many diferent functions
all markets are afected:
– consumer
– business
market push (for consumers?) / market pull (for business?)
provided value?
return on investment?
24. 24/272
supporting technical felds
devices
– connected embedded electronic boards
– gateways
interface to the physical world
– sensors
– actuators
– I/O, bus
embedded software
secure element
network
– wired
– wireless
– protocols
positioning
25. 25/272
supporting technical felds
identifcation
mobile application
server-side application
– container, virtual machine
– application server
– web server
– database management system
– data analytics tools
– geographical information system
– thin client, thick client
– graphical user interface
etc.
28. 28/272
specifcations
in a building, the temperature of a room must be transmitted to a central
control room and displayed to an operator
the operator must have the ability to send a command to the sensed room,
to set the color of a lamp (R, G, B, of)
what else?
32. 32/272
questions
what is a microcontroller?
how to program it?
how to connect sensors?
diferent types of wired and wireless technologies? characteristics?
how to exchange data between device and central application?
security?
how to design a whole system?
specifc characteristics of an IoT project?
etc.
what are the limitations of this demo? How to remove them?
33. 33/272
source code
source code for the whole system is available on GitHub:
https://github.com/PascalBod/ExpLoRerD2D
35. 35/272
architecture?
defnes:
– functions
– structure
– behavior
– deployment
diferent viewpoints:
– enterprise viewpoint (business requirements)
– information viewpoint (information semantics and processing)
– computational viewpoint (functions, interfaces)
– engineering viewpoint (distribution of processing)
– technology viewpoint (technologies)
[RM-ODP: Reference Model for Open Distributed Processing]
[Arc01]
36. 36/272
our demo system: enterprise viewpoint
who is the customer?
who is the user?
requirements:
– in the same building, a controlled room and a central controlling room
– an operator needs to get temperature of controlled room, on a periodic
basis. Which period? Reliability level? Which accuracy (in value and in
time)?
– the operator needs to be able to set color of a lamp in the controlled
room, when he wants. Reliability level?
37. 37/272
our demo system: information viewpoint
temperature. Celsius or Fahrenheit? Precision? Accuracy?
no specifc processing on temperature values in our system (averaging,
fltering, etc.)
LED color: 4 values only.
38. 38/272
our demo system: computational viewpoint
Central sideRemote side
setup + loop (Arduino)
LoRa messages - remote
application software - remote
Linux VM in macOS
MacBookmicrocontroller, sensor, comm. module
LoRa messages - central
software components - central
temperature
LED
GUI
software components - remote
temperature
LED
application software - central
OS API
communication
services API
low-level software API
components APIscomponents APIs
communication protocols
components protocols
application protocols
Customer-dedicated
integration
Technical components
Communication
Execution platforms
communication
services API
my own view - check standardization section for other views
incomplete: at central side, electronic board + computer...
39. 39/272
computational viewpoint
Central sideRemote side
OS
embedded device
communication services - remote
application software - remote
OS
PC / serverperipherals
communication services - central
software components - central
component
component
component
software components - remote
component
component
component
application software - central
OS API
communication
services API
OS API
components APIscomponents APIs
communication protocols
components protocols
application protocols
Customer-dedicated
integration
Technical components
Communication
Execution platforms
management
security
communication
services API
management
security
management: frmware update, device provisioning, user creation, etc.
security: data integrity, authentication, etc.
40. 40/272
our demo system: engineering viewpoint
temperature
sensor
communication
module
microcontroller
communication
module
microcontroller
PC
controlled room central control room
41. 41/272
our demo system: technology viewpoint
controlled room
(remote device)
communication
module
microcontroller
temperature
sensor
antenna
LoRa
central
application
central control room
(central device + computer)
45. 45/272
summary (and some observations)
many diferent architectures
electronics + communication + software => complexity
processing is distributed over various components => complexity
wireless network => possible loss of connectivity
46. 46/272
5. devices
5.1. device architecture
5.2. important microcontroller characteristics
5.3. interfacing with peripherals
5.4. storage
5.5. software development
5.6. summary
52. 52/272
important microcontroller characteristics
what is a microcontroller?
– on same chip: CPU + (some) memory + clock generator + peripherals
architecture:
– von Neumann, Harvard, modifed 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
– data memory width may be diferent from program memory width
– etc.
53. 53/272
important microcontroller characteristics
processing power
– depends on clock speed and architecture
– options: foating 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
54. 54/272
legacy microcontroller - example
Freescale 68HC11E1
– 8 bits
– 3 MHz
– RAM: 512 bytes - EEPROM: 512 bytes
– 38 General Purpose I/O (GPIO)
– 1 x Asynchronous Serial Communications Interface (SCI)
– 1 x Synchronous Serial Peripheral Interface (SPI)
– 8 x 8-Bit Analog-to-Digital Converter (ADC)
– 16-bit Timer System
– address / data bus for external memory
– bootstrap mode
– price: ⋍ US$7 (10 000)
[Mic01]
55. 55/272
recent microcontroller - example 1
Microchip PIC16F1705
– 8-bit data memory, 14-bit program memory
– 32 MHz
– RAM: 1 KB - Flash: 14 KB
– 2 x Capture / Compare / Pulse Width Modulation
– 1 x Universal Asynchronous Receiver Transmitter (UART)
– 1 x SCI - 1 x Inter Integrated Circuit (I2C)
– 8 x 10-bit ADC
– timers: 4 x 8-bit, 1 x 16-bit
– price: ⋍ US$0.88 (10 000)
[Mic02]
56. 56/272
recent microcontroller - example 2 (our demo system)
Microchip ATSAMD21J18 (ex-Atmel)
– 32-bit - ARM Cortex-M0+ core
– 48 MHz
– RAM: 32 KB - Flash: 256 KB
– 6 x serial comm. (UART / SPI / I2C)
– 5 x counters / timers
– 1 x real-time clock
– 1 x 20 channel 12-bit ADC
– USB
– price: < US$1.87 (10 000)
57. 57/272
recent microcontroller - example 3
NXP LPC1837JET256
– 32 bits - ARM Cortex-M3 core
– 3-stage pipeline, modifed Harvard architecture
– 180 MHz
– RAM: 136 KB - Flash: 1024 KB
– 6 x PWM
– 4 x UART - 2 x I2C - 2 x SPI
– 2 x CAN - 2 x USB - 1 x Ethernet
– 8 x 10-bit ADC
– 4 x 32-bit timers
– price: ⋍ US$8 (10 000)
[Mic03]
58. 58/272
5. devices
5.1. device architecture
5.2. important microcontroller characteristics
5.3. interfacing with peripherals
5.4. storage
5.5. software development
5.6. summary
60. 60/272
interfacing with peripherals
sensors: pressure, temperature, light level, heat, magnetic feld, airfow, 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.
62. 62/272
interfacing with peripherals - GPIO
an optocoupler may be required
software debounce may be required (a hardware debouncer is sometimes
provided by the microcontroller)
63. 63/272
interfacing with peripherals - ADC / DAC
important parameters: resolution and sampling rate
analog to digital converter (ADC):
– converts an analog voltage to a digital value
– signal conditioning may be required
– some microcontrollers provide integrated Op Amp (e.g. PIC16F527)
digital to analog converter (DAC):
– converts a digital value to an analog voltage
[Per02]
64. 64/272
float mVolts = (float)analogRead(TEMP_SENSOR) * 3300.0 / 1023.0;
float temp = (mVolts - 500.0) / 10.0;
in our demo system
component: Microchip MPC9701AT - linear active thermistor
voltage: 0 to 3.3V
ADC steps: 1023
10 mV / °C
0°C <==> 500 mV
65. 65/272
interfacing with peripherals - serial interface
V.24 / RS-232
– minimum 3 wires: transmitted data, received data, signal ground
– asynchronous communication (start bit, stop bit)
– additional wires for control signals (request to send, ready for sending, data
set ready, calling indicator, etc.)
– voltage level:
– V.28:
– bit to 1: -15 V < voltage < -3 V
– bit to 0: +3 V > voltage > +15 V
– distance: < 15 m
– connectors: DB-25, DB-9
– USA: RS-232 (TIA-232)
[Per03]
66. 66/272
UART
Address bus
Control bus
RX TTL
TX TTL
GND
level shifter
TX V.24
RX V.24
GND
CPU
microcontroller
interfacing with peripherals - serial interface
bytes are serialized using an UART (Universal Asynchronous Receiver Transmitter)
voltage levels are shifted from board voltage to V.28
for short distances, level
shifting may be omitted
67. 67/272
interfacing with peripherals - serial interface
interface characteristics:
– asynchronous => a byte starts with a start bit and ends with stop bit(s)
– speed (b/s)
– byte format (number of data bits, parity, number of stop bits)
a byte is framed. Similar to message framing described in communications
section.
mark or
previous stop bit
start bit
data bits (5 to 8) +
parity (E, O, M, S, N)
stop bit(s)
68. 68/272
in our demo system: serial interface
serial
over USB
usual PCs don’t have serial interface anymore
serial over USB is seen as a serial interface by PC application software
69. 69/272
interfacing with peripherals - SPI
Serial Peripheral Interface
– defned by Motorola (then Freescale, then NXP Semiconductors, now
Qualcomm) (1985?)
MOSI: Master Output, Slave Input SCLK: Serial Clock
MISO: Master Input, Slave Output SS: Slave Select
[Per04] [Per05]
70. 70/272
interfacing with peripherals - SPI
synchronous communication
full duplex, clock up to a few MHz
one master, one chip select per slave
4 wires
Applications:
– short distance communication (in main board vicinity)
– exemples:
– sensors (temperature, pressure, etc.)
– memory (EEPROM, etc.)
– LCD
– etc.
71. 71/272
interfacing with peripherals - I2
C
Inter-Integrated Circuit
– defned by Philips (the NXP Semincoductors now Qualcomm) (1980's)
[Per06] [Per07]
74. 74/272
interfacing with peripherals - CAN
mainly for vehicles
2-wire bus
multi-master, message broadcast system with asynchronous
communication
bus access: CSMA/CD+AMP (Carrier Sense Multiple Access / Collision Detection with
Arbitration on Message Priority)
maximum speed: 1 Mb/s
distance: up to several hundreds of meters (with “low” bit rate)
[Ser03]
75. 75/272
interfacing with peripherals - Bluetooth
Bluetooth:
– designed in 1994 by Ericsson
– originally: to replace RS-232 cables
– range: less than 100 m
– Serial Port Profle (SPP). Many other profles (audio, fle, telephony, etc.)
Bluetooth Low Energy (BLE - 4.0):
– designed for very low power operation
– optimized for data transfer
[Blu01]
76. 76/272
at a software point of view
writing low-level code to handle interfaces:
– serial interface: not too complex
– SPI, I2C: not too complex either
– CAN, Bluetooth: use existing drivers!
77. 77/272
5. devices
5.1. device architecture
5.2. important microcontroller characteristics
5.3. interfacing with peripherals
5.4. storage
5.5. software development
5.6. summary
85. 85/272
bare metal
some events generated by peripherals
input level changed
character sent
character received
counter limit reached
end of conversion
bit received
frame received
frame sent
watchdog timeout
86. 86/272
bare metal
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
save
context
restore
context
start
conversion
87. 87/272
bare metal
usual OS services not available:
– process
– thread
– synchronized access to shared resources (memory, peripherals)
– inter-thread communication
– device drivers
– fle system
– etc.
88. 88/272
bare metal
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 (fash fle system, TCP/IP
stack, etc.)
– macro defnitions preventing use of assembly language
– hardware debugger with trace capture
89. 89/272
bare metal
available tools (cont'd):
– well known design patterns:
– ring bufer
– fnite state machine (FSM)
– etc.
Note: ring bufer and FSM can be used in OS context
90. 90/272
outPtr inPtr
data
bare metal
ring bufer (or circular bufer):
– fxed-size memory array, used as an interface between a producer and a
consumer
– pointer outPtr points to frst non empty element
– pointer inPtr points to frst 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
91. 91/272
bare metal
ring bufer (cont'd):
– a ring bufer is a FIFO (First In, First Out)
– when put rate is greater than get rate, bufer gets full:
– new data overwrites oldest one, or
– put is not performed
– beware: put and get operations must be atomic
examples of use:
– receive bufer for a serial interface
– message queue for communication between two diferent pieces of code
92. 92/272
state S1
state S2
event E1 (+ condition C1)
actions A to perform
bare metal
fnite state machine:
– an abstract machine that can be in one of a fnite 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:
93. 93/272
RTOS
an RTOS (or an OS) provides many services:
– tasks
– task notifcations
– 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 confgured for the hardware platform
– larger footprint
– etc.
94. 94/272
5. devices
5.1. device architecture
5.2. important microcontroller characteristics
5.3. interfacing with peripherals
5.4. storage
5.5. software development
5.6. summary
95. 95/272
summary
complex technical subset of IoT:
– analog electronics
– digital electronics
– bus
– software
device software ≠ web server software!!!!
if you can reuse an existing design, do it!
more and more open source designs are available
location, communication: see next sections
communication
module
microcontroller
+ memoryinterfaces
location
module
user
interface
communication
network
data storage
97. 97/272
positioning - GNSS
GNSS: Global Navigation Satellite System
mostly for outdoor use
working principles:
– constellation of satellites
– every satellite sends messages: satellite position, message time
– satellite time is very accurate (atomic clock)
– listening to 3 satellites, the GNSS receiver estimates its location on earth
(distance = diference of time x speed of light)
– that's only an estimate (the receiver does not have an atomic clock)
– using a 4th satellite, the receiver synchronizes its clock
– => real location can be computed
satellite orbits: MEO (20 000 km), GEO (36 000 km)
98. 98/272
positioning - GNSS
speed of light (approx.): 3 x 108 m/s: 10 m <=> 33 ns
fx: position
accuracy:
– depends on receiver quality, on satellites being used, etc.
– documented as better than 8 m with 95% confdence level
– usual accuracy: 20 m
Dilution of Precision (DOP – PDOP/HDOP/VDOP):
– how satellite constellation geometry impacts error in computed location
– good when < 6
99. 99/272
positioning - GPS
GPS: US system
– 31 operational satellites
– MEO orbit: 20 200 km
GLONASS: Russia (formerly USSR) system
– 24 operational satellites
– MEO: 19 100 km
100. 100/272
positioning - other GNSS
Galileo: Europe
– target: 24 satellites + 6 spares
– MEO: 23 200 km
– accuracy: 8 m horiz. 9 m vert. 95% of time
– 12 operational satellites, 4 testing, 2 not fully available
– operational (15-Dec-2016)
BeiDou ( 北斗 ): China
– target: 5 GEO satellites + 30 MEO satellites
– currently: 17 satellites – operational over China
Japan (QZSS), India (NAVIC)
101. 101/272
positioning - GNSS accuracy
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
102. 102/272
positioning - GNSS augmentation systems
To increase accuracy (and integrity):
– diferential GPS
– a GPS receiver placed at a location known with very good accuracy is
used to generate corrections send to other GPS receivers
– another receiver is required
– => ⋍ 3 – 5 m accuracy
– SBAS (Satellite-Based Augmentation Systems)
– additional satellites broadcast corrections
– no other receiver required
– => ⋍ 1 – 3 m accuracy
– USA: WAAS (Wide Area Augmentation System)
– Europe: EGNOS (European Geostationary Navigation Overlay Service)
– India: GAGAN (GPS Aided Geo Augmented Navigation
– Japan: MSAS (Multi-functional Satellite Augmentation System)
103. 103/272
positioning - GNSS augmentation systems
A-GPS (Assisted GPS)
– mainly for PLMN terminals (your mobile phone...)
– almanac (coarse orbit and status information for all satellites) and ephemeris
(precise orbit for one satellite) data are sent to the GPS receiver using the
mobile network
– this reduces TTFF (Time To First Fix)
– data generated by mobile operators, or by OTT players (Google, etc.)
RTK (Real-Time Kinematic)
– signal phase is used, to get an accuracy up to a few centimeters
– fx computation can be quite long
104. 104/272
positioning - interface
command + data
interface
communication
module
microcontroller
+ memoryinterfaces
location
module
user
interface
communication
network
data storage
105. 105/272
positioning - interface
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
106. 106/272
positioning - interface
most receivers are multi-constellations (GPS, GLONASS, Galileo, BeiDou)
important: antenna placement
may be important: tamper protection
– antenna cable short circuit and antenna removal events
107. 107/272
positioning - network - misc.
network positioning:
– trilateration (several time measures)
– triangulation (several angle measures)
– cell identifcation
– “fngerprinting”
– beacons
dead reckoning: frst known position then inertial sensor fusion
(accelerometer + magnetometer and fltering)
position may be available at
– device side
– network side
108. 108/272
positioning - indoor
all previous technologies may be used for indoor positioning, depending on
constraints
but no easy-to-integrate, generic system exists today
domain still open to more innovation
109. 109/272
summary
GPS is not the only GNSS!
accuracy increases
time to frst fx decreases
other systems: keep an eye on
how to integrate a GNSS receiver: check communications section
111. 111/272
identifcation
some systems have to identify / authenticate external objects:
– truck trailers
– shipping containers
– bottles of perfumes
– bottles of wine
– etc.
112. 112/272
identifcation
RFID (Radio Frequency Identifcation):
– tag / label with (almost) unique identity
– passive (no battery) or active (battery)
– read-only or read/write
– reader: transmits
– a passive tag uses incoming energy to transmit back its data
– as usual, distance depends on power, antenna and frequency
– from a few tens of centimeters up to a few meters (more is possible)
NFC (Near-Field Communication):
– purposely short distances only (a few centimeters)
– for secure applications (e.g., contactless payment)
113. 113/272
identifcation
questions: how to identify objects on a global basis, and let every
organization exchange object data?
part of the answer: GS1
– international not-for-proft organization
– delivers standards, services and solutions
– standards:
– barcodes
– EPCglobal: tag data, tag protocols, reader protocols, ONS (Object Name
Service), discovery services, etc.
– etc.
a world in itself...
115. 115/272
communications - overview
central part of IoT systems
wireless or wired
a given system can use several network technologies
– to increase connectivity reliability
– to increase connectivity coverage
– to provide specifc properties (low power, QoS, etc.)
– to support legacy equipments
– to lower operating costs / capital costs
– etc.
116. 116/272
communications - important characteristics
shared or not
geographic coverage + possibility to adapt it
latency
connectivity setup time
addressability
required power for transmission
terminal cost
communication cost
ease of integration
throughput
confdentiality
reliability
availability
etc.
118. 118/272
framing
before going farther, let’s look at how to transmit messages over a serial
link, for instance to
– use a location module
– use a communication module
119. 119/272
radio set mod lora<CR><LF>
ok<CR><LF>
radio tx <data><CR><LF>
ok<CR><LF>
radio_tx_ok<CR><LF>
our demo system - remote device
confgure then request to send data
[Com01]
120. 120/272
radio set mod lora<CR><LF>
ok<CR><LF>
radio rx <window><CR><LF>
ok<CR><LF>
radio_rx <data><CR><LF>
our demo system - central device
confgure then wait for received data
[Com01]
121. 121/272
data encoding
<data>: hexadecimal value of bytes to be transmitted, in ASCII characters
example 1:
– bytes to be transmitted: 0x01 0x02 (16 bits)
– characters transmitted after encoding: 0102
(4 x 8 = 32 bits - 0x30 0x31 0x30 0x32)
example 2:
– letter T - ASCII code is 0x54
– characters transmitted after encoding: 54
(0x35 0x34)
122. 122/272
to summarize
communication module interface: messages over serial link
two types of messages:
– control
– data to be exchanged with remote side
a message must be recognized as a message:
– delimiters (<CR><LF>)
– transparency: it must be possible to send <CR><LF> characters to the other
side => hexadecimal coding
– more details in next slides
what happens if a message exchanged with the module is corrupted or
lost?
– more details in next slides
124. 124/272
framing - general case
control bytes:
– to confgure the module (link speed, power mode, etc.)
– to signal specifc events
data bytes:
– for a GNSS receiver: location, satellite information, etc.
– for a communication module: data to be sent to / received from remote side
multiplex control bytes and data bytes
error control
sequence control
fow control
time-out control
transparency
=> framing + acknowledgement + possible repetition
125. 125/272
framing - general case
header payload
check
sequence
detailed frame structure depends on protocol
header may contain:
– packet numbering
– number of last good packet received
– frame class
– etc.
check sequence:
– result of a mathematical operation performed on previous bytes
– receiver performs the same operation and compares result
Questions:
– how to know when a frame starts and when it stops?
– how to ensure transparency for payload?
126. 126/272
framing - delimitation
several solutions for delimitation:
– byte count
– fag bytes
– etc.
byte count:
fag bytes:
header payload
check
sequence
payload
size
header payload
check
sequence
B E
128. 128/272
framing - transparency
use a predefned escape byte, ESC for instance
on transmission side:
– when E is in payload, insert an ESC before it
– when ESC is in payload, insert another ESC before it
on reception side:
– when ESC is received, delete it and keep following byte
another solution: reduce payload byte set!
etc.
129. 129/272
framing - always required?
framing is always required
but error processing may be ignored in some environments (typically on
short links in non-noisy environments)
130. 130/272
framing - NMEA 0183 example
$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47
fag byte
only readable
ASCII characters
(no CR)
fag byte: CR
check
sequence
132. 132/272
wireless - PMR
Professional Mobile Radio
– not accessible to consumer
– frequency + associated bandwidth allocated to a user for a given period
– user: private or public organization (company, city, association, etc.)
– cost: annual fee (“license fee”) per terminal. In France:
– fee = I x bf x c x k4 + n x G
– I: bandwidth, in MHz
– bf: depends on frequency
– c: depends on coverage
– k4: constant
– n: number of mobile users
– G: constant
133. 133/272
wireless - PMR
Frequency (bands):
– 40 MHz, 80 MHz, 150 MHz, 400 MHz, etc.
Technology:
– analog – voice + data (modem) – 6,25 or 12,5 kHz channels – 1200 b/s
– digital:
– DMR (Digital Mobile Radio) – 2 slot TDMA over 12,5 kHz channels – 9000
kb/s for 2 slots
– dPMR – FDMA over 6,25 kHz channels – 4800 b/s
– TETRA (TErrestrial Trunk RAdio) – 4 slot TDMA over 25 kHz channels –
7200 b/s per slot – for shared networks
– TETRAPOL – FDMA – for shared networks
– TEDS, GSM-R
Coverage:
– from ⋍ 30 km (mono-site) up to wide area coverage (multi-sites / trunk)
TDMA: Time Division Multiple Access
FDMA: Frequency Division Multiple Access
134. 134/272
wireless - PMR - data
data communication:
– usually, using a dedicated connector on transceiver
– analog:
– let's forget about it...
– digital:
– DMR: status messages (≤ 128 bytes) - short messages (≤ 36 bytes) –
packet data
– dPMR: short messages (≤ 100 bytes) - packet data
– TETRA: short messages (≤140 bytes) - packet data
135. 135/272
wireless - PMR
in 2016:
– around 25.000 PMR networks in France
users:
– taxis, public transports, ambulances, airports, highways, security, industry,
constructions, etc.
– public organizations: cities, hospitals, etc.
[Com06]
136. 136/272
wireless - unlicensed
France regulation:
– AFP = Appareils de Faible Puissance et de Faible Portée
– freely accessible
– 6.8 MHz, 13.6 MHz, 27.0 MHz, 40.7 MHz, 433.0 MHz, 434.0 MHz, 863-868...
MHz, 2.4 GHz, 5.7-5.9 GHz, 24... GHz, 61 GHz, 122-123 GHz, 244-246 GHz
– ERP: depends on frequency - from 1 mW to 500 mW
– some restrictions on duty cycle, on channel spacing, etc.
– some other frequencies, for specifc equipments
– usual range: up to a few kilometers, unobstructed LoS
– throughput: from several 100s of b/s to several 1000s of b/s
ERP: Efective Radiated Power
LoS: Line of Sight
137. 137/272
wireless - unlicensed long range
for a given radiated power and a given bit error rate, range can be
increased either by:
– using lower bit rate with traditional modulation technologies. But this narrows
spectrum => precise frequency reference is required to decode received
modulation.
or by
– using spread spectrum modulation. But processing is complex.
Examples:
– SIGFOX (choice 1) - technology + network operator
– range: documented as up to 40 km LoS
– LoRa (Semtech) (choice 2) - technology (chipsets)
– range: documented as up to 15 km LoS
138. 138/272
wireless - zoom on LoRa / LoRaWAN
modulation: CSS (Chirp Spread Spectrum)
robust against interference and fading
multiple signals can be sent on same RF channels, with diferent spreading
factors (SF)
error correction in physical layer
LoRaWAN:
– provides Adaptative Data Rate (SF management) => battery life, network
capacity
– interoperability device / network
– security
– etc.
142. 142/272
our demo system: LoRa
LoRaWAN requires a network infrastructure
we could have used Orange or Objenious networks
but what about local coverage?
=> we use LoRa only, in device-to-device mode
Microchip RN2483 in LoRa mode only
143. 143/272
wireless - PLMN
Public Land Mobile Network
two main families of standards / technologies:
– 3GPP: 3rd Generation Partnership Project
– GSM, GPRS, EDGE, HSDPA, HSUPA, MBMS, LTE, LTE Advanced...
– 3GPP2: 3rd Generation Partnership Project 2
– CDMA2000, UMB, LTE...
shared between anybody who subscribes
broad coverage, but target is population, not territory
144. 144/272
wireless - 3GPP
data services:
– CSD (Circuit Switched Data): obsolete
– SMS (Short Message Service)
– 140 to 160 characters / bytes
– USSD (Unstructured Supplementary Service Data)
– specifc services
– packet data - IP compatible
– throughputs (beware: uplink ≪ downlink):
– 2.5G: 8 to 40 kb/s (GPRS) – EDGE = GPRS x 3
– 3G: 2 Mb/s non-moving, 384 kb/s moving
– 3.5G: 14.4 Mb/s (HSDPA)
– 4G: 100 Mb/s and more (LTE)...
GPRS: General Packet Radio Service
EDGE: Enhanced Data rates for GSM Evolution
HSDPA: High-Speed Downlink Packet Access
LTE: Long Term Evolution
145. 145/272
wireless - 3GPP IoT-oriented
three LPWA technologies in Release 13:
– NB-IoT (Narrow-Band IoT)
– EC-GSM-IoT (Extended Coverage GSM for the IoT)
– LTE-M (LTE for Machines)
LPWA : Low Power Wide Area
146. 146/272
wireless - NB-IoT
power consumption decreased => battery life > 10 years (!)
spectrum efciency improved
extended coverage (rural and deep indoors)
low device complexity => low cost
147. 147/272
wireless - EC-GSM-IoT
based on eGPRS (EDGE for GPRS)
software upgrade of existing GSM networks
battery life > 10 years (!)
148. 148/272
wireless - LTE-M
simplifed term for LTE-MTC CatM1
lower device complexity - cost reduced to 25% of current eGPRS modules
extended coverage
battery life > 10 years (!)
149. 149/272
wireless - LPWA comparison
10 year life impossible if received signal too low
data rate can be decreased => longer TX => lower battery life
[Com04]
152. 152/272
wireless - 3GPP - IP connectivity
APN (Access Point Name):
– name of gateway between 3GPP network and the Internet - real name: GGSN
– defned by the operator
– defnes following gateway characteristics:
– static or dynamic IP address
– public or private IP address
– allowed protocols (TCP, UDP, etc.)
– allowed ports
153. 153/272
wireless - 3GPP - IP connectivity with IP stack in µc board
mobile network
the Internet
GGSN (APN)
1 - attach
2 – defne and activate context + start comm.
=> comm. module known
to network
=> IP address assigned to
comm. module
3 – start a PPP session
=> IP address assigned to
remote device
communication
module
microcontroller
board
AT commands
GGSN: GPRS Gateway Support Node[Com03] [Com04]
154. 154/272
wireless - 3GPP - IP connectivity
1/ attach:
AT+CGATT=1
OK
2/ defne PDP context 3:
AT+CGDCONT=3,"IP","orange.m2m.spec"
OK
activate PDP context 3:
AT+CGACT=1,3
OK
establish communication using PDP context 3:
ATD*99***3#
CONNECT
3/ start a PPP session
155. 155/272
wireless - 3GPP - IP connectivity with IP stack in µc board - router
mobile network
the Internet
GGSN
1 - register
2 – define and activate context + start comm.
=> comm. module known
to network
=> IP address assigned to
comm. module
AT commands
3 – define NAT / PAT rule
=> comm. module
performs NAT / PAT
communication
module
microcontroller
board
156. 156/272
wireless - 3GPP - IP connectivity without IP stack in µc board
mobile network
the Internet
GGSN (APN)
1 - attach
2 – defne and activate context + start comm.
=> comm. module known
to network
=> IP address assigned to
comm. module
3 – send / receive data
communication
module
microcontroller
board
AT commands
157. 157/272
wireless - 3GPP - programmable comm. module
mobile network
the Internet
GGSN (APN)
1 - attach
2 – defne and activate context + start comm.
=> comm. module known
to network
=> IP address assigned to
comm. module
3 – send / receive data
communication
module +
application
API
158. 158/272
wireless - satellites
geostationary orbits
– characteristics:
– 36.000 km above the Earth
– satellite seen from Earth as stationary
– coverage restricted to desired zone
– minimum end-to-end latency: 2 x 36.000 km / 300.000 km/s => 240 ms
– Inmarsat:
– BGAN M2M: IP at up to 448 kb/s – latency from 800 ms – global coverage
except polar regions
– IsatM2M: messages of 25 (up) / 100 (down) bytes – latency 30 to 60 s –
global coverage except polar regions
– IsatData Pro: messages of 6.4 (up) / 10 (down) kB – latency 15 to 60 s –
global coverage except polar regions
– Thuraya
BGAN: Broadband Global Area Network
159. 159/272
wireless - satellites
low earth orbit (LEO)
– characteristics:
– satellites constantly in motion around the Earth
– altitude: 170 – 2000 km => period: 90 – 130 min.
– low power
– higher latency !
– Orbcomm:
– messages of 6 to 30 bytes
– average latency: 6 min.
– global coverage
– Globalstar
– Iridium
– Argos
160. 160/272
wireless - short distance
Wi-Fi
– wireless local area network (WLAN) technology based on IEEE802.11
standards
– Wi-Fi Alliance owns the brand (not an abbreviation...)
– range: usually up to 100 m outdoors
Bluetooth
– originally designed to replace serial cables – personal area network (PAN)
– managed by the Bluetooth Special Interest Group
– range: less than 100 m
– many profles
– Bluetooth Low Energy (part of V4.0)
– Bluetooth Mesh
161. 161/272
wireless - short distance
ZigBee
– managed by ZigBee Alliance
– low-power
– range: up to 100 m
– mesh network => long distance by retransmitting data
Z-Wave
– managed by Z-Wave Alliance - for home automation
– low-power
– range: around 30 m
– mesh network
162. 162/272
wireless - comparison
Techno Shared Range Latency Setup time
PMR no from 30 km up to wide
area
depends on architecture 0
unlicensed 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
163. 163/272
wireless - comparison - 2/2
Techno Addressability TX power Equipment cost Comm. cost
PMR full W 100s € 0 €
unlicensed full mW 10s € 0 €
2.5G/3G restricted W 100s € fat rate
4G restricted W 100s € --> 10s € fat rate
satellites
geo
restriced W 1000s € high
satellites
LEO
restricted W 100s € high
Wi-Fi full mW 10s € 0 €
164. 164/272
wireless - 3 dimensions
3 dimensions, for wireless networks:
– technology
– regulations
– operator
example 1:
– 4G is a technology mainly used for public cellular networks
– operators (Orange, Verizon, etc.) have to buy licenses
– 4G can be used on private networks as well
example 2:
– Sigfox is an operator using its proprietary technology on license-free bands
– the technology could be used on licensed bands as well
example 3:
– LoRa is a technology used on license-free bands
– there are several operators (Orange, Bouygues Telecom, etc.)
– the technology can be used by consumers as well
– the technology can be used on licensed bands as well
166. 166/272
wired
leased lines
– permanent connection between two locations
– analog or digital – symmetric throughput (unlike ADSL)
– example for France:
– Orange Transfx: up to 2048 Kb/s
– for IoT / M2M: more or less obsolete
Public Switched Telephone Network (PSTN)
– requires a modem (modulator – demodulator)
– up to 56 Kb/s
– cost proportional to duration (depends on package)
– long setup time (up to 20 or 30 s)
– for IoT / M2M: not so used
Asymmetric Digital Subscriber Line (ADSL)
– pseudo permanent connection
167. 167/272
wired
Local Area Network (LAN)
– Ethernet
feld buses:
– PROFIBUS
– DeviceNet
– INTERBUS
– FOUNDATION
– Modbus
– Sercos
– PROFINET
– Powerlink
– EtherCAT
– etc.
169. 169/272
messaging protocols
just a few words about 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 communications / framing section. Simpler, for TCP, thanks to TCP
characteristics:
– ordered data transfer
– error-free data transfer
170. 170/272
messaging protocols
data serialization - endianness independency:
– ASN.1: defned 30 years ago by CCITT (now ITU-T) – not so used in
M2M/IoT...
– Google re-invented a solution in 2008: Protocol Bufers – not so used either in
M2M/IoT... (but framing not provided...)
– CBOR (Concise Binary Object Representation): IETF - 2013
– advantages:
– reliable solutions
– data endianness independency
– transparent serialization/deserialization
– forward compatibility
– drawbacks:
– some complexity
– Protocol Bufers needs framing
– libraries in various languages to encode / decode frames
– not so difcult to defne your own mechanism
171. 171/272
messaging protocols
applying web technologies to IoT / M2M communications is often not the
right choice:
– HTTP: request / response (=> polling), ASCII, complex parsing
– XML: verbose
– JSON: still too verbose
one beneft:
– go through frewalls and proxies
but should IoT / M2M communications be transported along with web
communications?
172. 172/272
messaging protocols - MQTT
MQTT acronym comes from Message Queue (not present in MQTT!) and
Telemetry Transport (but MQTT is not restricted to telemetry)
maintained by OASIS Consortium (Organization for the Advancement of Structured Information
Standards)
mixes messaging with publish / subscribe (one to many - application
decoupling)
based on TCP/IP (MQTT-SN for non TCP/IP networks)
small transport overhead
abnormal disconnection notifcation
free open source implementations:
– Eclipse Mosquitto (server)
– Eclipse Paho (clients in various languages)
173. 173/272
messaging protocols - CoAP
Constrained Application Protocol
maintained by the IETF (Internet Engineering Task Force) - RFC7252
request / response – designed to easily interface with HTTP
based on UDP or equivalent
low transport overhead
low parsing complexity
resource discovery (a client queries a server)
several free open source implementations of CoAP (client, server)
174. 174/272
messaging protocols - other
many other protocols:
– Open Wireless Telematics Protocol (designed by Mobile Devices)
– Cloud Connector (designed by Digi)
– etc.
not so difcult (for really experienced developer) to defne one's own
protocol
175. 175/272
device management protocols
OMA DM: specifed by Open Mobile Alliance (OMA)
OMA DM supports:
– device provisioning (device initialization and confguration)
– software updates (application and system software)
– fault management (reporting faults, querying status)
for M2M: OMA Lightweight M2M (LWM2M)
– based on CoAP
– open source implementation: Eclipse Wakaama project
176. 176/272
summary
many diferent technologies
understanding real user needs is important, to choose right network
technology/technologies
perhaps the most important part of a system, as it transfers data from on
side to the other one
perhaps the most difcult part of a system, at a technical point of view
178. 178/272
platforms
beware: the word « platform » may have diferent 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, that makes easier to integrate devices
into applications
180. 180/272
platforms
Central sideRemote side
OS
embedded device
communication services - remote
application software - remote
OS
PC / serverperipherals
communication services - central
software components - central
component
component
component
software components - remote
component
component
component
application software - central
OS API
communication
services API
OS API
components APIscomponents APIs
communication protocols
components protocols
application protocols
Customer-dedicated
integration
Technical components
Communication
Execution platforms
management
security
communication
services API
management
security
181. 181/272
platforms
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
182. 182/272
platforms
connected device central side
platform
platform
code solving
customer problem
code solving
customer problem
customer
pays for this,
not for the
platform
relative sizes of software
code,
for a complex system
183. 183/272
platforms
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 usually 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
187. 187/272
platforms - example - Sierra Wireless
connectivity management
– SIM inventory
– usage tracking
– etc.
application enablement
– RESTful API
– data storage
– rules engine
– device protocol support
– etc.
device management
– device monitoring
– command transmission
– OTA frmware update
– confguration deployment
– etc.
[Pla02]
188. 188/272
platforms - how to use one
usual steps, to use a platform for a new development:
– register
– check list of supported devices, and select one, possibly a simulated 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
190. 190/272
overview
REST: representational state transfer
invented in 2000 - an architecture, not a protocol
– client-server
– stateless
– cacheable
– layered system
– uniform interface
– [code on demand]
for web services: RESTful APIs
– base URL
– HTTP method (GET, HEAD, PUT, POST, DELETE, TRACE, CONNECT)
– data elements - JSON
191. 191/272
example - when you visit google.com from France
client server
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0
Host: google.com
Accept: */*
open TCP socket with address google.com
HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Location: https://www.google.fr/?gfe_rd=cr&ei=J8-MWPedMPL-8AePwISQDA
Content-Length: 259
Date: Sat, 28 Jan 2017 17:04:39 GMT
Alt-Svc: quic=":443"; ma=2592000; v="35,34"
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="https://www.google.fr/?gfe_rd=cr&ei=J8-MWPedMPL-8AePwISQDA">here</A>.
</BODY></HTML>
192. 192/272
example - AirVantage API
client server
GET /api/v1/users/current?access_token={token} HTTP/1.1
....
{
uid: "81210eca05484d34a29bc6c34dc31bf7",
email: "dsciamma@sierrawireless.com",
name: "David Sciamma",
company: {
uid: "97ba9e22078548a2847912a87152e3f4",
name: "Sierra Wireless"
},
profle: {
uid: "df1c0f7d5f8c4db2b45978f98e1093ad",
name: "Manager"
}
}
193. 193/272
example - AirVantage API
after authentication:
– get received data
– send command to a device
– get monitoring data
– etc.
196. 196/272
communication server
communication server:
– provides an interface to communicate with devices
– may handle several diferent 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.
198. 198/272
our demo system
JavaFX application implementing all functions:
– GUI
– communication server
– application layer
source lines of code (SLOC): around 1700
[Cen01]
200. 200/272
communication server
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.
201. 201/272
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
202. 202/272
Geographic Information Systems
some applications need
– to perform spatial operations and / or
– to display spatial information
at a technical point of view, two diferent elements:
– functions:
– spatial queries against spatial database
– spatial libraries
– data:
– digital maps
– georeferenced data
at an architectural point of view:
– web GIS
– rich client
203. 203/272
Geographic Information Systems
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.
205. 205/272
Geographic Information Systems
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
206. 206/272
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
208. 208/272
big data
data sets too large / too complex to be processed with traditional tools
we are not talking about Terabyte (1012 bytes)
we are talking about Petabyte (1015 bytes), Exabyte (1018 bytes), etc.
Volume, Velocity, Variety
some tools:
– Hadoop (distributed processing - MapReduce, YARN, HDFS)
– Spark (analytics over Hadoop fle system)
– Cassandra (distributed NoSQL)
– ElasticSearch (analytics)
– many, many, many more tools
– check http://bigdata.andreamostosi.name/
209. 209/272
where is big data?
Q: why big data is not addressed in the central side section?
210. 210/272
where is big data?
A:
– currently, big data technologies are used at central side
– remember: an IoT system is a whole
– more power processing available on the edge and in devices
– => big data processing could be distributed over devices soon
212. 212/272
an example
for electric vehicle prototypes: data about battery, electric engine, location,
speed, etc.
for 100 vehicles during one year:
– 400 MB x 100 x 12 = 480 GB - this is not big data!
for 1 million vehicles during one year:
– 400 MB x 1 000 000 x 12 = 4.8 x 1015 B (4.8 Petabytes) - this is big data
but...
213. 213/272
an example
but
– current mobile data plans are currently too expansive for such volumes
– mobile network coverage is currently not full => bufering is required =>
memory cost
– there is enough processing power AND energy in a vehicle => processing can
be performed on the fy, so that only main results are sent to the central side
216. 216/272
information security
we talk about information security only
three objectives, according to the CIA triad:
– confdentiality
– integrity
– availability
217. 217/272
checklist
business processes:
– who is in charge?
– how to address security?
device hardware and physical security:
– secure boot process
– no active debug interface
– physical protection against tampering
– etc.
device application:
– signed software
– signed remote software updates
– unused ports are disabled
– good practice coding standard
– well defne source code management
– safe failures
– etc.
[Sec01]
218. 218/272
checklist
device operating system:
– most current patches
– plan for remote update
– non-essential services are remoed
– etc.
device wired and wireless interfaces:
– unauthorized connections are prevented
– IP packets forwarding between interfaces is disabled
– unused ports are closed
– if existing, default connection password is unique to each device
– connections are secured (TLS...)
– etc.
[Sec01]
219. 219/272
checklist
authentication and authorization:
– code and data are binded to a specifc devie hardware
– a password can’t be null or blank
– protection against repeated login attempts
– stored passwords are encrypted
– etc.
encryption and key management for hardware:
– true random number generator
– tamper proof location for sensitive data
– etc.
web user interface:
– strong user authentication
– automatic session timeout
– input validation
– etc.
[Sec01]
220. 220/272
checklist
mobile application:
– minimum required amount of personal information is stored
– personal user data is encrypted
– stored passwords are encrypted
– etc.
privacy:
– only authorised personnel have access to personal data of users
– personal data is anonymized
– data retention policy
– product owner is informed about data collection
– etc.
cloud and network elements:
– latest security patches
– webserver identifcation switched of
– etc.
[Sec01]
221. 221/272
checklist
secure supply chain and production:
– test and calibration software erased before dispatch
– duplicate serial numbers are detected
– securely controlled area may be required
– etc.
[Sec01]
222. 222/272
summary
security is a world by itself
it applies to all subcomponents
a broad view is required
rely on real experience
[Sec01]
224. 224/272
standardization
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 side should be able to communicate with any central
side
– any central side should be able to communicate with any central
side
– any side 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)
225. 225/272
standardization
in Europe: ETSI (European Telecommunications Standards Institute)
most of ETSI M2M 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
229. 229/272
standardization
many other standardization organizations:
– Open Connectivity Foundation
– Thread Group
– Hypercat Consortium
– Industrial Internet Consortium (IIC)
– Global Standards Initiative on Internet of Things (IoT-GSI)
– ITU Joint Coordination Activity on IoT (JCA-IoT)
– TIA TR-50
– Open Mobile Alliance (OMA)
– OMG Data-Distribution Service for Real-Time Systems (DDS)
– IEEE IoT Architecture Working Group
230. 230/272
standardization
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)
231. 231/272
standardization
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
235. 235/272
ecosystem
more realistic view:
Software
developer
Middleware
developer
Software
component
developer
Device
manufacturer
Location
technology
provider
Wireless
module
manufacturer
Network
operator
Integrator Installer
Geocoded data
provider
Customer
Service
provider
Embedded OS
developer
User
Sensor /
actuator
manufacturer
Embedded
software
developer
Electronic
board
manufacturer
Hosting
236. 236/272
ecosystem
many diferent 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 difcult to diagnose
240. 240/272
agility
We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on
the left more.
[Pro08]
245. 245/272
example - user needs - 1/4 B
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
247. 247/272
example - user needs - 2/4 B
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
– => modifcation of some delivered functions
– => decision about new ones to be added
– => new version
– several successive versions
be agile
249. 249/272
example - user needs - 3/4 B
project: RFP for a bus schedule checking system
« big brother » feeling: bus drivers could decide to go on strike
– => frst 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
251. 251/272
example - user needs - 4/4 B
project: for a customer, develop a system allowing to check inner workings
of several car prototypes
provider's Business Unit asked their R&D to develop the system. They
decided on a monthly 40 MB data package (usual data packages: 10
MB).
R&D work was done by beginners in the domain. They implemented a thin
client architecture, and were very proud of it (M2M 2.0!) But monthly data
volume was more than 400 MB! And data was lost for every lengthy loss of
connectivity.
keep broad view in mind
don't think you are clever than other people when you enter a new domain
253. 253/272
example - technology - 1/4 B
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
255. 255/272
example - technology - 2/4 B
for a taxi dispatch system:
– the provider ordered an onboard device from a very well known
company (new product)
– two design faws appeared after frst tests (HW + SW)
no time for correction: a software workaround had to be implemented
never assume things work as documented (bis)
plan for contingencies
257. 257/272
example - technology - 3/4 B
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 efort:
– => 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
259. 259/272
example - technology - 4/4 B
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
261. 261/272
example - legal aspects - B
project: frst 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
263. 263/272
hardware for devices
many, many, many open source and/or free (or low cost) materials
microcontroller boards:
– BeagleBone Black Wireless (Wi-Fi BT) 69 €
– ESP-WROVER-KIT (Wi-Fi, camera interface) 44 €
– CHIP Pro (Wi-Fi BT - open source) US$ 16
– Arduino
check http://systev.com/iot-device-dev-kits/
electronics:
– https://www.adafruit.com/
– http://www.cooking-hacks.com/
– http://www.seeedstudio.com/
– https://www.tindie.com/
– Farnell, Mouser, RS
check http://www.monblocnotes.com/node/2114
264. 264/272
software for devices
software development tools for devices:
– BeagleBone Black Wireless: Linux
– ESP-WROVER-KIT: dedicated RTOS SDK
– CHIP Pro: Linux
– Arduino: Arduino IDE
various software stacks:
– protocols (refer to previous slides)
– etc.
265. 265/272
software for central side and communications
open source platforms
– DeviceHive
– FI-WARE
– Home*Star
– IoTivity
– Kaa
– Nimbits
– Node-RED
– OpenIoT
– OpenRemote
– SiteWhere
– thinger.io
267. 267/272
conclusion
developing IoT systems can be challenging because:
– large diversity of user needs
– sometimes difcult to get real user needs
– diferent software development paradigms
– integration of technologies from diferent felds
268. 268/272
conclusion
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, if you choose this domain, you'll have fun!
BTW there is a long distance between our system demo and a real system
:-)