How to Build the Connectivity Architecture for the Industrial Internet of Things (IoT)

How to Build the Connectivity Architecture for the
Industrial Internet of Things (IoT)
Rajive Joshi, Ph. D.
Principal Solution Architect
Real-Time Innovations Inc.
February 25, 2015

Outline
• Industrial IoT is different!
– Why? How? What?
• Open Interoperable Connectivity Architecture
– Role, Model, Rules, Patterns, Realization
• Building the Connected Architecture
– Generic Use Case
– Architecture Mapping
– Implementation

Industrial Internet of
Things (IoT) is different!
Why? How? What?

4
Quiz! What’s common?

Why are they different?
• Operate in the real-world
– Non-stop
• Failure has severe consequences
– Loss of life or property, often both
• Data timeliness is critical
– Right answer delivered too late becomes the
wrong answer!

How are they different?
Technical Factors
• Scalability
– Volume, Variety
• Performance
– Velocity, Timeliness
• Resilience
– Availability, Recovery,
Durability
• Security
– Authentication, Authorization,
Integrity, Confidentiality, Non-
Repudiation
Business Factors
• Reliability
– Chance of failure during
anticipated lifetime
• Safety
– No unintended consequences
• Longevity
– Incremental upgrades on an
ongoing basis
• Diversity
– Independent developers
– Multiple technologies

There are many vectors along which we can measure end-point “robustness.” Table 1
summarizes these vectors:
Table 1: Near-term end-point differences between IIoT and HIoT
Attribute Industrial IoT (IIoT) Human IoT (HIoT)
Market Opportunity Brownfield Greenfield
Product Lifecycle Until dead or obsolete Whims of style and/or budget
Solution Integration Heterogeneous APIs Vertically integrated
Security Access Identity & privacy
Human Interaction Autonomous Reactive
Availability 0.9999 to 0.99999 (4–5 ‘9 ’s) 0.99 to 0.999 (2–3 ‘9’s)
Access to Internet Intermittent to independent Persistent to interrupted
Response to Failure Resilient, fail-in-place Retry, replace
Network Topology Federations of peer-to-peer Constellations of peripherals
Physical
Connectivity
Legacy & purpose-built Evolving broadband &
wireless
Example Gateways Commercial monitoring
Echelon SmartServer
Consumer home automation
Revolv Hub
Market Opportunity: “Brownfield” is a term borrowed from commercial real estate; it is
used to denote a potential site for building development that had been previously
developed for industrial or commercial use. IIoT uses brownfield to describe the
Collectively referred to as a
Gateway
Source:
http://www.moorinsightsstrategy.com/wp-content/uploads/2013/10/Connecting-with-the-Industrial-Internet-of-Things-IIoT-by-Moor-Insights-Strategy.pdf
Architecture Style Data Driven,
Publish-Subscribe
Human Driven,
Request-Response
Moore Insights report 2014
What’s different?

Common Pitfalls
Applying connectivity technologies meant for
human users
to
non-humans users*
*Time and again, people re-discover this!

Key Takeaways
• Industrial Internet of Things (IoT) is different!
– Why?
• Requirements
– How?
• Qualities: Technical and Business
– What ?
• Architecture and Techniques
 Connectivity architecture must address the
unique requirements of Industrial Internet Systems

Open Interoperable
Connectivity Architecture
Role, Model, Rules, Patterns, Realization

Connectivity Architecture Role
Interoperability: Reduce Time to Integrate
Party A Party B
No standard exists, completely
custom integration
Interfaces can be
transformed/mapped
Interfaces use a
common model
“Plug and Play” standard defined
Credit: Scott Neumann, UISol position paper

Data Centric Connectivity Architecture
Rule: Decouple apps from the Data
Data centricity enables interoperation, scale, integration
Messaging middleware
Databus
Unstructured files
Database
Data Centricity
Data Centricity

Connectivity Data Flow Patterns
Fundamental Building Blocks
Industrial IoT
• Stream
• Command
• Status
• Configuration
Conventional Enterprise IT
• Event
• Query
• Transaction
• Job
Architecture Style
Publish-Subscribe Request-Response
Activity Trigger
Data (State Change) Human (Decision)

DDS: The Connectivity Foundation for IIoT
Data-Centric Messaging Bus
• Data Distribution Service (DDS) is
an open industry standard for data-
centric connectivity
• From OMG, the world’s largest
systems software standards
organization
– UML, DDS
– Industrial Internet Consortium (IIC)
• DDS is Open & Multi-Vendor
– Open Standard & Open Source
– 12 implementations
Interoperability
between source written
for different vendors
Interoperability between
applications running on different
implementations
DDS-RTPS Protocol
Real-Time Publish-Subscribe
Distribution
Fabric
DDS API

• ~800 Designs
– Healthcare
– Transportation
– Communications
– Energy
– Industrial
– Defense
• 15+ Standards &
Consortia Efforts
DDS Industrial Internet Applications
Current Users

Connectivity Architecture using DDS
Connect Everything, Everywhere
• Proximity
• Platform
• Language
• Physical network
• Transport
protocol
• Network
topology
DDS “DataBus”
Seamless data sharing regardless of:
Explicit Shared
Data Model
with
Controlled QoS

