IoT Architecture Principles v6

Principles of IoT
Architecture
Gaurav
Nayyar
Copyright © 2017 Tech Mahindra. All rights reserved. 1

Digital Transformation through IoT

Industry is transforming…
Towards Towards
Platforms Mobility
Towards Towards Towards

Servicification Access Co-creation

Enabling Digital Transformation
Digital Enterprises are the enterprises that have managed to leverage digital technologies (NMACSSS) individually as well as in
combination to alter its ecosystem of existing products and services, business models and business processes to deliver altogether
new and superior value
DIGITAL CUSTOMERS DIGITAL PRODUCTS & SERVICES

(Enabled by CMO/CDO) (Enabled by CEO & CTO)
DIGITAL
TRANSFORMATION
DIGITAL PROCESSES & OPERATIONS DIGITAL PRODUCTIVITY

(Enabled by COO/CIO) (Enabled by CPO/CXO/CHRO/CIO)
Bringing Value to Users
Customer Maximize Safety and Maximize Asset

Experience Revenue Environment Value

IoT Principles
Cloud & H/W Business Process -->

IT + IoT = Real Time Agnostic System Enterprise Systems --
IT Integrator > IoT
Covering the Return on Value

Entire Value Chain

Sample Use Cases

Industrial Use Cases

Internet of Things Eco System
The IoT Eco System is complex convergence of different technologies and skills. The Eco system requires not only the right
skills but right partners to be able to create the end service.

WAN
GGSN IPSEC
SMSC NNI
HLR
SGSN Internet
Core NW Application Cloud
Radius &
Dia Internet
SGSN
Mediation
B/OSS
Internet
Portal
Connectivity
Sensors and IoT hub @ Edge Radio NW Interconnect User Access
Platform
NW

IoT Devices

What are IoT Devices?
Internet / Network
(Connectivity)
Thing / Embedded Device

Gartner –
"The Internet of Things is the network of physical objects that contain embedded technology to
communicate and sense or interact with their internal states or the external environment."

What are IoT Devices?
Key Elements of a Typical IoT Device

Microprocessors & Microcontrollers
CC32xx Wireless MCU, SoC

Sensors
Sensors
 A sensor is a component, device or a module that detects or measures changes in its
environment and converts it to a form that can be interpreted by a processor.
Type of Sensors
 Analog – Sensors that produce continuous  Digital – Sensors that produce digital output in the
analog output signal proportional to their form of binary data, serial data, parallel data or
measurement. The output signal can be in the PWM, etc.
form of voltage, current or resistance, etc.
 Examples – LDR, Thermistor, Microphone,  Examples – OPT3001 Ambient Light Sensor, LM75A
Piezoelectric Sensor, Analog Accelerometer, etc. Temperature Sensor, BMP180 Barometric Pressure Sensor,
etc.

Sensors
Categories of Sensors
 Passive - A passive sensor is one that does not  Active - An active sensor is one that requires an
require a source of power to generate an output. external source of power (excitation voltage) to
operate.
 It detects and gathers target data from phenomena
occurring in the subject’s environment.  It emits a signal to be bounced off a target, with data
gathered by the sensor upon their reflection.
 Mostly need to be conditioned and or amplified with an
active device like an op-amp.
 Examples – Radar, LiDAR, Sonar, Ultrasonic
 Examples – Strain Gauge, Piezoelectric sensor, PIR Transducer, IR Proximity sensor, etc.
sensor, Thermocouples, etc.

Sensors
Properties of a Good Sensor
 It is sensitive to the measured property only.
 It is insensitive to any other property likely to be

encountered in its application.
 It does not influence the measured property.

Firmware
Firmware
Firmware is a low-level software that can run from ROM or RAM and provides set capabilities to an
embedded device. Bootloader, Device Driver, RTOS & Application may all form a part of firmware.
Bootloader
Bootloader is a small application that loads an
operating system or application into memory
and relinquishes control of the hardware target
to that software.
Device Driver
The Hardware Abstraction Layer software that
communicates with specific hardware
peripherals is called a device driver. A device
driver provides a standard API to read and write
to a specific peripheral.

Firmware
Operating System
An Operating System is a system software that manages system resources and provides common
services for applications running within the OS environment.
Types of Operating Systems

 Platform Operating Systems
 Real-time Operating Systems
Application
Application is code dedicated to handling a
particular task.

M2M Terminals/Gateways
 M2M terminal can be broken down into two logical components. The first is the application portion of the terminal that provides the
specific hardware and software for the M2M application. For example, in a point of sales terminal, the application portion would be the
keypad, LCD, and printer with the associated application layer software. This can also be referred to as a Sensor that captures real time
data from the external environment like pressure, energy, temperature etc.
 The second logical component of the M2M terminal is the M2M module, which is mainly responsible for providing the connectivity
services. The application portion is also sometimes simply referred to as the “host” to the M2M module. The application portion of the
terminal is highly related to the M2M application
 Cellular chipset technology is at core of all wireless M2M devise. They share the same technology platform as other cellular
devices such as handsets and USB modems.

Gateways
 Enables communication from the Edge to the Cloud
 Aggregates Sensor data
 Multiple built-in connectivity options; i.e. Cellular, WiFi, Zigbee, BLE etc.
 Simple Rule Engine
 Often includes SDK for custom coding and deploying agents
 A key component of Edge IoT Architecture

Edge Architecture
 Edge Device with Embedded Agent and Cellular Long-Haul

Edge Architecture
 Edge Device to Gateway with Cellular Long-Haul

General-purpose
input/output (GPIO) is a generic
pin on an integrated circuit or
computer board whose
behavior—including whether it is
an input or output pin—is
controllable by the user at run
time.
GPIO pins have no predefined
purpose, and go unused by
default.[1][2] The idea is that
sometimes a system
integrator who is building a full
system might need a handful of
additional digital control lines—
and having these available from
a chip avoids having to arrange
additional circuitry to provide
them.

IoT Device Selection Criteria
 Minimum Viable Features

– Connectivity & Other Technical Requirements
– Reliability
– Quality of Connection & Real-Time Performance
– Power Requirements
 Compatibility
– Greenfield or Brownfield Implementation
– Integration Feasibility and Effort
– Platform Agents

 Cost
– Hardware
– Software
– Integration
 Data and Security

– Privacy
– Security
– Amount of Data

 Brand Identity
