IoT application Models and business

use-cases
Prof. Pradeep Abeygunawardhana
• 1. Read-only Remote Asset Monitoring
• Not surprisingly, the simplest IoT use case is also the most
adopted. Read-only remote asset monitoring refers to assets
that are connected from afar in a read-only manner (i.e., one
can visualize the asset data, but one cannot send back any
commands to the asset itself). This use case is one of the
easiest and cheapest to set up due to its simplicity. In many
cases, remote asset monitoring supersedes the error-prone
and costly manual task of checking and documenting asset
states in person. Adoption in 2020 was clearly accelerated by
the pandemic and is expected to grow even further, as 36% of
interviewees say they plan to invest significantly in this use
case in the next two years.
• Hindustan Coca-Cola Beverages Pvt. Ltd., located near
Pune, India, adopted remote asset monitoring for its PET and
can-bottling lines. The real-time and continuous monitoring
of critical parameters (e.g., syrup flow rate, can-rinse
pressure, and water temperature) replaced its MS Excel-
based manual reporting. In this specific case, the company
combined the remote connectivity of its assets with a
condition-monitoring use case that generates alarms based
on predefined conditions.
• 2. IoT-based Process Automation
• IoT-based process automation has been rolled out by 33% of companies.
This type of process automation describes operational processes that
were either entirely manual in the past or relied on antiquated, industrial-
automation setups but have now been upgraded with state-of-the-art
hardware and software. Companies that introduce this use case to
upgrade their existing setups often do so to add flexibility and agility in
the operations process so that specific process steps can be changed in
the future. This becomes important because companies are increasingly
interested in aligning their manufacturing and operations processes to
ever-changing customer demands.
• An Australian farmer, reported he was able to use 20% less water
thanks to a new IoT-based irrigation system supplied by Lindsay, a US-
based manufacturer of pivot-irrigation systems. Farmers increasingly
adopt smart IoT-based irrigation systems to automate the process of
irrigation and thereby enhance their crop yields.
• 3. Remote Asset Monitoring and Control (read/write)
• “Read/Write remote asset monitoring and control” is the extension of
“Read-only remote asset monitoring.” On top of “reading” the assets data,
with this setup one can also communicate back and thereby influence
asset control from afar (i.e., “writing” data back).
• Just like the read-only asset monitoring use case, this use case
was accelerated by the COVID-19 pandemic as service teams, engineers,
and other staff needed to find ways to reach an asset that needed their
attention while being in a different location.
• Because of the added complexity and security risk of controlling an asset,
on top of just simply monitoring, this use case comes with significantly
higher costs of installation and maintenance. However, it has been proven
that such solutions pay off in a relatively short time: Of those decision
makers whom IoT Analytics interviewed, 51% reported amortization in
less than 24 months.
• Implementation example
• Schlumberger, an oilfield service company, recently adopted a
monitoring and control solution from Advantech and ReStream. These
companies had partnered up to supply and develop a new oilfield fluid-
monitoring system based on LTE connectivity. The project helped to
achieve flow assurance, ensure asset integrity, and optimize production. It
also helped to increase labor safety. Oilfield companies suffer from a
dynamic chemical environment that, if unchecked, can lead to premature
wear, lost productivity, and the release of lethal poisonous gases
Forum on Internet of Things: Empowering the New
Urban Agenda
Geneva, Switzerland, 19 October 2015

An introduction to oneM2M

Omar Elloumi
oneM2M Technical Plenary chair, Alcatel-
Lucent, [email protected]
M2M Common Service Layer in a nutshell
• It is a software layer
• It sits between M2M applications and communication HW/SW
that provides data transport
• It normally rides on top of IP
• It provides functions that M2M applications across different
industry segments commonly need. Those functions are
exposed to Applications via IT-friendly APIs.
• It allows for distributed intelligence (device, gateway, cloud
apps)
• It is based on RESTful APIs and resources
Standardization approach
Architectur
Use Requireme e Test and
cases nts APIs and Interop
protocols

