Architecture Reference Model

Reference Model and Architecture

•An ARM consists of two main parts: a Reference model and a Reference Architecture.

•A reference model describes the domain using a number of sub-models

IOT Reference Model

IoT domain model
The domain model captures the basic attributes of the main concepts and the
relationship between these concepts. A domain model also serves as a tool for human
communication between people working in the domain in question and between
people who work across different domains.

Main concepts
The IoT is a support infrastructure for enabling objects and places in the physical
world to have a corresponding representation in the digital world.

Physical vs. Virtual World

•The Devices are physical artefacts with which the physical and virtual worlds
interact. Devices as mentioned before can also be Physical Entities for certain types of
applications, such as management applications when the interesting entities of a
system are the Devices themselves and not the surrounding environment. For the IoT
Domain Model, three kinds of Device types are the most important:

1. Sensors:

 These are simple or complex Devices that typically involve a transducer that
converts physical properties such as temperature into electrical signals.
 These Devices include the necessary conversion of analog electrical signals into
digital signals, e.g. a voltage level to a 16-bit number, processing for simple
calculations, potential storage for intermediate results, and potentially
communication capabilities to transmit the digital representation of the physical
property as well receive commands.
 A video camera can be another example of a complex sensor that could detect
and recognise people.

2. Actuators:

 These are also simple or complex Devices that involve a transducer that converts
electrical signals to a change in a physical property (e.g. turn on a switch or
move a motor).
 These Devices also include potential communication capabilities, storage of
intermediate commands, processing, and conversion of digital signals to analog
electrical signals.
3. Tags:

 Tags in general identify the Physical Entity that they are attached to. In reality,
tags can be Devices or Physical Entities but not both, as the domain model
shows.
 An example of a Tag as a Device is a Radio Frequency Identification (RFID) tag,
while a tag as a Physical Entity is a paper-printed immutable barcode or Quick
Response (QR) code.
 Either electronic Devices or a paper-printed entity tag contains a unique
identification that can be read by optical means (bar codes or QR codes) or radio
signals (RFID tags).
 The reader Device operating on a tag is typically a sensor, and sometimes a
sensor and an actuator combined in the case of writable RFID tags.

Information Model
Virtual Entity in the IoT Domain Model is the “Thing” in the Internet of Things, the IoT
information model captures the details of a Virtual Entity- centric model. Similar to the
IoT Domain Model, the IoT Information Model is presented using Unified Modelling
Language (UML) diagrams.

High-
level IoT Information Model

Relationship between core concepts of IoT Domain Model and IoT Information Model.
Functional model
The IoT Functional Model aims at describing mainly the Functional Groups (FG) and
their interaction with the ARM, while the Functional View of a Reference Architecture
describes the functional components of an FG, interfaces, and interactions between
the components. The Functional View is typically derived from the Functional Model
in conjunction with high-level requirements.
Device functional group
The Device FG contains all the possible functionality hosted by the physical Devices
that are used for increment the Physical Entities. This Device functionality includes
sensing, actuation, processing, storage, and identification components, the
sophistication of which depends on the Device capabilities

Communication functional group

The Communication FG abstracts all the possible communication mechanisms used by
the relevant Devices in an actual system in order to transfer information to the digital
world components or other Devices.

IoT Service functional group

The IoT Service FG corresponds mainly to the Service class from the IoT Domain
Model, and contains single IoT Services exposed by Resources hosted on Devices or in
the Network (e.g. processing or storage Resources).

Virtual Entity functional group

The Virtual Entity FG corresponds to the Virtual Entity class in the IoT Domain Model,
and contains the necessary functionality to manage associations between Virtual
Entities with themselves as well as associations between Virtual Entities and related
IoT Services, i.e. the Association objects for the IoT Information Model. Associations
between Virtual Entities can be static or dynamic depending on the mobility of the
Physical Entities related to the corresponding Virtual Entities.

IoT Service Organization functional group

The purpose of the IoT Service Organisation FG is to host all functional components
that support the composition and orchestration of IoT and Virtual Entity services.
Moreover, this FG acts as a service hub between several other functional groups such
as the IoT Process Management FG when, for example, service requests from
Applications or the IoT Process Management are directed to the Resources
implementing the necessary Services.

IoT Process Management functional group

The IoT Process Management FG is a collection of functionalities that allows smooth
integration of IoT-related services (IoT Services, Virtual Entity Services, Composed
Services) with the Enterprise (Business) Processes.

Management functional group

The Management FG includes the necessary functions for enabling fault and
performance monitoring of the system, configuration for enabling the system to be
flexible to changing User demands, and accounting for enabling subsequent billing for
the usage of the system. Support functions such as management of ownership,
administrative domain, rules and rights of functional components, and information
stores are also included in the Management FG.

Security functional group

The Security FG contains the functional components that ensure the secure operation
of the system as well as the management of privacy. The Security FG contains
components for Authentication of Users (Applications, Humans), Authorisation of
access to Services by Users, secure communication (ensuring integrity and
confidentiality of messages) between entities of the system such as Devices, Services,
Applications, and last but not least, assurance of privacy of sensitive information
relating to Human Users.

Application functional group

The Application FG is just a placeholder that represents all the needed logic for
creating an IoT application. The applications typically contain custom logic tailored to
a specific domain such as a Smart Grid

Communication model
Safety
the IoT Reference Model can only provide IoT-related guidelines for ensuring a safe
system to the extent possible and controllable by a system designer.
Eg: smart grid.

Privacy
Because interactions with the physical world may often include humans, protecting
the User privacy is of utmost importance for an IoT system. The IoT-A Privacy Model
depends on the following functional components: Identity Management,
Authentication, Authorisation, and Trust & Reputation