– New or Partner Vendor
– Presence in IoT Space
– Past Track Record
 Certifications
– FCC, CE etc.
– Application-Area Specific (If Any)
 Additional Features
– FOTA & COTA

Example of Device Selection Guideline
 MoSCoW Method
– Must Have
– Should Have
– Could Have
– Won’t Have (this time)
 Device Specification Comparison Sheet

Device Selection Guideline

Connectivity for IoT

Connectivity For IoT Devices
 Frequency bands and worldwide regulations
– ITU coordinates the shared global use of radio spectrum
– Regulated by FCC in the United States
– Regulated by CEPT in Europe
– Regulated by WPC in India

 ISM Bands
– Unlicensed
– Reserved Frequency Bands by ITU-R
– For Industrial, Scientific & Medical (ISM) applications
– Vary slightly from country to country

 IoT Communication Protocols
 Link Layer
– Bits to radio signals & vice versa
– Data Framing for reliable communication
– Manages access to the radio channel
 Network Layer
– Addresses & routes data through the network
 Transport Layer
– Generates communication sessions
– Facilitates multiple communication channels
 Application Layer
– Responsible for data formatting
– Controlling Data Integrity
– Governs the data flow in an optimal scheme
IoT Protocols

 Wireless Network Range
25 Kilometers
100 Meters
10 Meters

Connectivity For IoT
 Typical Topologies

 Wireless Network Range
Technology Frequency Data Rate Range Topology Power Usage Applications
WiFi 2.4 GHz 54 Mb/s 100 m Star High WLAN, Mobiles Router/Gateway
BLE 2.4 GHz 1 Mb/s 10 m - 50 m Star Low Beacons, Sensors, Health Devices
ZigBee 2.4 GHz 250 kb/s 10 m - 100 m Mesh, Tree, Star Low Home Automation, Sensor Network
Z-Wave 900 MHz 100 kb/s 30 m - 100 m Mesh, Tree, Star Low Home Automation
NFC 13.56 MHz 424 kb/s 20 cm Peer to Peer Low Secure Payment, Transport Ticket

Serial Communication
serial communication is the process of sending data one bit at a time, sequentially, over
a communication channel or computer bus. This is in contrast to parallel communication, where several
bits are sent as a whole, on a link with several parallel channels.
Serial communication is used for all long-haul communication and most computer networks, where the
cost of cable and synchronization difficulties make parallel communication impractical.
Serial Interfaces
I2C, CAN, LIN, SPI, Flex, MOST, and I2S. Then there’s Ethernet and USB and other higher-speed serial
interfaces like FireWire, HDMI, and Thunderbolt. Two of the oldest interfaces are RS-232 and RS-485.
RS 485

Service/Connectivity Management Platform

What is SMP?
Service Management

What SMP does ?

The SIM state model
INACTIVE TERMINATED
ACTIVE-TEST ACTIVE-READY ACTIVE-LIVE ACTIVE-SUSPEND INACTIVE-STOPPED
Operator transition ACTIVE-SLEEP
Customer transition - manual

Customer transition – manual or automated
Optional - Needs to be customer enabled
In inactive stage SIM is not recognized in the network and no communication possible
In active stage SIM is recognized in the network

End to end visibility of SIM estate

Various types of SMP deployments
SIM- Global
Platform- Centralized
RAN- Operator
SIM- Operator
Platform- Centralized
RAN- Operator
Various types of SMP deployments…..contd.
SIM- Operator
Platform- Oprator
RAN- Operator
In the local deployment model, the

platform is deployed once and then
handed over to operator for end to
end management after some initial
handover –takeover and training
Operator is responsible for customer

onboarding and end to end operations
later on.

M2M Service Lifecycle
Service
Definition
and OpCo
Configuration
Customer On-
Service boarding and
Termination Service set-up
Usage
SIM Ordering
processing,
&
Pricing and
Provisioning
Reporting
Operational
Service Service
Manageme Delivery
nt

M2M Platform Architecture
Source- Logica
Business Benefits of SMP to Telcos
 Leveraging the existing network assets for IOT

 Leveraging existing operation support for IOT
 Differentiated SIM offering
 Differentiated SMS services
 Differentiated billing based upon services, APIs, Bundled Data etc.
 Scope for standard IOT solutions through IOT market place
 Scope for end to end customized solutioning
 Scope for Device Management, Data Collection and Analytics

WAN
GGSN IPSEC
SMSC NNI
HLR
SGSN Internet
Radius &
Dia Internet
SGSN
Mediation
B/OSS
Internet
Portal
Connectivity
Platform
NW

Network Integrations (Case Study)
After 1 Gig – Fiber termination – Opt Connect (Optical Fiber) else

Ethernet Cat 6 cable
BGP protocol (for redundancy)------ check BoM for the switches
we have
FW on AEP side
AEP 6 GGSN
Mumbai
Active - DC PaCo MPLS
VRF
MPLS
MPLS Cloud
VRF
AEP
IT MPLS 4 SMSC
Chennai
Passive - DR
GDSP S-NoC – SDP / VLT

VRF PVN / Guj
NDC 2 – Data Center
Verify all switches All internet apps in DMZ Exchange
Need destination point to connect to
MPLS
Application Enablement Platform

Need for IOT Platform
Application Enablement
Scalable & secure platform to process data from 500,000 machines in 5 years.
Strong device identification and access management required
Complex Events, alerts and business processes for different types of machine
Device Management
Need for device SDK and libraries to connect to machines
Need for efficient device registration and diagnostics capabilities
Need for scripts and firmware upgrade on the devices
Integration & APIs

Need to integrate with Jasper APIs of AT&T and Rogers in North America
Need to integrate with CETS for efficient Incident Management
Need to integrate with Big Data to store device data
IOT Platform
IoT Enabling Capability Supporting Capability
UI, BRM, BPM, Device Data, Big Carrier and

Application Efficient integration with carrier
Data, Complex Event Processing, Communication
Development connectivity platform
Alerts Management Integration
Application Complete support of software / Device SDK for drivers & driver libraries,
Management firmware update Management gateways
Ability handle large number of Operating

Scalability Security, multi-tenancy, and cloud
devices Environment
UI (User Interface), BRM (Business Rule Management), BPM (Business Process Management), EAI (Enterprise Application Integration)