Connectivity Architecture using DDS
Interoperability Between Subsystems
DDS Routing Service
• Organize
– Hierarchy
• Bridge
– Data models
– Protocols
– Security domains
• Isolate
– Control export
– Filter access
– Translate models
Other
protocols
Routing Service
Pluggable Adapters
Transformation Engine
System
Super System
Subsystem
Subsystem
Subsystem
Subsystem

Key Takeaways
• Connectivity Architecture Role
– Interoperability to reduce integration time & effort
• Connectivity Architecture Model, Rules, Patterns
– Decouple apps from data
– Pick a core open connectivity standard
– Use gateways to organize and bridge
• Connectivity Architecture Realization
– Leverage the DDS open standard, popular in Industrial
Internet Systems, for integration of disparate
connectivity protocols
– Leading DDS implementations provide all the
connectivity fundamental building blocks
– Seamless data sharing from sensor to cloud

Building the
Connected Architecture
Generic Use Case
Architecture Mapping
Implementation

Connected Home
Gadgets  Service Provider  Occupants
Cloud
Intelligent Device
Intelligent Device
Intelligent Device
WAN
WAN
Many Devices
Internal LAN
Many Users
LAN
At Home
• Fixed Network
• Stable Addressing (relatively)
• Ad-hoc components
• Gateway

Cloud
Intelligent Device
Intelligent Device
Intelligent Device
WAN
WAN
Many Devices
Internal LAN
Many Users
LAN
Field technician on-site
• Fixed Network
• Stable Addressing (relatively)
• Managed Components
• Gateway
Connected Energy
Turbines  Operations  Operators

Connected Healthcare
Patient Monitors  Hospital  Doctors
Cloud
Intelligent Device
Intelligent Device
Intelligent Device
WAN
WAN
Many Devices
Internal LAN
Many Users
LAN
Doctor at the Hospital
• Mobile Network
• Dynamic Addressing
• Certified Components
• Gateway

Connected Cars
Car  Service Provider  Drivers
Cloud
Intelligent Device
Intelligent Device
Intelligent Device
WAN
WAN
Many Devices
Internal LAN
Many Users
LAN
In the Vehicle
• Mobile Network
• Qualified Components
• Gateway

Generic Connectivity Use Case
Devices  Cloud  Users
Cloud
Intelligent Device
Intelligent Device
Intelligent Device
WAN
WAN
Many Devices
Internal LAN
Many Users
LAN
Occasionally
• Mobile Network
• Ad-hoc Components
• Gateway

Connectivity Architecture Mapping
Choosing the right technology
Cloud
Intelligent Device
Intelligent Device
Intelligent Device
WAN
WAN
Many Devices
Internal LAN
Many Users
LAN
Occasionally
?
?
?
?

Cloud
Intelligent Device
Intelligent Device
Intelligent Device
WAN
WAN
Many Devices
Internal LAN
Many Users
LAN
Occasionally
DDS
- Stateful interactions and many data flow
patterns (now, future)
- Publish-Subscribe architecture style, data
driven
- Scalability, Performance, Resilience,
Security Requirements
- Disconnected & Intermittent Links
- Mobile Networks (Cellular and WiFi)

Cloud
Intelligent Device
Intelligent Device
Intelligent Device
WAN
WAN
Many Devices
Internal LAN
Many Users
LAN
Occasionally
Web (Web-Sockets, HTTP)
- Stateless interactions, single data flow
pattern (query)
- Request-Response architecture style,
human driven
- Established Scalability, Security
infrastructure
- Forgiving Performance, Resilience
requirements
- Ubiquitous access from any (mobile)
device or thin client

Cloud
Intelligent Device
Intelligent Device
Intelligent Device
WAN
WAN
Many Devices
Internal LAN
Many Users
LAN
Occasionally
DDS
driven
Security Requirements
- Reliability, Safety, Longevity requirements
- Diversity of transports and platforms

Cloud
Intelligent Device
Intelligent Device
Intelligent Device
WAN
WAN
Many Devices
Internal LAN
Many Users
LAN
Occasionally
DDS
driven
- Request-Reponse architecture style,
human driven
Security
- Longevity of Services
- Diversity of connectivity solutions

Cloud
Intelligent Device
Intelligent Device
Intelligent Device
WAN
Many Devices
Internal LAN
Many Users
LAN
Occasionally
• Mobile Network
• Gateway
DDS Databus
WAN
DDS Databus

Deployment View
Cloud
Intelligent Device
Intelligent Device
Intelligent Device
WAN
Many Devices
Internal LAN
Many Users
LAN
Occasionally
• Mobile Network
• Gateway
DDS Databus, Domain 1
WAN
Domain 0

Deployment View
Cloud
Intelligent Device
Intelligent Device
Intelligent Device
WAN
Many Devices
Internal LAN
Many Users
LAN
Occasionally
• Mobile Network
• Gateway
WAN
UDP, Shmem
Domain 0
TCP
UDP,
Shmem

