Wowow

The IoT World Forum (IoTWF) Standardized
Architecture
 As shown in Figure the IoT Reference Model defines a set of levels with control
flowing from the center (this could be either a cloud service or a dedicated data
center), to the edge, which includes sensors, devices, machines, and other types
of intelligent end nodes.
In general, data travels up the stack,originating from the edge, and goes
northbound to the center. Using this reference model, we are able to achieve the
following:
 Decompose the IoT problem into smaller parts
 Identify different technologies at each layer and how they relate to one
another
  Define a system in which different parts can be provided by different vendors
  Have a process of defining interfaces that leads to interoperability
 Define a tiered security model that is enforced at the transition points between
levels
Architecture
The following sections look more closely at each of the seven layers of the
IoT Reference Model.
 Layer 1: Physical Devices and Controllers Layer The first layer of the IoT
Reference Model is the physical devices and controllers layer . This layer is
home to the “things” in the Internet of Things, including the various
endpoint devices and sensors that send andreceive information. The size of
these “things” can range from almost microscopic sensors to giantmachines
in a factory. Their primary function is generating data and being capable of being
queried and/or controlled over a network .
Layer 2: Connectivity Layer In the second layer of the IoT Reference
Model, the focus is on connectivity. The most important function of this IoT
layer is the reliability and timely transmission of data.
Architecture
Architecture
Layer 3: Edge Computing Layer Edge computing is the role of this
layer.
 Edge computing is often referred to as the “fog” layer
 At this layer, the emphasis is on data reduction and
converting network data flows into information that is ready for
storage and processing by higher layers.
One of the basic principles of this reference model is that
information processing is initiated as early and as close to the edge of
the network as possible.
Architecture
Architecture
Upper Layers: Layers 4–7 The upper layers deal with handling and processing the IoT data generated by the bottom
layer. For the sake of completeness, Layers 4–7 of the IoT Reference Model are summarized in Table 2-2.
M2M Communication- Architecture
 Machine-to-machine communication, or M2M, is exactly as it sounds: t wo
machines “communicating,” or exchanging data, without human
interfacing or interaction.
This includes serial connection, powerline connection (PLC), or wireless
communications in the industrial Internet of Things (IoT).
Switching over to wireless has made M2M communication much easier and
enabled more applications to be connected.
 In general, when someone says M2M communication, they often are
referring to cellular communication for embedded devices.
 Examples of M2M communication in this case would be vending machines
sending out inventory information or ATM machines getting authorization
to despense cash
M2M ARCHITECTURE
Over the time, the scope of M2M has expanded to include the Internet of Things.
Recognizing this need, in 2012 ETSI and 13 other founding members launched one
M2M as a global initiative designed to promote efficient M2M communication
systems andhttp://www.internet-of-things-book.com
Book website: IoT Architecture
M2M ARCHITECTURE(ETSI)
 The one M2M architecture divides IoT functions into three major domains: the application layer,
the services layer and the network layer. While this architecture may seem simple and somewhat
generic at first glance, it is very rich and promotes interoperability through IT-friendly APIs and
supports a wide range of IoT technologies. Let's examine each of these domains in turn:
 Applications Layer: The one M2M architecture gives major attention to connectivity between
devices and their applications. This domain includes the application layer protocols and attempts to
standardize northbound API definitions for interaction with Business Intelligence (BI) Systems.
Applications tend to be industry specific and have their own sets of data models and thus they are
shown as vertical entities.
 Services Layer: This layer is shown as a horizontal framework across the vertical industry
applications. At this layer, horizontal modules include the physical network that the IoT
applications run on, the underlying management protocols, and the hardware. Examples include
backhaul communications via cellular, MPLS (Multiprotocol label switching) networks, VPNs and so
on. Riding on top is the common services layer. This conceptual layer adds APIs and middleware
supporting third party services and applications.
 Network Layer: This is the communication domain for the IoT devices and endpoints. It includes the
devices themselves and the communication network that links them. Embodiments of this
communication infrastructure includes wireless mesh technologies and wireless point to
multipoint systems.
Architecture IEEE/IETF standardized industrial IOT
OGC
What is OGC and how it works?

The Open Geospatial Consortium (OGC) is a not-for-profit organisation
focused on developing and defining open standards for the geospatial
community to allow interoperability between various software, and data
services.
What is OGC architecture in IoT?

The OGC SensorThings API provides an open, geospatial-enabled and
unified way to interconnect the Internet of Things (IoT) devices, data, and
applications over the Web. At a high level the OGC SensorThings API
provides two main functionalities and each function is handled by a part.
OGC architecture for IOT
IoT Design Methodology
Outline
• IoT Design Methodology that includes:

• Purpose & Requirements Specification
• Process Specification
• Domain Model Specification
• Information Model Specification
• Service Specifications
• IoT Level Specification
• Functional View Specification
• Operational View Specification
• Device & Component Integration
• Application Development
Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015

IoT Design Methodology - Steps
Step 1: Purpose & Requirements Specification
• The first step in IoT system design methodology is to define

the purpose and requirements of the system.
• In this step, the system purpose, behavior and
requirements (such as data collection requirements, data
analysis requirements, system management
requirements, data privacy and security requirements,
user interface requirements, ...) are captured.
Step 2: Process Specification
• The second step in the IoT design methodology

is to define the process specification.
• In this step, the use cases of the IoT system are
formally described based on and derived from
the purpose and requirement specifications.
Step 3: Domain Model Specification
• The third step in the IoT design methodology is to define
the Domain Model. The domain model describes the
main concepts, entities and objects in the domain of IoT
system to be designed.
• Domain model defines the attributes of the objects and
relationships between objects. Domain model provides an
abstract representation of the concepts, objects and
entities in the IoT domain, independent of any specific
technology or platform.
• With the domain model, the IoT system designers can get
an understanding of the IoT domain for which the system
is to be designed.
Step 4: Information Model Specification
• The fourth step in the IoT design methodology
is to define the Information Model.
• Information Model defines the structure of all
the information in the IoT system, for
example, attributes of Virtual Entities,
relations, etc. Information model does not
describe the specifics of how the information is
represented or stored.
• To define the information model, we first list
the Virtual Entities defined in the Domain
Model. Information model adds more details to
the Virtual Entities by defining their attributes
and relations.
Step 5: Service Specifications
• The fifth step in the IoT design methodology is to
define the service specifications.
• Service specifications define the services in the
IoT system, service types, service
inputs/output, service endpoints, service
schedules, service preconditions and service
effects.
Step 6: IoT Level Specification
• The sixth step in the IoT design
methodology is to define the IoT level for
the system.
• In Chapter-1 Introduction , we defined 6 IoT
deployment levels.
Step 7: Functional View Specification
• The seventh step in the IoT design methodology is
to define the Functional View.
• The Functional View (FV) defines the functions of
the IoT systems grouped into various Functional
Groups (Fgs).
• Each Functional Group either provides
functionalities for interacting with instances of
concepts defined in the Domain Model or provides
information related to these concepts.
Step 8: Operational View Specification
• The eighth step in the IoT design methodology is to
define the Operational View Specifications.
• In this step, various options pertaining to the IoT
system deployment and operation are defined,
such as, service hosting options, storage options,
device options, application hosting options, etc
Step 9: Device & Component Integration
• The ninth step in the IoT design methodology
is the integration of the devices and
components.
Step 10: Application Development
•The final step in the IoT design

methodology is to develop the IoT
application.
Home Automation Case Study
Step:1 - Purpose & Requirements
• Applying this to our example of a smart home automation system, the
purpose and requirements for the system may be described as follows:
• Purpose : A home automation system that allows controlling of the lights in a home
remotely using a web application.
• Behavior : The home automation system should have auto and manual modes. In
auto mode, the system measures the light level in the room and switches on the
light when it gets dark. In manual mode, the system provides the option of manually
and remotely switching on/off the light.
• System Management Requirement : The system should provide remote monitoring
and control functions.
• Data Analysis Requirement : The system should perform local analysis of the data.
• Application Deployment Requirement : The application should be deployed locally
on the device, but should be accessible remotely.
• Security Requirement : The system should have basic user authentication capability.
Step:2 - Process Specification
Step 3: Domain Model Specification
Step 4: Information Model Specification
Step 6: IoT Level Specification
Step 7: Functional View Specification
Step 8: Operational View Specification
Step 9: Device & Component Integration
Step 10: Application Development
• Auto
• Controls the light appliance
automatically based on the lighting
conditions in the room
• Light
• When Auto mode is off, it is used for
manually controlling the light
appliance.
• When Auto mode is on, it reflects the
current state of the light appliance.
Assignment -II
Create the design methodology
as per the 10 step process given
in chpater 2
1 for Smart Agriculture
2.For Smart City

Wowow

Uploaded by

Copyright:

Available Formats

Wowow

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Wowow

Uploaded by

Copyright:

Available Formats

The IoT World Forum (IoTWF) Standardized

What is OGC and how it works?

What is OGC architecture in IoT?

• IoT Design Methodology that includes:

Book website: http://www.internet-of-things-book.com Bahga & Madisetti, © 2015

• The first step in IoT system design methodology is to define

• The second step in the IoT design methodology

•The final step in the IoT design

You might also like