Conceptual Approach for IOT (Industry Best Practice)
Key Considerations
On IOT Platform Stakeholders
Equipment  Millions of devices
Security & Edge Users

 Multi Protocol Support
Mgmt System
Query
 Wireless Communication
Device Device APPS
Attestation Attestation
Web  Complex Event Processing
Applications
Storage
 Alert Management
 Bulk of device data

Services Mobile
Data Transport Data Ingestion Persistence & Compute
Orchestration
Broker & Processing Concurrency Apps  Global Spread
 Analytics
Analytics Alerts
 Process integration
Shared Services
• Monitoring • Auditing External  Business benefits
Systems

Reference Module Decomposition for IOT Platform
IOT Identity & Access Mgmt.
Data Center Management
Identity Directory/DB
Device Access Management

I D
N Machine Data Store Business Intelligence
N A
E IOT Comm. Gateway T Device Identity Management T
T Big Data
R A Dashboard &
W
A B Reports
O Protocol Handlers Data Aggregator
N A
R
E S
K
T E Big Data Store
Service Security IOT Platform Analytics
F
F F
I Device Management
I I No SQL DB
R Service R R
E Management Message Queuing
E E
W Key Value Store
W W
A
A Application Enablement A
L
L L
L
L Management Console L
RDBMS
Message Routing Enterprise Applications
Data Store
Carrier Network Integration

Reference Functional Decomposition for IOT Platform
On Equipment IOT Platform Enterprise Systems
DWH
Application Enablement
CETS
Rule Engine Device Security Master Data
Alerts Engine Reports

Device Management Agent Notification Engine ------------
Business Intelligence
Business Intelligence
Communication Device Management Dashboards / Reporting
Communication Agent Device Registry SW Distribution Analytics
Remote Diagnostics ----------------- Bigdata

Remote Access Agent
Machine Features Carrier Network Integration Stakeholders Systems

SIM Management. Account Management
CMS Agent Telemetry FSV Applications
Billing Provisioning
Customer Applications
Consumer Engaging Apps
Fountain Applications
Content Management
Kiosk Framework
Digital Signage 3rd Party Applications

Application Management Platform
The M2M Platform connects M2M devices with backend enterprise
system(s). While enabling the communication (at the application
layer), common functionality related to the application data
management is provided by the middleware in form of reusable
middleware components. To enable the M2M application providers
and Enterprises to develop and manage applications that help
them drive greater efficiency and new business alike requires an
Application management layer with following functional and
non‐functional features:
 SDKs and APIs for rapid application development and

adaptation to changing needs ensure quicker time to market
 Common services such as configurable rule engine, alert and
notification management, device profile and state
management
 Configurable and customizable data model
 Customizable connectors for enterprise system integration
 Highly scalable software and hardware infrastructure which
ensures that the platform can service the MNO’s projected
volumes and much more than that through capacity addition.
 Multi‐tenancy model
IoT Application with and without AMP

Schedule with a platform
Schedule Influencing Factors
1. TW will reduce only development time by 40-50%, not all the phases
2. Custom Enterprise integrations required
3. Data Model has to be created like any other
4. Devices are not compliant on TW
5. Protocols adapters need to be build
6. Screens : TW with its basic masshup widgets has limitations to impliment VF branding. Will need to develop custom mashups
7. Business Logic and algorithms like geo fencing, nearest route, fastest route, driver behavour would be custom logic
8. Wrapper for all services

9. Custom logic needs to build for business rules
10. Debugging – Very Difficult
11. Change is very expensive – all links have to be recreated for a change
12. Mobile App
13. Generic Components, Basic Services and Framework required in all use cases to be developed first
https://support.ptc.com/apps/help_center/brand=Thingworx

IoT Platform – ONE M2M Reference Architecture

Device Management
The Device Management (DMG) CSF provides management of device capabilities on MNs (e.g. M2M
Gateways), ASNs and ADNs (e.g. M2M Devices), as well as devices that reside within an M2M Area
Network. Application Entities (AE) can manage the device capabilities on those Nodes by using the
services provided. While the AE does not require an understanding of the technology specific protocols
or data models, this information is provided to the AE so that an AE can utilize this information for
administrative purposes (e.g. diagnostics, troubleshooting).

The IoT Reference Architecture
Device Management
Platform
Enterprise/3rd party
Sensor Network Gateway Network IoT Platform Analytics
Things systems
SIM Management Platform
Smart Home
ZigBee Edge Analytics 2G/3G/4G/Broad Device Mgmt. Big Data Storage ERP
REST/JMS/htt band
ps/http
Wi-Fi
Wi-Fi Public network Analytics platform e.g. SAP
Data Collection SAP
HANA, Actian
Bluetooth
MQTT/AM
QP Private Network Data Modelling Actian Analytics Platform CRM
Modbus
Connected Car
Edge Mgmt.
Business Rules Predictive Analytics
Global/Local SIM
CANbus COAP Weather
OTA updates
Systems
Notification&
Protocol System Integration
Global SIM& Managed Services
Alerts
Traffic
6LoWPAN Abstraction
Connected Factory Real time System
https/http analytics
Whitelisting
802.15.4 Dashboards
OMADM Vertical Solution Development
/LWM2M/TR069 Tcp/udp
User /Enterprise Facing Services / Apps
Ethernet Security
Smart City
Cell Modem/ Smarty City Apps CRM Apps

GPS
Smart Factory App Smart Home Apps
Cloud Computing
Edge Computing
Players – Microsoft Azure, Google, AWS, IBM etc.
Players – Cisco, Dell, Intel, Qualcomm etc.
Copyright © 2017 Tech Mahindra. All rights reserved. Platforms – Bosch, Telit, PTC, GE 65
Application Layer Protocols

IoT Application Layer Protocols

HTTP
Not much to explain as it is a very common protocol

HTTP has high computation complexity, low
Connectionless data rate and high energy consumption.
Media independent
Stateless
Client/server
pull protocol

COAP
Constrained Application Protocol (CoAP)

lightweight protocol CoAP is intended to be used and considered as a
replacement of HTTP for being an IoT application layer protocol.
Specialized for constrained nodes and constrained (e.g., low-power,
lossy) networks.
These applications range from smart energy, smart grid, building
control, intelligent lighting control, industrial control systems, asset
tracking, to environment monitoring
Compare to HTTP low overhead, multicast.
Multicast, low overhead, and simplicity are extremely important
for Internet of Things (IoT) and Machine-to-Machine (M2M) devices,
which tend to be deeply embedded and have much less memory and
power supply than traditional internet devices have.
Therefore, efficiency is very important. CoAP can run on most devices
that support UDP or a UDP analogue.

