Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

IoT and connected devices: an overview

668 views

Published on

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.

Published in: Engineering
  • Be the first to comment

IoT and connected devices: an overview

  1. 1. IoT and connected devices Pascal BODIN 2018 V20180217
  2. 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
  3. 3. 3/272 0. foreword
  4. 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. 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
  6. 6. 6/272 1. defnition?
  7. 7. 7/272 in the '70s - '80s [Def01] [Def02]
  8. 8. 8/272 in the '70s - '80s  SCADA (Supervisory Control And Data Acquisition)
  9. 9. 9/272 in the '90s
  10. 10. 10/272 in the '90s  M2M (Machine to Machine)  LBS (Location Based Services)
  11. 11. 11/272 in the '00s
  12. 12. 12/272 in the '00s  IoT (Internet of Things)
  13. 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. 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
  15. 15. 15/272 2. functional vs technical
  16. 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. 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. 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. 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]
  20. 20. 20/272 some use cases – smart xxx  many more use cases!!
  21. 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?
  22. 22. 22/272 supporting technical felds  Question: which technologies?
  23. 23. 23/272 supporting technical felds electronics software communications IoT
  24. 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. 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.
  26. 26. 26/272 summary  many diferent use cases  many diferent technologies involved
  27. 27. 27/272 3. demo system
  28. 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?
  29. 29. 29/272 engineering viewpoint temperature sensor communication module microcontroller communication module microcontroller PC controlled room central control room
  30. 30. 30/272 technology viewpoint controlled room (remote device) communication module microcontroller temperature sensor antenna LoRa central application central control room (central device + computer)
  31. 31. 31/272 information viewpoint controlled room central control room about every 30 s: temperature set LED to R, G, B or of about every 30 s: temperature
  32. 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. 33/272 source code  source code for the whole system is available on GitHub: https://github.com/PascalBod/ExpLoRerD2D
  34. 34. 34/272 4. architecture
  35. 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. 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. 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. 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. 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. 40/272 our demo system: engineering viewpoint temperature sensor communication module microcontroller communication module microcontroller PC controlled room central control room
  41. 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)
  42. 42. 42/272 other possible architectures - 1 gateway central side connected device local wireless network long distance network
  43. 43. 43/272 other possible architectures - 2 central side connected device long distance network
  44. 44. 44/272 other possible architectures - 3 personal side connected device long distance network
  45. 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. 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
  47. 47. 47/272 communication module microcontroller + memoryinterfaces location module user interface communication network data storage device architecture
  48. 48. 48/272 our demo system communication module microcontroller temperature sensor antenna board: €78,65 [Dev05]
  49. 49. 49/272 another example [Dev01] [Dev02] [Dev03] [Dev04] microcontr. board: $12.50 GSM/GPS module: $49.95 GSM antenna: $2.95 GPS antenna: $3.95 analog inputs digital I/O microcontroller + memory location + communication module
  50. 50. 50/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
  51. 51. 51/272 communication module microcontroller + memoryinterfaces location module user interface communication network data storage device architecture
  52. 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. 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. 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. 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. 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. 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. 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
  59. 59. 59/272 communication module microcontroller + memoryinterfaces location module user interface communication network data storage device architecture
  60. 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.
  61. 61. 61/272 interfacing with peripherals - GPIO  general purpose digital input/output (GPIO): – read or set a voltage (high / low) [Per01]
  62. 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. 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. 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. 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. 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. 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. 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. 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. 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. 71/272 interfacing with peripherals - I2 C  Inter-Integrated Circuit – defned by Philips (the NXP Semincoductors now Qualcomm) (1980's) [Per06] [Per07]
  72. 72. 72/272 interfacing with peripherals - I2 C  multi-master  clock up to a few MHz  2 wires  applications: – same than SPI
  73. 73. 73/272 interfacing with peripherals - CAN  Controller Area Network – defned by Bosch (1986) [Per08]
  74. 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. 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. 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. 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
  78. 78. 78/272 communication module microcontroller + memoryinterfaces location module user interface communication network data storage device architecture
  79. 79. 79/272 storage  when on-chip memory is not enough  additional memory: – important parameters: – bus type (serial, parallel) – max number of program / erase cycles (e.g. 3 000, 100 000) – write time (e.g. page erase - word / page write) – soldered IC: – EEPROM 512 Kb (<=> 64 KB) - 8 pins - SPI - ⋍ US$1.3 – 8 Gb (<=> 1 GB) - 48 pins - multiplexed A/D buses - ⋍ US$8.0 – memory card: – MMC, SD, miniSD, microSD, etc. – ex.: microSD 1 GB ⋍ US$27
  80. 80. 80/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
  81. 81. 81/272 development environment ● source code edition ● compilation / link ● simulation ● debugging ● load / run ● emulation ● debugging LPCXpresso VxWorks GNU toolchain TASKING ... PC running Linux, OSX, Windows microcontroller board Atmel Studio
  82. 82. 82/272 execution environment Morpheus3 VxWorks RTX OS RTOS specifc runtime interrupt handlers + background task ... ... ... Esterel Lustre bare metal Ada
  83. 83. 83/272 our demo system: device code  Arduino  source lines of code: – remote device: around 600 – central device: around 600 – common parts
  84. 84. 84/272 bare metal  let's look more closely at a microcontroller architecture
  85. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  96. 96. 96/272 6. positioning
  97. 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. 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. 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. 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. 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. 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. 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. 104/272 positioning - interface command + data interface communication module microcontroller + memoryinterfaces location module user interface communication network data storage
  105. 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. 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. 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. 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. 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
  110. 110. 110/272 7. identifcation
  111. 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. 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. 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...
  114. 114. 114/272 8. communications 8.1. overview 8.2. framing 8.3. wireless networks 8.4. wired networks 8.5. messaging protocols
  115. 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. 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.
  117. 117. 117/272 8. communications 8.1. overview 8.2. framing 8.3. wireless networks 8.4. wired networks 8.5. messaging protocols
  118. 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. 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. 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. 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. 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
  123. 123. 123/272 general case communication module microcontroller + memoryinterfaces location module user interface communication network data storage command + data interfaces command + data interfaces
  124. 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. 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. 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
  127. 127. 127/272 framing - delimitation  fag byte: how to allow E byte to be present in payload?  => transparency
  128. 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. 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. 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
  131. 131. 131/272 8. communications 8.1. overview 8.2. framing 8.3. wireless networks 8.4. wired networks 8.5. messaging protocols
  132. 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. 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. 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. 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. 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. 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. 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.
  139. 139. 139/272 wireless - zoom on LoRa / LoRaWAN [Com07]
  140. 140. 140/272 wireless - zoom on LoRa / LoRaWAN [Com07]
  141. 141. 141/272 wireless - zoom on LoRa / LoRaWAN [Com07]
  142. 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. 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. 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. 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. 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. 147/272 wireless - EC-GSM-IoT  based on eGPRS (EDGE for GPRS)  software upgrade of existing GSM networks  battery life > 10 years (!)
  148. 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. 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]
  150. 150. 150/272 interfacing with 3GPP module  AT commands, defned in 3GPP TS 27.007 (and TS 07.07)  commands: [Com02]
  151. 151. 151/272 interfacing with 3GPP module  responses:
  152. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  165. 165. 165/272 8. communications 8.1. overview 8.2. framing 8.3. wireless networks 8.4. wired networks 8.5. messaging protocols
  166. 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. 167/272 wired  Local Area Network (LAN) – Ethernet  feld buses: – PROFIBUS – DeviceNet – INTERBUS – FOUNDATION – Modbus – Sercos – PROFINET – Powerlink – EtherCAT – etc.
  168. 168. 168/272 8. communications 8.1. overview 8.2. framing 8.3. wireless networks 8.4. wired networks 8.5. messaging protocols
  169. 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. 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. 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. 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. 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. 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. 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. 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
  177. 177. 177/272 9. platforms 9.1. architecture and services 9.2. RESTful API
  178. 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
  179. 179. 179/272 platforms central side connected device long distance network
  180. 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. 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. 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. 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
  184. 184. 184/272 many platforms ? Afero deviceWISE Microtronics end-to-end platform Sine-Wave AggreGate dweet.io Mobius SIMPro AirVantage Electric Imp MODE SmartThings Ark Enterprise2Cloud mozaiq Solair ARTIK Cloud EVRYTHNG Murano TempoIQ AT&T's M2X Exosite myDevices The ThingBox AWS IoT FlowCloud Nabto thethings.iO Axeda IoT Platform Gaonic Neo ThingFabric AXON GoFactory Net4Things ThingPlug Ayla IoT Cloud Fabric Golgi Netatmo Connect ThingSpeak Beebotte IFTTT netObjex Thingsquare Berg iMotion NetPro ThingWorx Blynk Impact n.io UnificationEngine Bosch IoT Suite Initial State Octoblu Verizon's M2M platform Busit IoTAcceleration Platform OpenMTC Vortex Canopy Itron OpenSensorCloud Waygum Carriots Hologram Cellular Platform OpenSensors waylay CloudConnect Home2Cloud Open.Sen.se WyzBee Combicloud IBM IoT Cloud Parse Xively Concirrus IoTfy People Power - now FabrUX Yaler Connext DDS IoT lab Plat-One Zatar Coversant IoT Cloud IoT-X PubNub Dashboard of Things iQmenic REDtone IOT Canopy dataplicity Kii resin.io DeviceHive Datavenue Lelylan restack FI-WARE Deutsche Telekom's M2M Device Cloud Loop RuBAN Home*Star / IOTDB Device Connection Platform Lumata Samsung SAMIIO IoTivity DeviceCloud M2M Intelligence SAP HANA Kaa DeviceHub MachineShop SensorLogic macchina.io DevicePilot mbed Device Server SkyNet Nimbits Node-RED OpenIoT OpenRemotecheck http://www.monblocnotes.com/node/1979 opensource
  185. 185. 185/272 our demo system: if we had used Orange LoRaWAN...
  186. 186. 186/272 our demo system: if we had used Orange LoRaWAN...
  187. 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. 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
  189. 189. 189/272 9. platforms 9.1. architecture and services 9.2. RESTful API
  190. 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. 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&amp;ei=J8-MWPedMPL-8AePwISQDA">here</A>. </BODY></HTML>
  192. 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. 193/272 example - AirVantage API  after authentication: – get received data – send command to a device – get monitoring data – etc.
  194. 194. 194/272 10. central side
  195. 195. 195/272 computational viewpoint  communication server  database  geographic information system (GIS) functions  data fltering and processing  user interface(s)  etc.
  196. 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.
  197. 197. 197/272 communication server  example: – for PMR or unlicensed radio antennas transceivers + modems communication server [Cen01]
  198. 198. 198/272 our demo system  JavaFX application implementing all functions: – GUI – communication server – application layer  source lines of code (SLOC): around 1700 [Cen01]
  199. 199. 199/272 communication server  example: – for 3GPP communication server Internet
  200. 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. 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. 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. 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.
  204. 204. 204/272 Geographic Information Systems  data: – OpenStreetMap (Open Source)
  205. 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. 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
  207. 207. 207/272 11. big data
  208. 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. 209/272 where is big data?  Q: why big data is not addressed in the central side section?
  210. 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
  211. 211. 211/272 an example cellular network 400 MB / vehicle / month
  212. 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. 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
  214. 214. 214/272 more generally  there is no one fts all architecture
  215. 215. 215/272 12. security
  216. 216. 216/272 information security  we talk about information security only  three objectives, according to the CIA triad: – confdentiality – integrity – availability
  217. 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. 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. 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. 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. 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. 222/272 summary  security is a world by itself  it applies to all subcomponents  a broad view is required  rely on real experience [Sec01]
  223. 223. 223/272 13. standardization
  224. 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. 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
  226. 226. 226/272 standardization  AE: Application Entity - CSE: Common Services Entity - NSE: Network Services Entity [Sta01]]
  227. 227. 227/272 ITU-T - technical overview [Sta02]]
  228. 228. 228/272 ITU-T - types of devices and relationship with physical things
  229. 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. 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. 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
  232. 232. 232/272 14. ecosystem
  233. 233. 233/272 ecosystem  what we saw: – many diferent use cases – several diferent technologies  => ecosystem and value chain are complex
  234. 234. 234/272 ecosystem  usually, value chain is depicted like this: Devices Connectivity Integration Applications Customers
  235. 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. 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
  237. 237. 237/272 15. project perspective
  238. 238. 238/272 gathering user requirements requirements analysis prototyping product development tests installation - user approval usual projet phases (simplifed)
  239. 239. 239/272 gathering user requirements requirements analysis prototyping product development tests installation - user approval technology hands-on proof of concepts tooling important phases
  240. 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]
  241. 241. 241/272 agility real needs technology iterations delivery • handling of: • requirements uncertainty • technology uncertainty
  242. 242. 242/272 agility  beware: electronics project lifecycle is not software project lifecycle  => prototypes  => feld user test  => OTA update  => expandable hardware  => more powerful hardware [Pro08]
  243. 243. 243/272 16. case studies
  244. 244. 244/272 example - user needs - 1/4 A
  245. 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
  246. 246. 246/272 example - user needs - 2/4 A
  247. 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
  248. 248. 248/272 example - user needs - 3/4 A
  249. 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
  250. 250. 250/272 example - user needs - 4/4 A
  251. 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
  252. 252. 252/272 example - technology - 1/4 A
  253. 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
  254. 254. 254/272 example - technology - 2/4 A
  255. 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
  256. 256. 256/272 example - technology - 3/4 A
  257. 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
  258. 258. 258/272 example - technology - 4/4 A
  259. 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
  260. 260. 260/272 example - legal aspects - A
  261. 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
  262. 262. 262/272 17. want to play?
  263. 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. 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. 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
  266. 266. 266/272 18. conclusion
  267. 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. 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 :-)
  269. 269. 269/272 thanks! systev.com @PascalBod06 fr.linkedin.com/in/pascalbodin/ pascal.bodin@systev.com
  270. 270. 270/272 credits and references [Def01] https://material.io/icons/ [Def02] https://openclipart.org/detail/237859/factory [Def03] https://en.wikipedia.org/wiki/Internet_of_things [Fct01] http://www.libelium.com/resources/top_50_iot_sensor_applications_ranking/ [Fct02] https://www.aylanetworks.com/iot-use-cases/connected-home [Pr101] http://homelive.orange.fr/accueil/ [Pr102] http://www.samsung.com/fr/consumer/mobile-devices/smartphones [Pr103] https://openclipart.org/detail/155101/server [Pr201] https://www.u-blox.com/en/product/neo-m8-series [Pr202] http://www.ti.com/product/CC3200MOD/description [Pr203] https://www.sierrawireless.com/products-and-solutions/embedded-solutions/automotive-modules/ [Pr204] https://developer.mbed.org/platforms/FRDM-K64F/ [Pr205] https://openclipart.org/detail/210237/misc-depression-button [Pr206] https://www.u-blox.com/en/product/c027 [Pr207] https://www.iridium.com/products/details/iridiumedge [Arc01] http://www.rm-odp.net/ [Arc01] https://openclipart.org/detail/232991/sedan [Arc02] https://openclipart.org/detail/177832/radiator [Arc03] https://openclipart.org/detail/24535/street-lamp [Arc04] https://openclipart.org/detail/202078/printer-inkjet
  271. 271. 271/272 credits and references [Dev01] https://www.adafruit.com/products/2590 [Dev02] https://www.adafruit.com/products/2542 [Dev03] https://www.adafruit.com/products/2461 [Dev04] https://www.adafruit.com/products/1991 [Dev05 https://shop.sodaq.com/en/explorer.html [Per01] https://wiki.openwrt.org/doc/hardware/port.gpio [Per02] http://maxembedded.com/2011/06/the-adc-of-the-avr/ [Per03] [Per04] https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus [Per05] https://learn.sparkfun.com/tutorials/serial-peripheral-interface-spi [Per06] http://www.engineersgarage.com/contribution/i2cinter-integrated-circuittwitwo-wire-interface [Per07] http://maxembedded.com/2014/02/inter-integrated-circuits-i2c-basics/ [Per08] [Com01] http://www.microchip.com/wwwproducts/en/RN2483 [Com02] https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1515 [Com03] http://www.wikiwand.com/it/Gateway_GPRS_Support_Node [Com04] http://www.robotshop.com/eu/fr/plateforme-developpement-beaglebone-black-beagleboard.html [Com05] [Com06] http://planstrategique.anfr.fr/?p=1247 [Com07] https://www.lora-alliance.org/technology http://eu.mouser.com/Connectors/D-Sub-Connectors/D-Sub-Standard-Connectors/_/N-9gybx? No=50&P=1ytmhdqZ1yzv7x2Z1z0z812 https://autoelectricalsystems.wordpress.com/2015/11/10/basics-of-controller-area-network-can-bus- part-1/ https://www.sierrawireless.com/iot-blog/iot- blog/2016/08/lpwa_for_the_iot_part_2_standard_vs_proprietary_technologies/
  272. 272. 272/272 credits and references [Pla01] http://www.aeris.com/technology/aercloud/ [Pla02] [Cen01] https://openclipart.org/detail/17312/antenna-square [Sec01] https://iotsecurityfoundation.org/ [Sta01] http://onem2m.org/images/files/deliverables/Release2/TS-0001-%20Functional_Architecture-V2_10_0.pdf [Sta02] http://www.itu.int/rec/T-REC-Y.2060-201206-I [Pro01] https://openclipart.org/detail/259142/garbage-truck [Pro02] https://openclipart.org/detail/204589/old-british-taxi [Pro03] https://openclipart.org/detail/144367/chiva [Pro04] https://openclipart.org/detail/139267/eco-car [Pro05] https://dir.indiamart.com/impcat/gprs-modem.html [Pro06] https://openclipart.org/detail/116599/solar-panel [Pro07] https://openclipart.org/detail/181618/crashed-car https://www.sierrawireless.com/products-and-solutions/sims-connectivity-and-cloud-services/iot-cloud- platform/

×