Security & IP Reference

IotDM
Automotive
privacy communications points

Restful
Device Device
Home webservices
Management certification
APIs
Reuse of
Energy Data exchange existing Open source
protocols
Semantics
E-Health Interworking framework
(future)
oneM2M Architecture approach
Pipe (vertical): Horizontal (based on common Layer)
1 Application, 1 NW, Applications share common service and network infrastructure
1 (or few) type of Device Multipoint communications
Point to point communications

Application Application Application

Business
Application
Application
Common
Common Service Layer
Service Layer

Things
Communication Communication Communication representations
Network (wireline, wireless, Network 1 Network 2
Powerline ..)
IP
Gateway
S
Gateway
Local NW A AA
S S
Local NW A A Device
Device

A Device Device

Device Things
S Common Service Layer
A Application
oneM2M Architecture approach
Automotive Home Energy Automotive Home Energy
Application Application Application Application Application Application

Common Service Layer

Communication Technologies &
Protocols
Communication Networks

Communication Devices & Hardware

Currently developed solutions are similar Horizontal framework, Restful API IoT will be based on ontologies (formal
are vertically integrated, with limited Objects represented as resource description of concepts and relationships,
integration of data models (Zigbee, DLMS Access control policy to access resource e.g. W3C Semantic Sensor Network) as
for smart meters, etc.). well as big data frameworks

TOMORROW
IoT ready IoT enabled
Why does it matter
• Healthy eco-system with economies of scale
Combat
• More partnering choices and opportunities for M2M/IOT
fragmentation industry stakeholders

• Standardized protocols / APIs -> simplifies application

development/deployment
Lower CAPEX • Cross-vertical standards -> same devices and back-ends in
different industries

• Standard features to use networks more efficiently -> get

better tariffs
Lower OPEX • Flexibility for verticals -> utilize best transport network
meeting business needs

Reduced development, test and deployment lifecycles through

Time to Market focusing on core business (application logic)
Technical Specifications
Requirements Functional Definitions Service Layer
Architecture & Acronyms Core Protocols
TS-0002 TS-0001 TS-0011 TS-0004
(WI-0001) (WI-0002) (WI-0003) (WI-0009)

HTTP Protocol CoAP Protocol Management Management

Binding Binding Enablnt - OMA Enablnt - BBF
TS-0009 TS-0008 TS-0005 TS-0006
(WI-0013) (WI-0012) (WI-0010) (WI-0010)

MQTT Protocol Security Service

Binding Solutions Components
TS-0010 TS-0003 TS-0007
(WI-0014) (WI-0007) (WI-0011)

ftp://ftp.onem2m.org/Work Programme/
Technical View
Application
Layer AE AE AE
Mca Mca Mca
Service
Layer CSE CSE CSE CSE
Mcn Mcc Mcn Mcn Mcc Mcn Mcc’
Network Underlying Underlying
Layer NSE Network NSE NSE Network NSE
Other
Device Gateway Server Server

Entities AE (Application Entity), CSE (Common Services Entity) and NSE (Network Services Entity)
Reference Point One or more interfaces - Mca, Mcn, Mcc and Mcc’

EXAMPLE REQUEST EXAMPLE RESPONSE

GET http://provider.net/home/temperature/la HTTP/1.1 200 OK
HTTP/1.1 X-M2M-RI: 56398096
Host: provider.net Content-Type: application/vnd.onem2m-res+json
X-Orig: /CSE-1234/WeatherApp42 Content-Length: 94
X-M2M-RI: 56398096 {"ri":"28375964","cnf":"application/json:0",
Accept: application/vnd.onem2m-res+json "con":"{'timestamp':1413405177000,'value':25.32}"}

Source N. Damour, Sierra Wireless