COAP
• On one side, CoAP provides URI, REST method such as GET,

POST, PUT, and DELETE. On the other side, based on
lightweight UDP protocol, CoAP allows IP multicast, which
satisfies group communication for IoT.
• To compensate for the unreliability of UDP protocol, CoAP
defines a retransmission mechanism and provides resource
discovery mechanism with resource description
• Headers are considerably smaller, and the protocol supports
splitting larger payloads through multiple requests known as a
Blockwise transfer.
• The most defining feature of CoAP Protocol is the fact that it
leverages the tried and tested REST model.

COAP
CoAP is incredibly lightweight. It has been developed to RFC 7252

standards. This means it can be run on devices with very limited
resources. As low as 10k of memory and 100k of application
space is all that a device needs to run CoAP.
Inbuilt into the network stack of CoAP is full 30172 bit RSA
encryption.
Smartphone development is a good example of this. Regardless

of platform, iOS or Google Android, CoAP delivers a
standardized protocol for application developers.

AMQP vs JMS
JMS has queues and topics. A message sent on a JMS queue is consumed by no more than one client.
A message sent on a JMS topic may be consumed by multiple consumers. AMQP only has queues.
While AMQP queues are only consumed by a single receiver, AMQP producers don't publish directly to
queues. A message is published to an exchange, which through its bindings may get sent to one queue
or multiple queues, effectively emulating JMS queues and topics.
A limitation of JMS is that the APIs are specified, but the message format is not. Unlike AMQP, JMS has
no requirement for how messages are formed and transmitted. Essentially, every JMS broker can
implement the messages in a different format. They just have to use the same API

Protocol selection
COAP MQTT
Constrained hardware Hardware support TCP Protocol
8 bit microcontrollers Publish/Subscribe
low power sensors Continuous Open Connection and session
Connectivity and bandwidth Require larger packet transmission (from COAP)
very low bandwidth
connectionless/stateless
Resource Discovery by client
AMQP
Systems are too complex, too expensive, too slow to adapt with changing needs.
Cant loose data.
Technology agnostic
No constraint on hardware

Infrastructure /Availability / Scalability

High Availability
High availability is a characteristic of a system, which aims to ensure an agreed level of operational performance, usually uptime, for a
higher than normal period. Availability is usually expressed as a percentage of uptime in a given year.
There are three principles of systems design in reliability engineering which can help achieve high availability.
 Elimination of single points of failure. This means adding redundancy to the system so that failure of a component does not
mean failure of the entire system.
 Reliable crossover. In redundant systems, the crossover point itself tends to become a single point of failure. Reliable systems
must provide for reliable crossover.
 Detection of failures as they occur. If the two principles above are observed, then a user may never see a failure. But the
maintenance activity must.
Availability % Downtime per year Downtime per month Downtime per week Downtime per day
90% ("one nine") 36.5 days 72 hours 16.8 hours 2.4 hours
95% ("one and a half nines") 18.25 days 36 hours 8.4 hours 1.2 hours
97% 10.96 days 21.6 hours 5.04 hours 43.2 minutes
98% 7.30 days 14.4 hours 3.36 hours 28.8 minutes
99% ("two nines") 3.65 days 7.20 hours 1.68 hours 14.4 minutes
99.5% ("two and a half nines") 1.83 days 3.60 hours 50.4 minutes 7.2 minutes
99.8% 17.52 hours 86.23 minutes 20.16 minutes 2.88 minutes
99.9% ("three nines") 8.76 hours 43.8 minutes 10.1 minutes 1.44 minutes
99.95% ("three and a half nines") 4.38 hours 21.56 minutes 5.04 minutes 43.2 seconds
99.99% ("four nines") 52.56 minutes 4.38 minutes 1.01 minutes 8.66 seconds
99.995% ("four and a half nines") 26.28 minutes 2.16 minutes 30.24 seconds 4.32 seconds
99.999% ("five nines") 5.26 minutes 25.9 seconds 6.05 seconds 864.3 milliseconds
99.9999% ("six nines") 31.5 seconds 2.59 seconds 604.8 milliseconds 86.4 milliseconds
99.99999% ("seven nines") 3.15 seconds 262.97 milliseconds 60.48 milliseconds 8.64 milliseconds
99.999999% ("eight nines") 315.569 milliseconds 26.297 milliseconds 6.048 milliseconds 0.864 milliseconds
99.9999999% ("nine nines") 31.5569 milliseconds 2.6297 milliseconds 0.6048 milliseconds 0.0864 milliseconds
High Availability Cluster
Active/active — Traffic intended for the failed node is either
passed onto an existing node or load balanced across the
remaining nodes. This is usually only possible when the
nodes use a homogeneous software configuration.
Active/passive — Provides a fully redundant instance of
each node, which is only brought online when its
associated primary node fails.[2] This configuration typically
requires the most extra hardware.
N+1 — Provides a single extra node that is brought online
to take over the role of the node that has failed. In the case
of heterogeneous software configuration on each primary
node, the extra node must be universally capable of
assuming any of the roles of the primary nodes it is
responsible for. This normally refers to clusters that have
multiple services running simultaneously; in the single
service case, this degenerates to active/passive.
N+M — In cases where a single cluster is managing many
services, having only one dedicated failover node might not
offer sufficient redundancy. In such cases, more than one
(M) standby servers are included and available. The
number of standby servers is a tradeoff between cost and
reliability requirements.
ThingWorx Core Server Failure
1. ZooKeeper gets no response from the leader; therefore, it sends a request to the standby
TW HA Architecture node to become the leader.
2. The new leader sends confirmation to the load balancer (HAProxy in this guide) to have
requests routed to it.
Load Balancer Failure

Users
Assets If the active load balancing solution fails, sessions to the active ThingWorx Core server are no
Coordin Load Balancer interrupted. Depending on your load balancing solution, backup capacity is used for sessions
ator
during failover.
Conne Conne
ction ction
Zooke
server server
eper 3 HAProxy Server Failure
Zooke
eper 1 If your only HAProxy node fails or all of your HAProxy nodes fail, the following occurs:
Zooke HA Proxy
eper 2
(Load Balancer) The ThingWorx Core leader will still be accessible through its IP address but not through the
HAProxy IP address.
Requests to ThingWorx Core through HAProxy will not reach ThingWorx Core.
TW TW If one of two HAProxy nodes fail, the following occurs:

X1 X2 The session will be recognized in ThingWorx Composer once the backup HAProxy become
the new master. You are not prompted to log on once the new master HAProxy is up.
ZooKeeper Node Failure

Minimum setup for HA: Pgp Pgp
3 zookeeper nodes ool ool
2 TWx runtime servers (Master and Standby) If one of three ZooKeeper nodes fails, the following occurs:
2 HAProxy (loadbalancers)
3 Database instances nodes A new ZooKeeper leader is elected.
2 Pgpool processes (one on each of the Post Post ThingWorx Core remains active and accessible (for example, you can see entities
TWX runtime servers) gres gres
Post in Composer).
gres
When two ZooKeeper nodes fail, the following occurs:

Copyright © 2017 Tech Mahindra. All rights reserved. Leader election for ZooKeeper cannot take place. 80
Pgpool-II Node Failure
If the active pgpool-II node fails, the backup will detect it and take over the handling of all requests to the PostgreSQL servers. Users logged onto the
active ThingWorx Core server may experience delays in their applications, and there could be loss of user or device data that is being saved when the
pgpool-II node failure occurred.
PostgreSQL Node Failure

If a PostgreSQL server fails, the active pgpool-II node detects the failure and stops routing requests
to that server. User or device data being saved at the time of the failure could be lost if the
information had not been committed and replicated to other nodes before the failure.
When 2 nodes fail, Operations Stop

Horizontal Scaling
DEVICES Server Requirements
1 - Connection Server
0-50k
1 – Platform Server
50-100k
100-500k
500k-1m
1-2m
>2m
Vodafone Case
Per Device Year 1 Year 2 Year 3
Category
Frequency No. of Sensor OPS PWS OPS PWS OPS PWS Notes
Parameters/Packet
(min)
Assuming that data
Wearable 1 5 59.2 296 133.2 666 229.4 1147 transfer is not full day.
e.g. gateways
Tags Reader 10 3 1.48 4.44 3.33 9.99 5.735 17.205
e.g. pumps, generators

Asset Tracker 5 10 34.04 340.4 76.59 765.9 131.907 1319.067
e.g. OBD, CAN devices.

Vehicle Tracker 2 20 159.1 3182 357.975 7159.5 616.517 12330.3 Assuming that data
transfer is not full day.
Copyright © 2017 Tech Mahindra. All rights reserved. Total 253.82 3822.84 571.095 8601.39 983.56 14813.605 82
Cloud Based Elasticity
elasticity generally means the opposite – scaling down capacity or resources as they are no longer
needed.
Resources provisioning time[edit]
One potential problem is that elasticity takes time. A cloud virtual machine (VM) can be acquired at any
time by the user, however, it may take up to several minutes for the acquired VM to be ready to use.
The VM startup time is dependent on factors, such as image size, VM type, data center location,
number of VMs, etc
Monitoring elastic applications[edit]

Elastic applications can allocate and deallocate resources (such as VMs) on demand for specific
application components. This makes cloud resources volatile, and traditional monitoring tools which
associate monitoring data with a particular resource (i.e. VM), such as Ganglia or Nagios, are no longer
suitable for monitoring the behavior of elastic applications
Elasticity requirements[edit]
When deploying applications in cloud infrastructures (IaaS/PaaS), requirements of the stakeholder need
to be considered in order to ensure proper elasticity behavior. Even though traditionally one would try to
find the optimal trade-off between cost and quality or performance, for real world cloud users requirements
regarding the behavior are more complex and target multiple dimensions of elasticity
Amazon Elastic Compute Cloud
Amazon EC2 presents a true virtual computing environment, allowing you to use web service interfaces to launch
instances with a variety of operating systems, load them with your custom application environment, manage your
network’s access permissions, and run your image using as many or few systems as you desire.
To use Amazon EC2, you simply:

• Select a pre-configured, templated Amazon Machine Image (AMI) to get up and running immediately. Or create
an AMI containing your applications, libraries, data, and associated configuration settings.
• Configure security and network access on your Amazon EC2 instance.
• Choose which instance type(s) you want, then start, terminate, and monitor as many instances of your AMI as
needed, using the web service APIs or the variety of management tools provided.
• Determine whether you want to run in multiple locations, utilize static IP endpoints, or attach persistent block
storage to your instances.
• Pay only for the resources that you actually consume, like instance-hours or data transfer.
Amazon Elastic Block Store
Amazon Elastic Block Store (EBS) offers persistent storage for Amazon EC2 instances.
Amazon EBS volumes are network-attached, and persist independently from the life of an
instance.

Elastic Load Balancing
Elastic Load Balancing automatically distributes incoming application traffic across multiple Amazon
EC2 instances. It enables you to achieve even greater fault tolerance in your applications, seamlessly
providing the amount of load balancing capacity needed in response to incoming application traffic.
Elastic Load Balancing detects unhealthy instances within a pool and automatically reroutes traffic to
healthy instances until the unhealthy instances have been restored.

Cloud Services (Example AWS) – Custom Solutions
Service Name Description Usage
for deployment of DwAgent (Custom Bobcat
EC2 Cloud environment application)
monitoring service for AWS cloud For monitoring the EC2 DwAgent deployment on
CloudWatch resources DEV/QA/Prod
send individual messages or to fan-out
AWS SNS messages to large numbers of recipients Used to send notifications to SQS.
fully-managed message queuing service
for reliably communicating among
distributed software components and
AWS SQS microservices
AWS SES cost-effective email service to send emails notifications
run code for virtually any type of To manage different functionalities like Dw token
AWS Lambda application or backend service generation, Event managements
fast, fully managed, petabyte-scale data To store things data through a daily export jobs, quality
AWS Redshift warehouse parameters etc
capture, transform, and load streaming
data into Amazon Kinesis Analytics, To capture data through DynamoDB table changes,
AWS Firehose Amazon S3, Amazon Redshift, data exported through this to redshift
AWS
DynamoDB NoSQL DB
Application Based Scalability – Vertical Scaling

Security

