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.

Internet of Things Anatomy


Published on

IoT platform as a regular server software. Types of platforms and its' communicaion with devices. Data normalization, storage, processing and visualization. IoT Platform Enterprise Integration. AggreGate Platform.

Published in: Technology
  • Be the first to comment

Internet of Things Anatomy

  1. 1. Internet of Things Anatomy
  2. 2. Marketing experts introduced the Internet of Things • There was no revolution, just evolution • ‘Things’ have been communicating for quite a while (e.g. PLCs on a wire drawing line or network switches) • Monitoring and management systems have been existing for long, but again marketing experts sent them to the ‘cloud’ • Cellular and satellite modems weren’t invented yesterday • In fact IoT is just a general name joining various markets, both B2B and B2C • Terminology evolution: Intelligent Device Management => M2M => IoT - 2 -
  3. 3. Internet of Things comprises Devices (“things”) Data centers M2M concept assumes that devices interact with one another. They can do it: 1) Directly via network 2) Via network and central software in a data center (in the ‘cloud’) 3) Sometimes both Networks - 3 -
  4. 4. Device Network Structure IP TCP, UDP SNMP, Telnet, BACnet, Modbus, SOAP, HTTP, MQTT… RS-232, RS-485, Ethernet, Wi-Fi, USB, CAN, Bluetooth Z-Wave, GPRS/3G/LTE… PPP, ATM, SLIP… NetBIOS, PPTP, RPC… SSL, TLS... - 4 - OSI Network Model
  5. 5. Device Types The difference is in management software tasks. Example: GPS trackers for a dog and a bus are similar in terms of hardware, but they have absolutely different could services and dashboards. Consumer Industrial - 5 -
  6. 6. Device Logical Structure Variables (settings, properties): ability to read and write Such device structure is described in full or partially by any known communication protocol. Functions (methods, operations): ability to call and transmit input data while receiving output data Events (notifications): ability to subscribe and retrieve instances asynchronously Metadata (descriptions of available variables, functions and events) - 6 -
  7. 7. Internet of Things Platform • IoT platform is just a regular server software • It plays a role of runtime environment (application server) for IoT applications designed for the end user - 7 - • Only a few applications are written from scratch (will cover the reasons later) • IoT platforms are often deployed in rented commercial data centers, or in data centers belonging to large IoT device operators
  8. 8. Primary Objectives of IoT Platforms • Data collection from various devices and data sources • Storage of externally collected as well as internally generated data • Stand-alone data processing and automatic decision taking - 8 - • Data visualization (developing an operator interface) • Enterprise data integration (only for Industrial IoT) • Intelligent data exchange between devices
  9. 9. Types of IoT Platforms • Infrastructure platforms provide data storage and collection as well as API/SDK for implementing processing, visualization and integration methods (IoT application development) via programming • Full cycle platforms solve all tasks using visual constructors, with the only necessity for programming when writing communication modules and complex mathematics/logic - 9 -
  10. 10. Communication with Devices • Any IT (SNMP, Telnet, WMI...), automation (Modbus, BACnet, OPC…), IoT (MQTT, XMPP, AMQP…) and universal (HTTP/REST, SOAP, FTP…) protocols are used • Very few basic operations: reading and writing settings, executing operations, receiving events (including notifications on change in values) - 10 -
  11. 11. Data Normalization - 11 - Normalization is conversion to a unified standard form. It’s usually performed in two steps: • Abstraction from protocol (conversion to universal data types) • Abstraction from device type/make/version (application of device models)
  12. 12. Data Storage - 12 - What we store: • Server-side configuration and tools • Last device configuration snapshots (in case of unavailability) • Setting change history (for devices and server-side tools) • Event history (the same as above) Where we store: • Relational database (slow and inefficient) • NoSQL database (оптимально) • Specialized databases (e.g. RRD for time series aggregation – has its own pros and cons) RDBMS RRD (Statistics) NoSQL (Big Data)
  13. 13. Data Processing - 13 - • Completely standalone • Delayed group configuration and operation execution • Operator notifications upon important events and states (emails, SMS) • Dynamic models with own life cycle • Machine-readable knowledge base for taking decisions • Multiple tools (root cause analysis, scheduler, domain- specific languages – examples: AggreGate and IEC languages)
  14. 14. Data Visualization - 14 - • 1st and 2nd line operator interface is built from scratch for each IoT application • Interface base is a set of dashboards with navigation and drilldown • Dashboards include tables, forms, maps, facility plans, charts, diagrams and many other components • Everything is customizable till the very last pixel • Dynamic thanks to binding UI components to properties and events of a server data model
  15. 15. IoT Platform Enterprise Integration - 15 - • Uses the same protocols as for data collection • The protocols work the other way round • IoT doesn’t have typical integration scenarios • Configuration should be flexible but without programming
  16. 16. Why not to write everything yourself? - 16 - • A prototype will be ready quickly • You will spend years implementing a scalable system supporting failover clustering, distributed collection and storage architecture, etc. • A bicycle will be invented in about 5 years • There’ll be fixed expenses to support the real product state • It looks even more unnatural for system integrators, engineering companies and MSPs
  17. 17. Tibbo Systems and AggreGate Platform - 17 - • Tibbo Systems: Russian software developer working worldwide • AggreGate Platform: software “brick set” for building IoT device monitoring and management systems • 14-years’ investments into “brick” development • Hundreds of large installations in various countries • 10+ vertical market solutions, including IT infrastructure management and SCADA systems
  18. 18. Cases and References - 18 - • Monitoring and managing telecom tower power supply (Flexenclosure, Sweden) • Monitoring mission-critical uninterruptible power supply units (Unified Energy Corporation, Russia) • Narrow-band radio station monitoring system (DCI Tech, Canada) • Comprehensive monitoring of a multi-server telecom operator network (An-net, Russia) • Monitoring of engineer constructions (Insight, Russia) • Centralized fountain management (Sharel, Israel) • Roadheading equipment monitoring (Ilma, Russia)
  19. 19. Cases and References - 19 - • Building automation of the Electoral Commission of Namibia • Data acquisition from industrial alcohol breath testing devices (Intoximeters, the US) • Forklift fleet management and monitoring (Keytroller, the US) • Monitoring McAuto queue length and POS equipment (McDonald’s, the US) • Centralized monitoring, control and provisioning of Android-based vending machines (Minibar Systems, the US) • Cloud-based Time and Attendance system (RCPOnline, Poland) • Monitoring of a distributed IP-based emergency notification speakers network (Emergencies Ministry of Russia)