Reference Architecture For IoT?
• IoT devices are inherently connected – A model is needed to specify
interactions with the devices
• An architecture is needed to “tame” complexity and “achieve” scalability
• Devices are expect to interact with themselves and the environment,
continually – An architecture is need to achieve high-availability and
support deployment across highly-heterogeneous computational platforms
• Devices may not be designed for continuous “everyday” usage – An
architecture is needed to support remote, automatic and managed
updates of the IoT devices.
• IoT devices are likely to be used for collecting and analyzing data – An
architecture is need for managing the identity and access control for IoT
devices to ensure privacy
Generic Reference Model, technologies,

• IoT-A, is a “generic”
architectural reference
model, by the European
Lighthouse Integrated
Project, envisioned as
foundations for reasoning
about architectural principles
and design guidelines for the
emerging IoTs.
 Internet of Things Reference Architecture (IoT RA)
ISO/IEC JTC 1/WG 10
 Reference
IoT Reference Architecture Architecture
– Goals and Objectives

• IoT RA outlines
“what” the overall
structure approach
for the construction
of IoT systems and Conceptual Reference
Model Model
indicates “how” the
architecture and its
An abstract framework for understanding
domains or entities It defines a common structure and
relationships among entities of an
definitions describing the concepts and
will operate relationships with the IoT systems environment and for developing consistent
specifications supporting that environment
IoT RA Structure
Clause Structure

• CM contains
Characteristics
common entities
and their Abstracted and generated to build
relationships
Conceptual Model Reference Model
• RM provides the Develops
basis to define Creates
different
Architecture View
architectures Architecture view
views
Conceptual Model

Conceptual Model
Build
Concepts Overall Model
Reference Model and Architecture Views

Architecture Views

Functional View

is based on System View

Reference Model
Communication View
uses
Information View
Domain Concept
Usage View
Characteristics
Grouping 1st Level
Auto-configuration

Function and management capabilities separation

Highly distributed systems

IoT System Network communication
Characteristics
Network management and operation

Real-time capability

Self-description

Service subscription
Characteristics
Content-Awareness
IoT Service Characteristics Location-Awareness
Time-Awareness
Composability
Discoverability
Modularity
IoT Component Characteristics
Network connectivity
Shareability
Unique identification
IoT Characteristics
Legacy support
Compatibility
Well defined components
Flexibility
Usability
Manageability
Accuracy
Robustness Reliability
Resilience
Availability
Confidentiality
Security
Integrity
Safety
Protection of Personally Identifiable
Privacy
Information
 IoT Characteristics
Data - Volume, Velocity, Veracity, Variability and Variety

Heterogeneity

Other Characteristics
Regulation compliance

Scalability

Trustworthiness
Autoconfiguration Characteristic
• Description
• Ability to automatically reconfigure a device based on the interworking of
predefined rules
• Relevance to IoT
• Autoconfiguration is useful for IoT systems, as there are many and varied
components that can change over time
• It allows automatic maintenance and elimination of faulty components
• DHCP, ZeroConf, UPnP, Bonjour, …
Real-Time Capability
• Description
• Realtimeliness refers to a mode of operation where computation can control,
monitor or respond in a timely manner to an external process when it occurs
• Relevance to IoT
• IoT systems may require stream processing, which requires acting on data
events in progress in order to react “appropriately”
• Example – Process control requires monitoring of and acting on a number of parameters,
including temperature , flow, pressure or status of a device.
IoT Conceptual Model
• CM defines the concepts of, and relationships among, the
entities within IoT systems, in a generic, abstract and simple way.
• The overall model of IoT entities and their relationships
• The key concepts in a typical IoT system
• The relationships between the entities, especially between digital
entities and their physical entities
• Identifies the actors and where they are located
• Specifies how things and services collaborate via the network
CM – Overall Model for IoT Concepts
Entity

IoT-User

Is a Is a

Human Component Digital Entity Entity Identifier

Represents Has
Human User Digital User Virtual Entity Physical Entity Tag

Interacts using Is contained within Contains Acts on

Monitors

Uses
Data
Is a
Application Service Source Sensor Actuator

Interacts with Interacts with

Interacts through Uses Interacts with Is a
Is a
Entity Component Component
Interacts through
Connects
Network IoT-Gateway IoT Device