Security at each layer (Confidentiality, Integrity, Authenticity,
Non-Repudiation, Availability)
GGSN IPSEC
SMSC NNI
HLR
SGSN Internet
Radius &
Dia Internet
SGSN
Mediation
B/OSS
Internet
Portal
Connectivity
Platform
NW

IoT Infrastructure Threat Surface
IoT Threat Security in IOT
IoT Infrastructure
Surface Infrastructure
Access
Unauthorized access, Application Security,

insecure transport, Enterprise Customer Third Party Host/mobile based
application threats, protection, API
MITM Application protection
Trusted Identities – PKI & IAM

API Web Mobile
Unified Threat Monitoring

Data breach, insecure Data protection,
Data
cloud Interface, Perimeter protection,

infrastructure threats, Private/public malware protection,
malware Cloud application security,
traffic visibility,
Queue
Queue
Transport
Service Gateway Physical protection,

Configuration issues, traffic visibility, secure
SW tampering, gateway, malware
malware, protection, anti-
unauthorized access, tampering, host based
Rogue devices, MITM Wi-Fi, Ethernet, LTE protection, transport
Field gateway
Device
protection, signed code,

Field
insecure transport.
IP Non IP
Integration of IT & IoT networks IoT devices must have adequate security controls, single
vulnerable device can leave the complete IT network open to attacker

IoT Analytics

Analytics

Objectives of Analytics

Machine Learning

Maturity Model

IoT Analytics

Step 1: Anomaly Detection

Step 2: Generate Prediction Models

Step 3: Prediction

Case Study

Tech M and IoT

Tech M Capability across IoT Value Chain
Sensors
& Gateways Component % Market Strategy Offerings / P ’ship.
Network  Retrofit Global Partnerships Offerings : Design, Testing
Sensors 15-20  OE Leverage Engineering Partnerships: Bosch, Cisco,
Platform  Design Expertise Intel, Cal Amp
System
Integration  Global SIMs Best Prices Offerings : Design, Testing
Applications/ Network 10 -15  Country Specific Service Assurance Partnerships : ATT Vz, VF,
Analytics Partnerships Telco Integration Expertise Telefonica, Etisalat, Aircel
Platform Agnostic SI –
Security  Niche Players Domain wise classification Offerings : Platform
 Global Custom Products based on Engineering, SI
Platform 10-15
Tech Mahindra
Behemoths research & demand e.g. Risk Partnerships : PTC, Bosch.
 Custom Products Engineering Platform; Smart MS, Telit, Covisint, GE
Tech Mahindra with Services City Application
Partners
Leverage latest analytics
Offerings: Custom
 Container technologies and Bigdata
Applications 15-20 Applications, Packaged
 300 + platforms; 5 will sustain in this  Contents technology
Products, Resellers
game Domain specific analytics
 Tech M play in > 50% of value chain Geo specific partnerships for
 Our Differentiators Multi Year deals
 Field Services field services Eg: Spencer
 Domain Expertise Services 25-30 IoT Operations Center
 IT Operations Tech, Feeny Wireless, ATT,
 Engineering Knowhow IoT Operations Suite
GTrac
 Telecom Pedigree
 Ability to execute E2E operations System Offer E2E services under
10 – 15 10+ IoT offerings
Integration single roof
Tech Mahindra’s IoT Offerings
Business Case & Global Roll-out strategy for Smart Restrooms
for a leading US based Personal Care company
Consulting
Platform
E2E
E2E Managed Services with a Tier-1 Telco in Services - NW Integration & Roll out of SMP
Managed
NA for one of its enterprise customers Rollout & for a Global Telecom Giant
Service
Integration
Device Platform
Working with a leading European ODC for SMP & AMP Products
Telco for E2E Device Testing
Design & IoT Offerings Dev. &
of a leading US Telco
Testing Maint.
Solutions
Solutions
IoT Applications Testing on the in-house Centre for ODC for a Tier-1 Telco in
Testing on
SMP of a Global Telecom Giant Telcos and NA, Europe & India
Platforms
Enterprises
Packaged
Verticalized
Solutions
Vertical Solutions for India’s leading
Enterprise services company
Copyright © 2016
2017 Tech Mahindra. All rights reserved. 107
Partner Ecosystem
STRATEGIC PARTNERS
Networks
Field Middleware/
Services Platforms TELCO FOCUSSED PARTNERS
OUR PARTNER
ECOSYSTEM
VERTICAL SOLUTION PARTNERS
Devices &
Analytics
Sensors
Cloud

IoT: Where Do We Rank
Ranked in the Leadership zone in 2016 Digital & IOT Zones
Ranked in the Winner’s Circle of 2016 IOT Services Blueprint
Positioned as Leaders in IoT Application Services segment on

Nelson Hall IOT NEAT 2016
India Customer Value Leadership Award in Digital Enterprise

Transformation & IoT and Best Practices Award for System
Integrator in the IIoT industry in 2015
Positioned as Major Contender in IOT PEAK Matrix 2016
Recognized for IOT initiatives and has been mentioned in

“Market guide for IOT Service Providers 2016
Positioned as Major Player in IDC MarketScape Worldwide IoT

Consulting and SI Services Vendor Assessment 2016
Honoured as Best Digital Enterprise of the Year by Drivers of

Digital Awards 2016

109
Our Credentials
SOLAR POWER IOT PLATFORM ODC FOR IOT

STEAM IOT PLATFORM
PLANT ROLLOUT IOT PLATFORM
TURBINE DEVELOPMENT
MONITORING JGTM DEVELOPMENT
M2M STRATEGIC RISK

SI FOR IOT JGTM PRESALES
SI FOR IOT JGTM PARTNER FOR MANAGEMENT
CONSULTANCY IOT JGTM SYSTEM
LEADING ASIAN & AIRCRAFT

CELL TOWER EUROPEAN HEALTH AFTER MARKET
SMART LIGHTING INTEGRATION
MONITORING OPERATORS LONE WORKER MONITORING AS
A SERVICE
SMART
WASHROOM SMART CITY SMART CITY CONNECTED
SMART TOOL
CONSULTANCY IMPLEMENTATION IMPLEMENTATION MACHINES
DISPENSER AIRLINE CREW

REMOTE ASSET SECURITY & MONITORING & READY MIX
REMOTE
MONITORING SURVEILLANCE PEOPLE SAFETY CONCRETE
MONITORING
AMBULANCE REMOTE HEALTH COMPANY FLEET COMPANY FLEET

