Module 3 – Architectural

Overview
 Building an architecture
• Architecture refers to the description of the main conceptual elements,
the actual elements of a target system, how they relate to each other, and
principles for the design of the architecture. A conceptual element refers
to an intended function, a piece of data, or a service.
• An actual element, meanwhile, refers to a technology building block or a
protocol. The term “reference architecture” relates to a generalized model
that contains the richest set of elements and relations that are of
relevance to the domain “Internet of Things.”
• When looking at solving a particular problem or designing a target
application, the reference architecture is to be used as an aid to design an
applied architecture, i.e. an instance created out of a subset of the
reference architecture.
• The applied architecture is then the blueprint used to develop the actual
system solution (Figure). The approach taken here is much inspired from
the work in the EU FP7 (European frame work programme) project IoT-A
(IoT-A EUFP7 2013).

• An architecture can be described in several different views to capture

specific properties that are of relevance to model, and the views chosen in
this book are the functional view, deployment view, process view, and
information view.
• When creating a model for the reference architecture, one needs to
establish overall objectives for the architecture as well as design principles
that come from understanding some of the desired major features of the
resulting system solution.
• These objectives and principles have to be derived from a deeper understanding of the
actual problem domain, and is typically done by identifying recurring problems or type
solutions, and thus by that, extracting common design patterns.

• The problem domain establishes the foundation for the subsequent solutions. It is
common to partition the architecture work and solution work into two domains, each
focusing on specific issues of relevance at the different levels of abstraction.

• The top level of the triangle is referred to here as the “problem domain” (“domain model”
in software engineering). The problem domain is about understanding the applications of
interest, for example, developed through scenario building and use case analysis in order
to derive requirements.
• In addition, constraints are typically identified as well. These constraints can be technical,
like limited power availability in wireless sensor nodes, or non-technical, like constraints
coming from legislation or business.
• The lower level is referred to as the solution domain. This is where design
objectives and principles are established, conceptual views are refined,
required functions are identified, and where logical partitions of
functionality and information are described.

• Often this is where a logical architecture is defined, or network

architecture in the form of a network topology diagram is produced.

• It is also common to identify suitable technology components such as

operating systems and protocols or protocol stacks at this level.

• The actual system solution is finally captured by a system design that

typically results in actual software and hardware components, as well as
information on how these are to be configured, deployed, and
provisioned.
 Main design principles and needed
capabilities
• Within existing work for deriving requirements and creating architectures or
reference models for IoT and M2M, three primary sources can been identified.
• Two of them are the larger European 7th Framework Program research projects,
SENSEI (2013) and IoT-A (2013), the third being the result of a standardization
activity driven by ETSI in their Technical Committee (TC) M2M (ETSI M2M TC 2013).
These sources have been selected, as they represent state-of-the-art in terms of
creating more complete architectures for the IoT and M2M.
• The approach taken in SENSEI was to develop an architecture and technology
building blocks that enable a “Real World integration in a future Internet.”
• Key features include the definition of a real world services interface and the
integration of numerous Wireless Sensor and Actuator Network deployments into
a common services infrastructure on a global scale.
• The service infrastructure provides a set of services that are common to a vast
range of application services and is separated from any underlying communication
network for which the only assumption made was that it should be based on
Internet Protocol (IP).
• The telecommunications industry, meanwhile, has focused on defining a common
service core for supporting various M2M applications, and that is agnostic to
underlying networks in ETSI TC M2M.

• The approach taken has been to analyze a set of M2M use cases, derive a set of
M2M service requirements, and then to specify an architecture as well as a set of
supporting system interfaces.

• Similar to SENSEI, there was a clear approach towards a horizontal system with
separation of devices, gateways, communications networks, and the creation of a
common service core and a set of applications, all separated by defined reference
points.

• The approach taken in IoT-A differs from the two approaches above in the sense
that instead of defining a single architecture, a reference architecture is created,
captured in what the IoT-A refers to as the Architectural Reference Model (ARM).
• The vision of IoT-A is, via the ARM, to establish a means to achieve a high
degree of interoperability between different IoT solutions at the different
system levels of communication, service, and information. IoT-A provides a
set of different architectural views, establishes a proposed terminology
and a set of Unified Requirements (IoT-A UNI 2013).

• Comparing these different approaches, a common feature is the focus on a

horizontal system approach.

• The overall design objective of IoT architecture shall be to target a

horizontal system of real-world services that are open, service-oriented,
secure, and offer trust.
• Design for reuse of deployed IoT resources across application domains.
Deployed IoT resources shall be able to be used in a vast range of different
applications.
• Design for a set of support services that provide open service-oriented
capabilities and can be used for application development and execution.
• Design for different abstraction levels that hide underlying complexities
an heterogeneities.
• Design for sensing and actors taking on different roles of providing and
using services across different business domains and value chains.
• Design for ensuring trust, security, and privacy. Trust within IoT often
implies reliability, which can be both ensuring the availability of services as
well as how dependable the services are, and that data is only used for the
purposes the end-user has agreed to.
• Design for scalability, performance, and effectiveness. IoT deployments
will happen on a global scale and are foreseen to involve billions of
deployed nodes.
• Sensor data will be provided with a wide range of different characteristics.
Data may be very infrequent (e.g. alarms or detected abnormal events), or
may be coming as real-time data streams, all dependent on the type of
data needed or based on application needs.
• Design for evolvability, heterogeneity, and simplicity of integration. Technology is
constantly changing, and given the nature of IoT deployments where devices and
sensor nodes are expected to be operational and in the field for many years,
sometimes with lifecycles of over 15 years.

• Design for simplicity of management. Again going back to one of the potential
barriers for IoT adaptation, simplicity of management is an important capability
that needs to be properly taken care of when designing IoT solutions.

• Design for different service delivery models. We already know about the clear
trends to move from product offerings to a more combined product and service
offering in a number of industries, for instance, connected vehicles, and Software
as a Service (SaaS) as a delivery model.

• Design for lifecycle support. The lifecycle phases are: planning, development,
deployment, and execution. Management aspects include deployment efficiency,
design time tools, and run-time management.

• From these design principles, and taking into consideration detailed use cases and
target applications, it is possible to identify requirements that form the basis for a
more detailed architecture design.
An IoT Architecture Outline
Communication Layer
• Connectivity between the resources on one end and the different
computing infrastructures that host and execute service support logic and
application logic on the other end.
Business Layer :
The success of any device does not depend only on technologies used in it but also how
it is being delivered to its consumers. Business layer does these tasks for the device. It
involves making flowcharts, graphs, analysis of results, and how device can be improved,
etc.
Perception Layer
• This layer is also called the physical layer. It is the base of IoT
and consists of physical components such as sensors, power
networks, and embedded systems.
• The physical layer is responsible for capturing data and
physical events from the physical environment.
• This layer handles the physical connections between objects,
sensors, and other physical devices.
Standards considerations