Interacts through
CM – Entity and Domain Concepts

Domain

Contains Interacts with

Digital Entity
Includes
Entity
Contains Is a
Entity
Has

Physical Is a Nework
Entity Is a
Is a
Contains

IoT-User
CM – Domain Interactions

Domain A Domain B
Interacts with
CM – Domain Composition
Domain A

Contains Contains

Domain B Domain C
CM → RM
Transforming Concept into a Model
Entity-based IoT RM

IoT Users
(Include Human, Devices/HMI)
Security and Privacy

Operation & Application Resource &

Network
Management Service Interchange
System System System Peer Systems

IoT Gateway
(local services and data)

IoT Devices
(Include sensors, actuators, and tags)

Physical Entity, including human Tags

© ISO/IEC CD 30141 – All rights reserved
Domain-based IoT RM

User Domain (UD)

Operations & Management Application Service Resource & Interchange

Domain (OMD) Domain (ASD) Domain (RID)

Sensing & Controlling Domain (SCD)

Physical Entity Domain (PED)

© ISO/IEC CD 30141 – All rights reserved

Domain Composition
Inside-Domain Cross-Domain
Functions Functions
User Domain
User Interface

Dynamic composition & Automated Interoperability

Operation & Application Service IoT Resource &
Management Domain Domain Interchange domain

Safety & Resilience

Life Cycle Business API & Portal Resource Interchange
Management Support

Interoperability
Trust & Privacy

Connectivity
Security
Business Services Analytics Access Control
Security & Safety
Management

Regulation Management Logic & Rules Resource Management

Local Modeling Asset Management Executor

Sensing &
Controlling Network Access
Domain

Sensing Identification Actuation

Physical Entity Domain

CM, RM and RA
Interplay and Relationship
Relationship between CM, RM and RA
• IoT Domains are derived from the stakeholders, hardware
and software: CM -> RM -> RA

IoT RA IoT RA IoT RA IoT RA

IoT RA
IoT Conceptual Model Functional System Information Communication
Usage View
View View View View

IoT Reference Model

(Entity Based)
IoT Reference Model – Domain Based
IoT RA System View
IoT Resource and Interchange Domain
Resource Access
Interchange
Management Management
System
System System

Human
Users
Application Service Domain
User Interface Devices

Business Resource Controlled Physical

Service Service IoT
Objects
System System Gateway Actuator
HMI
Local
Control Sensed Physical Objects
Operation and Management System
Domain Sensor
Digital
User Regulation Sensing and Control Physical Entity Domain
Operation
Management Domain
System
System
User Domain
User Net Service Net Access Net Proximity Net
Functional Model
Functional Model – Information Flow
Communication View
IoT Architecture Models
ITU-T
ITU-T Y.2060 Model
Capabilities
Management

Capabilities
Security
Application IoT
Layer Applications

Service Support Generic Support Specific Support

& Application
Specific Management Capabilities
Generic Management Capabilities

Capabilities Capabilities

Specific Security Capabilities

Generic Security Capabilities
Support Layer

Networking Capabilities
Network
Layer
Transport Capabilities

Device
Device Generic
Generic Support
Support Specific
Specific Support
Support
Layer
Layer Capabilities
Capabilities Capabilities
Capabilities
ALLIANCE FOR INTERNET OF THINGS
INNOVATION
Reference Architecture
AIOTI Model – Consolidated High Level IoT Reference Architecture
❖ AIOTI WG03 IoT Reference Architecture
➢ Consolidation of IoT reference architecture from many sources, i.e. IoT-A,
IEEE P2413, OneM2M, ITU-T, ISO/IEC JTC1
➢ Architectural views based on ISO/IEC/IEEE 42010
❑ Domain Model ❑ Functional Model
User
Legend
contingent on
communication
“symbolic”

invokes

IoT Service associated Virtual

Entity
exposes

IoT Device
models & tracks

Interacts with
“Things”