TRACKING & MONITORING TELE-MEDICINE
MANAGEMENT MANAGEMENT
EMERGENCY
MGMT
FARM TO FORK – CONNECTED CAR

SURGICAL KIT & VEHICLE VEHICLE
COLD CHAIN DIGI-SENSE
TRACKING) DIAGNOSTICS DIAGNOSTICS
MONITORING

Case Study 1

Bobcat - Solution
CRM
Trailering
Engine Speed Geo-
Warranty Management
fence
System
Engine Oil
Enterprise Database
Air
Filter
Dealer Management
System
Hydra Batter Notification/Queueing

ulic y Services
Filter
Fleet
Management
Application
DwAgent
Hybris – e Commerce & Omni Channel
Product
Bobcat - Solution
CRM
Trailering
Engine Speed Geo-
Warranty Management
fence
System
Engine Oil
Enterprise Database
Air
Filter
Dealer Management
System
Hydra Batter Notification/Queueing

ulic y Services
Filter
UDP
Triggers
event notification
Amazon SQS
MQTT
Fleet
Management
Finite State Machine
Application Validation rules
DwAgent
Hybris – e Commerce & Omni Channel Complex business rules
Product
Case Study 2

Smart Street Light - High Level Solution Architecture
Smart Streetlight Application
Frontend
On/Off Dimming Google Map
Map View Monitoring Admin Application
Control Schedule Integration
North Bound Presentation Layer APIs

Device
IMPACT DB Intelligent Message
Managemen Agent Server
gateway Bus
t Backend
Platform
Data collection and Device Communication Layer

Nokia Impact Platform IMPACT Data Collector
South Bound Presentation Layer APIs
Mobile Network
Gateway
Onsite
Hardware
Controller
Smart Lights
Previous Approach
Nokia IMPACT Platform
Alerts Service Mobile Apps
Cloud Gateway
Management
Management
Identity &
Sensors & Notifications Service
Access
Device
Gateway
Data Storage
Integration
Dashboards & Applications
New Approach
Nokia IMPACT Platform

Rule Engine EMAIL
MQTT Broker
Cloud Gateway
Integration
Management
Adaptation
Sensors & Alerts Service TEXT

Layer
Gateway Device
Scheduler
Device Data Storage
Application
Provided by Nokia Developed by TechM

Alternate solution for the Missing Components
Missing Components Alternate Implementation

Device Communication Protocol support 1. TechM integrated external MQTT Broker with IG gateway and IMPACT
MQTT To HTTP Conversion (if MQTT 1.TechM developed Adaptation Layer for MQTT to HTTP converter and
Broker is external to IMPACT) integrate external HTTP client to IG gateway
Device Meta data Storage 1. TechM integrated external RDBMS to store master and meta data
information of device
Time Series Data Storage 1. TechM integrate external No-SQL Data store-Cassandra
Job Scheduler 1. TechM developed and integrate external scheduler
Alert & Notifications 1. Custom development of alerts and notification services

2. TechM integration with SMS and Email gateway
Rule Engine 1. Custom build BRE for rule configuration

Technical Architecture
Cassandra MySQL
Smart Light Application
NorthBound
Nokia Impact Platform

http SouthBound
HTTP Client Server
Adaptation Layer Message Transformation
MQTT Client/Listener
MQTT
Message Broker
(RabbitMQ)
Publish MQTT Subscribe Commands/Events

Commands/Events
Controller (Python Client)
RFID data transfer
Lam
Lamp Lamp Lamp
p
Architecture & Design Principles
 Separation of Concerns
 Single Responsibility
 Shared Pool Resources
 NoSQL Design Standards
 Principle of Least Knowledge
 Don’t Repeat yourself(DRY)

Smart Street Light Technology Stack
Technology Version
Java/JEE 1.8
Spring 4.2.5
Hibernate 4.0
Quartz scheduler 2.2.3
RabbitMQ 3.6.1
Cassandra 3.9
MySQL 5.5
AngularJS 1.4.8
Python 3.6
Linux/Ubuntu 16.04

IoT: Reality or Hype
Reality Challenges Growth Drivers
 In the merger and acquisition  An IoT solution is convergence of  Aggregation Platforms where by
market, the sales of IoT technologies and requires a complex many point solutions can be
companies have been well below eco system for delivery and combined and serviced as a single
billion dollar range maintenance. A strong and reliable package.
partner eco system is required to run
 Most of the deals with Enterprise an IoT solution.  Platform as a Service models will
or Government to date have enable universal access to the
been small with exception of a  IoT solutions are like mobile apps. The solutions from cloud.
few like delivering smart meters solutions can be endless and at the
in UK. same time any one solution will not  The cost of sensors have declined
meet needs of different customers, 50% in the past decade, according
 Large enterprises are developing geographies, verticals. Installations are to Goldman Sachs. We expect
their own IoT solutions to drive also very typical and require very high prices to continue dropping at a
efficiencies knowledge of the industry. steady rate.
 Major revenue source for Telcos  The cost of chipsets, modules and  Expanded Internet connectivity.
in IoT revenues is still the devices are prohibitive at the moment. ITU estimates that 57% of the
connectivity where the ARPU is global population is connected to
not more that 5-10 USD  IoT standards are not yet mature. the internet by 2019
Copyright © 2017 Tech Mahindra. All rights reserved.
Interoperability is missing. 121
Thank You