Trust
Generally, an entity is said to ‘trust’ a second entity when the first entity makes the
assumption that the second entity will behave exactly as the first entity expects.”

Security
The Security Model for IoT consists of communication security that focuses mostly on
the confidentiality and integrity protection of interacting entities and functional
components such as Identity Management, Authentication, Authorisation, and Trust &
Reputation.
Functional View: Description of what the system does, and its main functions.
•Information View: Description of the data and information that the system
handles. •Deployment and Operational View: Description of the main real world
components of the system such as devices, network routers, servers, etc.

IOT Functional View

Device and Application functional group

Devices are like phone,machines

Communication functional group

 The Hop-by-Hop Communication is applicable in the case that devices and
messages have to traverse the mesh from node-to-node (hop-by-hop) until they
reach a gateway node which forwards the message (if needed) further to the
Internet.
 This FC has two main interfaces:
 one “southbound” to/from the actual radio on the device, and
 one “northbound” to/from the Network FC in the Communication FG.

 The Network FC is responsible for message routing & forwarding and the
necessary translations of various identifiers and addresses.
 The translations can be
 (a) between network layer identifiers to MAC and/or physical network
identifiers,
 (b) between high-level human readable host/node identifiers to network
layer addresses and
  (c) translation between node/service identifiers and network locators in
case the higher layers above the networking layer use node or service
identifiers

 The End-to-End Communication FC is responsible for end-to-end transport of

application layer messages through diverse network and MAC/PHY layers.

IoT Service functional group

 The IoT Service FC is a collection of service implementations, which interface
the related and associated Resources.
 For a Sensor type of a Resource, the IoT Service FC includes Services that
receive requests from a User and returns the Sensor Resource value in
synchronous or asynchronous (e.g. subscription/notification) fashion.
 The IoT Service Resolution FC contains the necessary functions to realize a
directory of IoT Services that allows dynamic management of IoT Service
descriptions and discovery/lookup/resolution of IoT Services by other Active
Digital Artifacts.

Virtual Entity functional group

 The Virtual Entity FG contains functions that support the interactions between
Users and Physical Things through Virtual Entity services.
 An example of such an interaction is the query to an IoT system of the form,
“What is the temperature in the conference room Titan?”

Process Management functional group

Advertisements

REPORT THIS AD

The IoT Process Management FG, integration of business processes with IoT-related
services.

 It consists of two FCs:

 The Process Modelling FC provides that right tools for modelling a business
process that utilises IoT-related services.
 The Process Execution FC contains the execution environment of the process
models created by the Process Modelling FC and executes the created processes
by utilising the Service Organisation FG in order to resolve high-level application
requirements to specific IoT services

Service Organization functional group

 The Service Composition FC manages the descriptions and execution
environment of complex services consisting of simpler dependent services.
 An example of a complex composed service is a service offering the average of
the values coming from a number of simple Sensor Services.
 The Service Orchestration FC resolves the requests coming from IoT Process
Execution FC or User into the concrete IoT services that fulfill the requirements.


The Service Choreography FC is a broker for facilitating communication among

Services using the Publish/Subscribe pattern. Users and Services interested in specific
IoT-related services subscribe to the Choreography FC, providing the desirable service
attributes even if the desired services do not exist.
Security functional group
The Security FG contains the necessary functions for ensuring the security and
privacy of an IoT system.

The Identity Management FC manages the different identities of the involved

Services or Users in an IoT system

The The Authentication FC verifies the identity of a User and creates an assertion
upon successful verification. verifies the identity of a User and creates an assertion
upon successful verification.

The Authorization FC manages and enforces access control policies. It provides

services to manage policies (CUD), as well as taking decisions and enforcing them
regarding access rights of restricted resources.

The Key Exchange & Management is used for setting up the necessary security
keys between two communicating entities in an IoT system.

The Trust & Reputation FC manages reputation scores of different interacting

entities in an IoT system and calculates the service trust levels.

Management functional group

The Configuration FC maintains the configuration of the FCs and the Devices in an
IoT system. The component collects the current configuration of all the FCs and
devices, stores it in a historical database, and compares current and historical
configurations.

The Fault FC detects, logs, isolates, and corrects system-wide faults if possible. This
means that individual component fault reporting triggers fault diagnosis and fault
recovery procedures in the Fault FC.The component collects the current configuration
of all the FCs and devices, stores it in a historical database, and compares current and
historical configurations.

The Member FC manages membership information about the relevant entities in an

IoT system.

The State FC is similar to the Configuration FC, and collects and logs state
information from the current FCs, which can be used for fault diagnosis, performance
analysis and prediction, as well as billing purposes.

The Reporting FC is responsible for producing compressed reports about the system
state based on input from FCs. ii-font-family
IOT Information View
Information Description
The pieces of information handled by an IoT system

 Virtual Entity context information, i.e. the attributes (simple or complex) as

represented by parts of the IoT Information model.
 IoT Service output itself is another important part of information generated by an
IoT system. For example, Sensor or a Tag Service.
 Virtual Entity descriptions in general, which contain not only the attributes
coming from IoT Devices (e.g. ownership information).
 Virtual Entity Associations with other Virtual Entities (e.g. Room #12 is on
floor#7)
 Resource Descriptions –> type of resource (e.g. sensor), identity, associated
Services, and Devices.
 Device Descriptions –> device capabilities (e.g. sensors, radios).
 Descriptions of Composed Services –> the model of how a complex service
is composed of simpler services.
 IoT Business Process Model describes –> the steps of a business process
utilizing other IoT-related services.
 Management information such as state information from operational FCs used for
fault/performance purposes, configuration snapshots, reports, membership
information, etc.

Information Flow and Lifecycle

IOT Information handling
Deployment and operational view