AIOTI
ALLIANCE FOR INTERNET OF THINGS INNOVATION
Industrial Internet Consortium
Reference Architecture
 IIC Reference Architecture

Stakeholders
• Biz Decision Makers
• System Engineers
• Product Managers
Why
• System Engineers
• Product Managers Functional Viewpoint
• System Architects Verb
What Functional decomposition &
• Architects
• Engineers
Noun structures
Interfaces & interactions
• Developers
• Integrators Implementation Viewpoint
• Deployment How Activity & functional to
• Operations
technologies
mapping
Hierarchy: The Factory
Entreprise The Old World: Industrie 3.0

Work
Centers • Hardware-based structure
• Functions are bound to hardware
Station • Hierarchy-based communication
• Product is isolated
Control
Device

Field Device

Product

Graphics © Anna Salari, designed by freepik

Axis 1 – Hierarchy: The Factory
The New World: Industrie 4.0 Connected
World

• Flexible systems and machines

• Functions are distributed
throughout the network
• Participants interact across
Smart
hierarchy levels
Factory
• Communication among all
participants
• Product is part of the network

Smart
Products
Graphics © Anna Salari, designed by freepik
Reference Architectural Model Industry
Next-generation Industrial Manufacturing Systems
4.0

A Reference
model for all
participants
involved in
Industry 4.0
discussions

Basic RAMI is extended by security capabilities – Security is built into each layer and each dimension
INTEL Architecture
 Various Working Groups for Innovation and
interoperability
Working Group (Active Since) Charter Founding Members
Establish Internet Protocol (IP) as the network to interconnect ARM, Atmel, Bosch, Cooper, Dust
IPSO Alliance (Sep 2008) smart objects, and allow existing infrastructure to be readily used Networks, EDF, Ericsson, Freescale et
without translation gateways or proxies al
Developed an architectural reference model to allow seamless
ALU, Hitachi, IBM, NEC, NXP, SAP,
integration of heterogeneous IoT technologies into a coherent
IoT-A (2010-2013) Siemens, and universities – “Mission
architecture to realize ‘Internet of Things’ rather than ‘Intranet of
Accomplished late 2013”
Things’
Develop technical specifications for a common M2M Service Leading ICT standards bodies namely
oneM2M (2012) Layer to allow connectivity between devices and various M2M ETSI, ARIB, TTC, ATIS, TIA, CCSA and
applications, to realize horizontally integrated Internet-of-Things TTA
Collaborate for an open, universal IoT software framework across
devices and industry applications, based on AllJoyn open source Qualcomm, in collaboration with
AllSeen Alliance (2013)
project, originally developed by Qualcomm but now released to Linux Foundation
community developers
Industrial Internet Consortium (Mar Accelerate development and adoption of intelligent industrial
AT&T, Cisco, GE, Intel, IBM
2014) automation for public usecases
 Various Working Groups for Innovation
and interoperability
Working Group (Active Since) Charter Founding Members
Develop an open specification for IoT that will make data available in a
ARM, BT, IBM, Intel, Living
HyperCat (May 2014) way that others could make use of it, through a thin interoperability
PlanIT, et al
layer.
Define interoperable device communication standards (for peer-to-
Open Interconnect Consortium Atmel, Broadcom, Dell, Intel,
peer, mesh & bridging, reporting & control etc.) across verticals, and
(Jul 2014) Samsung and Wind River
provide an open source implementation
IEEE; collaborating with
Create a standard interoperability architecture and define commonly
oneM2M, ETSI and other
IEEE P2413 (Jul 2014) understood data objects, for information sharing across IoT
SDOs to evolve joint
systems; Standardization targeted by 2016
standards
Create an open, secure, simple, power-efficient protocol, based on
ARM, Freescale, Nest,
Thread (2014) robust mesh network that runs over standard 802.15.4 radios, and
Samsung, Silicon Labs, Yale
can support a wide variety of home products
Proposed a new Light-weight M2M protocol standard, based on
OMA LWM2M (2014) client-server model for remote management of M2M devices and OMA
related service enablement