Radio Spectrum (By ITU)
Frequency
Band name Abbreviation Example uses
Wavelength in air
3–30 Hz
Extremely low frequency ELF Communication with submarines
100,000 km – 10,000 km
30–300 Hz
Super low frequency SLF Communication with submarines
10,000 km – 1000 km
300–3000 Hz
Ultra low frequency ULF Submarine communication, communication within mines
1000 km – 100 km
3–30 kHz
Very low frequency VLF Navigation, time signals, submarine communication, wireless heart rate monitors, geophysics
100 km – 10 km
30–300 kHz
Low frequency LF Navigation, clock time signals, AM longwave broadcasting (Europe and parts of Asia), RFID, amateur radio
10 km – 1 km
300–3000 kHz
Medium frequency MF AM (medium-wave) broadcasts, amateur radio, avalanche beacons
1 km – 100 m
Shortwave broadcasts, citizens' band radio, amateur radio and over-the-horizon aviation communications, RFID, over-the-
3–30 MHz
High frequency HF horizon radar, automatic link establishment (ALE) / near-vertical incidence skywave (NVIS) radio communications, marine
100 m – 10 m
and mobile radio telephony
30–300 MHz FM, television broadcasts and line-of-sight ground-to-aircraft and aircraft-to-aircraft communications, land mobile and
Very high frequency VHF
10 m – 1 m maritime mobile communications, amateur radio, weather radio
300–3000 MHz Television broadcasts, microwave oven, microwave devices/communications, radio astronomy, mobile phones, wireless
Ultra high frequency UHF
1 m – 100 mm LAN, Bluetooth, ZigBee, GPS and two-way radios such as land mobile, FRS and GMRS radios, amateur radio, satellite radio
3–30 GHz Radio astronomy, microwave devices/communications, wireless LAN, most modern radars, communications satellites, cable
Super high frequency SHF
100 mm – 10 mm and satellite television broadcasting, DBS, amateur radio, satellite radio
30–300 GHz Radio astronomy, high-frequency microwave radio relay, microwave remote sensing, amateur radio, directed-energy
Extremely high frequency EHF
10 mm – 1 mm weapon, millimeter wave scanner
Terahertz or Tremendously 300–3000 GHz Experimental medical imaging to replace X-rays, ultrafast molecular dynamics, condensed-matter physics, terahertz time-
THz or THF
high frequency 1 mm – 100 μm domain spectroscopy, terahertz computing/communications, remote sensing, amateur radio
https://en.wikipedia.org/wiki/Radio_spectrum
ZIGBEE and Z-WAVE
As a wireless mesh networking technology, ZigBee can be used in direct communications, but most applications are based on a star or
tree topology mesh network. A master coordinator node controls other connected nodes. If a node cannot communicate with another node,
the two may communicate by way of links to other nodes within range acting as repeaters. ZigBee can support up to 65k nodes.
ZigBee devices operate in the unlicensed industrial, scientific, and medical (ISM) bands. The most popular configuration is in the 2.4-GHz
band, where the standard defines sixteen 5-MHz channels of operation.
The Z-Wave wireless mesh networking technology enables any node to talk to other adjacent nodes directly or indirectly through available
relays. A master controller node controls any additional nodes. The nodes communicate directly with one another if they’re within range. If two
nodes that want to communicate aren’t within range, they can link with another node that both can access and exchange information. A Z-Wave
network can have up to 232 nodes. Multiple controllers can be set up to partition a network as required for different functions.

IoT Architecture Principles v6

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

IoT Architecture Principles v6

Hochgeladen von

Copyright:

Verfügbare Formate

Principles of IoT

Copyright © 2017 Tech Mahindra. All rights reserved. 1

Copyright © 2017 Tech Mahindra. All rights reserved. 2

Towards Towards Towards

Copyright © 2017 Tech Mahindra. All rights reserved. 3

DIGITAL CUSTOMERS DIGITAL PRODUCTS & SERVICES

DIGITAL PROCESSES & OPERATIONS DIGITAL PRODUCTIVITY

Bringing Value to Users

Customer Maximize Safety and Maximize Asset

Copyright © 2017 Tech Mahindra. All rights reserved. 4

Cloud & H/W Business Process -->

Covering the Return on Value

Copyright © 2017 Tech Mahindra. All rights reserved. 5

Copyright © 2017 Tech Mahindra. All rights reserved. 6

Copyright © 2017 Tech Mahindra. All rights reserved. 7

Copyright © 2017 Tech Mahindra. All rights reserved. 8

Core NW Application Cloud

Copyright © 2017 Tech Mahindra. All rights reserved. 9

Copyright © 2017 Tech Mahindra. All rights reserved. 10

Thing / Embedded Device

Copyright © 2017 Tech Mahindra. All rights reserved. 11

Key Elements of a Typical IoT Device

Copyright © 2017 Tech Mahindra. All rights reserved. 12

CC32xx Wireless MCU, SoC

Copyright © 2017 Tech Mahindra. All rights reserved. 13

Copyright © 2017 Tech Mahindra. All rights reserved. 14

Copyright © 2017 Tech Mahindra. All rights reserved. 15

 It is sensitive to the measured property only.

 It is insensitive to any other property likely to be

 It does not influence the measured property.

Copyright © 2017 Tech Mahindra. All rights reserved. 16

Copyright © 2017 Tech Mahindra. All rights reserved. 17

Types of Operating Systems

 Real-time Operating Systems

Copyright © 2017 Tech Mahindra. All rights reserved. 18

Copyright © 2017 Tech Mahindra. All rights reserved. 19

Copyright © 2017 Tech Mahindra. All rights reserved. 20

Copyright © 2017 Tech Mahindra. All rights reserved. 21

Copyright © 2017 Tech Mahindra. All rights reserved. 22

Copyright © 2017 Tech Mahindra. All rights reserved. 26

 Minimum Viable Features

Copyright © 2017 Tech Mahindra. All rights reserved. 27

 Data and Security

Copyright © 2017 Tech Mahindra. All rights reserved. 28

Copyright © 2017 Tech Mahindra. All rights reserved. 29

 Device Specification Comparison Sheet

Copyright © 2017 Tech Mahindra. All rights reserved. 30

Copyright © 2017 Tech Mahindra. All rights reserved. 31

Copyright © 2017 Tech Mahindra. All rights reserved. 32

– Regulated by FCC in the United States

– Regulated by CEPT in Europe

– Regulated by WPC in India

Copyright © 2017 Tech Mahindra. All rights reserved. 33

Copyright © 2017 Tech Mahindra. All rights reserved. 34

Copyright © 2017 Tech Mahindra. All rights reserved. 36

Copyright © 2017 Tech Mahindra. All rights reserved. 37

Copyright © 2017 Tech Mahindra. All rights reserved. 38

Technology Frequency Data Rate Range Topology Power Usage Applications

Copyright © 2017 Tech Mahindra. All rights reserved. 39

Copyright © 2017 Tech Mahindra. All rights reserved. 41

Copyright © 2017 Tech Mahindra. All rights reserved. 42

Copyright © 2017 Tech Mahindra. All rights reserved. 43

Copyright © 2017 Tech Mahindra. All rights reserved. 44

ACTIVE-TEST ACTIVE-READY ACTIVE-LIVE ACTIVE-SUSPEND INACTIVE-STOPPED