Connectivity Implementation Example
Deployment View: Nodes
demo.rti.com
osx
(Mac OS Laptop)
WAN
Many Users
LAN
Occasionally
WAN
UDP, Shmem
Domain 0
TCP
UDP,
Shmem
vm1
(Linux Virtual Machine)
android
(Nexus 7 Tablet with LTE)
WAN
Domain 0
TCP
iPhone
(iOS)

Deployment View: Components
demo.rti.com
osx
(Mac OS Laptop)
WAN
Many Users
LAN
Occasionally
WAN
UDP, Shmem
Domain 0
TCP
UDP,
Shmem
vm1
(Linux Virtual Machine)
android
(Nexus 7 Tablet with LTE)
WAN
Domain 0
TCP
iPhone
(iOS)
rtiddsprototyper
rtiddsprototyper
rtiddsprototyper
Shapes
Demo
nodejs DDS Connector

Articulate Concept
1. Draw a diagram of the components and the interconnecting
data-flows
Define Structure
2. Define the data types for the interconnecting data flows (in
IDL or XML)
3. Define the system structure as a collection of data-oriented
interfaces (in XML)
Configure Behavior
4. Select from built-in Quality of Service (QoS) profiles to match
the data flow pattern; extend to match special cases.
5. Code component behaviors
35
Component Development Webinar
Build it Fast:
5 Steps from Concept to Working
Distributed System

Human Access
Cloud  Users
iOS Safari
http://demo.rti.com:7401/simple

Network Mobility
Devices  Cloud
• Switching between Cellular and Wi-Fi
– Seamless data sharing
– State managed by DDS
iOS Safari
Wi-Fi

Network Mobility
Devices  Cloud
• Switching between Cellular and Wi-Fi
– Seamless data sharing
– State managed by DDS
iOS Safari
Cellular (LTE) – Different IP Address Seamless Data Sharing

Elastic Cloud Applications
Cloud Apps  Cloud Apps
• Adding/removing/upgrading components
– Data is decoupled from components

Elastic Cloud Applications
Cloud Apps  Cloud Apps
• Adding/removing/upgrading components
– New components independently created to work
on the data

Connectivity Technology Triage
When to use what technology?
• Is there a human at one end?
– No!  Use DDS
• Device  Device
• Device  Cloud
– Yes!  Use DDS or Web-Sockets
• User Device  Cloud
– Web-browser  Use HTML5+Web-sockets
– App  Use DDS or HTML5+Web-sockets
• Ok to use DDS between
– Humans
– Non-humans
– Non-humans and Humans

• Is it over a WAN?
– Yes!  Use TCP (with TLS)
• Device  Cloud
– No! (LAN)  Use UDP (with multicast, if available)
• Cloud App  Cloud App (within the Cloud LAN)
• Switching between Cellular and WiFi networks
– Use DDS to manage state, independently of the
network mobility and switching
– Use DDS Quality of Service (QoS) to control the
how the state is distributed and managed
Connectivity Technology Triage
With DDS, which transport to use?

Key Takeways
• Generic Connectivity Use Case
– Devices  Cloud  Users
• Devices  Cloud (over WAN)
– Use DDS over TCP
• Devices  Devices
– Use DDS over UDP (LAN) or TCP (WAN)
• Cloud Apps  Cloud Apps (within LAN)
– Use DDS over UDP
• Cloud  Users (WAN)
– Use DDS over TCP, or
– Use Web-Sockets + HTML (over TCP)

Review
• Industrial IoT is different!
– Why? How? What?
• Open Interoperable Connectivity Architecture
– Role, Model, Rules, Patterns, Realization
• Building the Connected Architecture
– Generic Use Case
– Architecture Mapping
– Implementation

Edge to Cloud: Databus Hierarchy
Unit DataBus
Unit DataBus
Intelligent
Machines
Intelligent
Systems
Intelligent
Industrial
Internet
Cloud
Enterprise LAN
Intelligent
System of
Systems
Unit LAN Segment
Sense Act
Think HMI
Intra-machine
Think HMI
Intra-machine
Sense Act
Think HMI
Intra-machine
46

47
Quiz! Answer: They all use RTI’s Connext DDS

Thank You
Rajive Joshi, Ph. D
Principal Solution Architect
Real-time Innovations Inc.
rajive@rti.com

Start using DDS Today!
Download the FREE complete RTI Connext
DDS Pro package for Windows and Linux:
• Leading implementation of DDS
• C, C++, C#/.NET and Java APIs
• Tools to monitor, debug, test, visualize and
prototype distributed applications and systems
• Adapters to integrate with existing applications and
IT systems

How to Build the Connectivity Architecture for the Industrial Internet of Things (IoT)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (14)

Similaire à How to Build the Connectivity Architecture for the Industrial Internet of Things (IoT)

Similaire à How to Build the Connectivity Architecture for the Industrial Internet of Things (IoT) (20)

Plus de Real-Time Innovations (RTI)

Plus de Real-Time Innovations (RTI) (20)

Dernier

Dernier (20)

How to Build the Connectivity Architecture for the Industrial Internet of Things (IoT)