Transcript Watch Presentation Internet of Things Anatomy

Internet
of Things
Anatomy
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-
Internet of Things comprises
Networks
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
-3-
Device Network Structure
OSI Network Model
SNMP, Telnet, BACnet, Modbus, SOAP, HTTP, MQTT…
SSL, TLS...
NetBIOS, PPTP, RPC…
TCP, UDP
IP
PPP, ATM, SLIP…
RS-232, RS-485, Ethernet, Wi-Fi, USB, CAN, Bluetooth
Z-Wave, GPRS/3G/LTE…
-4-
Device Types
Consumer
Industrial
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.
-5-
Device Logical Structure
Variables (settings, properties):
ability to read and write
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)
Such device structure is described in full or partially by
any known communication protocol.
-6-
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
•
Only a few applications are written
from scratch
•
IoT platforms are often deployed in
rented commercial data centers, or
in data centers belonging to large IoT
device operators
-7-
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
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-
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 -
Data Normalization
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)
- 11 -
Data Storage
What we store:
• Server-side configuration and tools
• Last device configuration snapshots
(in case of unavailability)
RDBMS
• Setting change history
(for devices and server-side tools)
• Event history (the same as above)
RRD (Statistics)
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)
- 12 -
NoSQL (Big Data)
Data Processing
•
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, domainspecific languages – examples: AggreGate and IEC
languages)
- 13 -
Data Visualization
•
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
- 14 -
IoT Platform Enterprise
Integration
•
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
- 15 -
Why not to write everything
yourself?
• 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
- 16 -
Tibbo Systems and AggreGate
Platform
• 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
- 17 -
Cases and References
• 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)
- 18 -
Cases and References
• 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)
- 19 -