ISO/IEC 29182-3:2014
(Main)Information technology - Sensor networks: Sensor Network Reference Architecture (SNRA) - Part 3: Reference architecture views
Information technology - Sensor networks: Sensor Network Reference Architecture (SNRA) - Part 3: Reference architecture views
ISO/IEC 29182-3:2014 provides Sensor Network Reference Architecture (SNRA) views. The architecture views include business, operational, systems, and technical perspectives, and these views are presented in functional, logical, and/or physical views where applicable. ISO/IEC 29182-3:2014 focuses on high-level architecture views which can be further developed by system developers and implementers for specific applications and services.
General Information
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 29182-3
First edition
2014-02-15
Information technology — Sensor
networks: Sensor Network Reference
Architecture (SNRA) —
Part 3:
Reference architecture views
Technologies de l’information — Réseaux de capteurs: Architecture de
référence pour réseaux de capteurs —
Partie 3: Vues de l’architecture de référence
Reference number
©
ISO/IEC 2014
© ISO/IEC 2014
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2014 – All rights reserved
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 1
5 Purpose of Sensor Network Reference Architecture . 2
6 Overview of Sensor Network Reference Architecture . 3
7 Business architecture .11
8 Information architecture .12
8.1 Introduction .12
8.2 Application architecture .12
8.3 Data architecture .12
9 Technical architecture .13
9.1 Introduction .13
9.2 Physical View .16
9.3 System View .17
9.4 System Functionality .19
9.5 Technical View .19
Bibliography .22
© ISO/IEC 2014 – All rights reserved iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies
casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 29182-3 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology.
ISO/IEC 29182 consists of the following parts, under the general title Information technology — Sensor
networks: Sensor Network Reference Architecture (SNRA):
— Part 1: General overview and requirements
— Part 2: Vocabulary and terminology
— Part 3: Reference architecture views
— Part 4: Entity models
— Part 5: Interface definitions
— Part 6: Applications
— Part 7: Interoperability guidelines
iv © ISO/IEC 2014 – All rights reserved
Introduction
A wide range of applications has been proposed for sensor networks. In practice, however, sensor
networks have been built and deployed for a relatively small number of applications. This is partly due
to the lack of a business case for certain applications and partly due to technical challenges in building
a non-trivial sensor network of reasonable complexity. The main reason for this impediment is multi-
disciplinary expertise – such as sensors, communications and networking, signal processing, electronics,
computing, and cyber security – is required to design a sensor network. Presently, the design process
is so complex that one can leverage little from one sensor network design to another. It appears as if
one has to start from almost scratch every time one wishes to design and deploy a sensor network. Yet,
upon closer inspection, there are many commonalities in instantiations of sensor networks that realize
various applications. These commonalities include similarities in the choice of network architecture and
the entities/functional blocks that are used in the architecture.
The purpose of the ISO/IEC 29182 series of International Standards (ISs) is to
— provide guidance to facilitate the design and development of sensor networks,
— improve interoperability of sensor networks, and
— make sensor network components plug-and-play, so that it becomes fairly easy to add/remove
sensor nodes to/from an existing sensor network.
The ISO/IEC 29182 series can be used by sensor network designers, software developers, system
integrators, and service providers to meet customer requirements, including any applicable
interoperability requirements.
The ISO/IEC 29182 series comprises seven parts. Brief descriptions of these parts are given next.
ISO/IEC 29182-1 provides a general overview and the requirements for the sensor network reference
architecture.
ISO/IEC 29182-2 provides definitions for the terminology and vocabulary used in the reference
architecture.
ISO/IEC 29182-3 presents the reference architecture from various viewpoints, such as business,
operational, system, technical, functional, and logical views.
This part of ISO/IEC 29182 categorizes the entities comprising the reference architecture into two
classes of physical and functional entities and presents models for the entities.
ISO/IEC 29182-5 provides detailed information on the interfaces among various entities in the reference
architecture.
ISO/IEC 29182-6 provides detailed information on the development of International Standardized
Profiles.
ISO/IEC 29182-7 provides design principles for the reference architecture that take the interoperability
requirements into account.
© ISO/IEC 2014 – All rights reserved v
INTERNATIONAL STANDARD ISO/IEC 29182-3:2014(E)
Information technology — Sensor networks: Sensor
Network Reference Architecture (SNRA) —
Part 3:
Reference architecture views
1 Scope
This International Standard (IS) provides Sensor Network Reference Architecture (SNRA) views. The
architecture views include business, operational, systems, and technical perspectives, and these views
are presented in functional, logical, and/or physical views where applicable. This IS focuses on high-
level architecture views which can be further developed by system developers and implementers for
specific applications and services.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 29182-1, Information technology — Sensor networks: Sensor Network Reference Architecture
(SNRA) — Part 1: General overview and requirements
ISO/IEC 29182-2, Information technology — Sensor networks: Sensor Network Reference Architecture
(SNRA) — Part 2: Vocabulary and terminology
ISO/IEC 29182-4, Information technology — Sensor networks: Sensor Network Reference Architecture
(SNRA) — Part 4: Entity models
ISO/IEC 29182-5, Information technology — Sensor networks: Sensor Network Reference Architecture
(SNRA) — Part 5: Interface definitions
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 29182-2 apply.
4 Abbreviated terms
1D One-dimensional
2D Two-dimensional
3D Three-dimensional
AL Application Layer
BFL Basic Function Layer
CIP Collaborative Information Processing
CLM Cross Layer Management
© ISO/IEC 2014 – All rights reserved 1
CPU Computer Processing Unit
GHL Gateway Hardware Layer
GPS Global Positioning System
NOAA National Oceanic and Atmospheric Administration
IS International Standard
OGC Open Geospatial Consortium
OS Operating System
PV Physical View
RA Reference Architecture
SL Service Layer
SNHL Sensor Node Hardware Layer
SNRA Sensor Network Reference Architecture
SOA Service-Oriented Architecture
SV System View
TS Technical Standards
TV Technical View
5 Purpose of Sensor Network Reference Architecture
This International Standard provides reference architecture views consistent with the requirements
which are defined in ISO/IEC 29182-1 (General overview and requirements) and can be utilized more
effectively with other Parts, especially with ISO/IEC 29182-4 (Entity Models) and ISO/IEC 29182-5
(Interface Definitions).
A Reference Architecture (RA) is a generalized architecture of several end systems that share one or
more common domains, giving direction downward and requiring compliance upward. Therefore, an
architecture for a certain application will contain some, most, or all of the reference architecture. In
other words, the developer can reuse entities and elements in the reference architecture that fit his or
her application architecture and ignore the rest of entities and elements in the reference architecture.
In addition, the RA provides standards and policies for building a specific architecture.
RAs provide a consistent point of departure for implementing solutions so that each implementation:
a) Follows a consistent decomposition and design pattern;
b) Reduces cost by exploiting opportunities for reuse of services, products, data definitions, etc.;
c) Reduces schedule by starting with a core architecture to be tailored for implementation; and
d) Reduces risk by:
— Incorporating required global capabilities; and
— Taking advantaged of lessons learned and related expertise.
The Sensor Network Reference Architecture (SNRA) outlines “what” the overall structured approach
is for facilitating interoperability and the SNRA, from the details of this structure, indicates “how” the
2 © ISO/IEC 2014 – All rights reserved
architecture and its entities will operate through the development of interface standards. In short, the
SNRA provides rules and guidance for developing and presenting architecture descriptions.
This standard provides not only multiple perspectives of SNRA (e.g. business, information, and technical)
but also multiple views of the technical architecture (e.g. physical, system, operational, etc.) describing a
sensor network (e.g. business, information, application, and data). The combination of these architecture
perspectives and views forms a comprehensive architectural description of the sensor network system.
The reference architecture perspectives and views are to:
a) Show how Sensor Networks operate in a homogeneous or a heterogeneous system;
b) Show the systems of equipment and the flows of information that support the sensor networks; and
c) Show the technical rules and guidelines that allow these systems to interoperate.
Typically, a developer begins depicting an architecture with desires and needs for the data/information
that could be provided by a sensor network or sensor networks and that could meet the desires and
needs (e.g. then translated into a set of requirements). Additionally, the developer needs to have an
understanding of the technology available and also the roadmap of technologies to come. For example,
the desires and needs could be a computer and a set of sensor nodes (thus, a sensor network) in a car to
monitor and control subsystems, or alternatively they could be a large system of systems, such as the
sensor networks by National Oceanic and Atmospheric Administration (NOAA) to monitor worldwide
weather in order to predict weather patterns and to provide warnings if necessary. Each developer will
have specific requirements concerning the capabilities that a sensor node or sensor network should have
for target applications and services. The developer also needs to make many decisions in developing
a sensor network architecture including whether a sensor network will perform data processing to
provide high level information to a user, or a sensor network will make the raw data available to a user
who will use its own applications to process the raw data. The Sensor Network Reference Architecture
(SNRA) can provide the developer with various options and understanding for the developments, and
more importantly, SNRA provides the developer with the architecture starting point.
The SNRA supports the development of interoperating and interacting architectures. It defines the
multiple perspectives of SNRA and the multiple views of the technical architecture. Each view is
composed of sets of architecture data elements that are depicted via graphic, tabular, or textual
products. The SNRA also clearly defines the relationships between these architectural views and the
data elements they contain.
6 Overview of Sensor Network Reference Architecture
Sensor network is a system of distributed sensor nodes communicating with each other and also
interacting with other sensor networks that monitors environments external to the sensor network in
order to acquire, process, transfer, and provide information extracted from a physical world.
This Sensor Network Reference Architecture (SNRA) consists of a set of domains which are concerned
with gathering raw data from each domain’s physical environment, processing raw data into information,
and delivering information to a user or users. The user can be a human or a machine/software (e.g.
automated command and control system). In cases where a sensor network has a sensor node or sensor
nodes equipped with an actuator or actuators, information in the forms of a decision can flow from the
user to the actuator(s) attached to the sensor node to provide an actuation command.
Each sensor network consists of various entities such as sensor nodes, actuators, a network, processing (at
a local sensor node, a gateway, and/or fusion centre), applications used by the sensor nodes, applications
1)
used by the users , and finally the user. Figure 1 shows a high level physical view of multiple sensor
network domains although there are other domains not captured in the figure. Most sensor network
domains are designed to be disparate as each sensor network focuses on its own specific application.
This figure is to emphasize the importance of interoperability among dissimilar networks, sensors, and
1) [When the user is a person] Personal information belongs to individuals. It shall be implemented with any
protection means when personal information is connected to networks. [Reference: NIST-IR7628, Smart Grid Cyber
Security Vol.2 “Privacy and the Smart Grid”, and OECD: “Privacy Principles”]
© ISO/IEC 2014 – All rights reserved 3
disparate data contents and formats. Figure 1 also shows that sensing can occur in all geospatial expanses
(e.g. space, air, maritime, ground, and subsurface (e.g. underground, and below ocean/lake/river
surface)). In each geospatial expanse, there are many capabilities that sensor networks can provide as
shown in the figure. In space, a sensor network formed by the sensor nodes in a constellation of satellites
can provide data and information about Earth’s weather, air pollution, oceanic current movements,
and so on. In the air, air traffic control cannot be performed without sensor networks (e.g. radars).
In maritime, ships rely on GPS for navigating the oceans. The sensor networks can also be effectively
used for maritime container tracking, tagging of, and protection for the contents of the containers, On
the ground, many different sensor networks are found as there exist many different applications, (e.g.
intelligent highway, transportation, supply chain management, medical, military, industrial, finance,
first responders, governmental, home, environmental monitoring, perimeter protection and intrusion
prevention, health/situation monitoring of elderly or patients, and so on).
Figure 1 — High level physical graphic of sensor network domains
In summary Figure 1 shows that there are many dissimilar sensor networks in various geospatial
expanses, and within each expanse, there are many disparate sensor network applications and services
where the disparity exists in types of sensors in the sensor network, networks that support the sensor
networks, and data formats utilized by the sensors and the communication networks.
Figure 1 also attempts to illustrate an interoperable sensor network reference architecture, consisting
of multiple horizontally interoperable subsystems or modules and the interfaces between those
subsystems and modules. Interoperability also needs to exist vertically to transmit the information
seamlessly within the hierarchical structure of the sensor networks supporting a complex system of
systems. Both horizontal and vertical interoperability can be achieved by a standard developing process
that promotes open architecture and also by standardization of interfaces between subdivisions (both
subsystems and sensor networks), layered structures in sensor networks and its applications. For the
reference architecture to fulfil the requirements of interoperability, existing interoperability standards
should be used to describe sensor network systems. Additionally, the needs for new standards, to satisfy
new technologies, applications and services of sensor networks, can be identified from the sensor
network reference architecture.
4 © ISO/IEC 2014 – All rights reserved
Figure 2 describes the sensor network reference architecture by identifying the main entities of sensor
networks and the interfaces between the main entities which make up a sensor network. The detailed
descriptions of the interfaces (e.g. Interface 1, Interface 2, …, Interface 5) can be found in ISO/IEC 29182-
5.
The main entities identified are:
a) Sensor Nodes, and a sensor node has:
— Sensor Node Hardware Layer (SNHL);
— Basic Functions Layer (BFL);
— Service Layer (SL);
— Application Layer (AL); and
— Cross Layer Management (CLM);
b) Gateway and a gateway is likely to have the same or similar layers and layer structure as those in
the sensor node); thus, a gateway has:
— Gateway Hardware Layer (GHL);
— Basic Functions Layer (BFL);
— Service Layer (SL);
— Application Layer (AL); and
— Cross Layer Management (CLM);
c) External Environment through Access Network and Backbone Network connecting to service
providers and users.
In Service Provider, it is likely to have the similar layer structure as the one in a gateway.
The interfaces between these main entities, identified in grey colour-filled boxes in Figure 2, are:
a) Within a sensor node, there are:
— Interface between Sensor Node Hardware Layer and Basic Functions Layer (SNHL / BFL);
— Interface between Basic Functions Layer and Service Layer (BFL / SL);
— Interface between Service Layer and Application Layer (SL / AL); and
— Interfaces between Cross Layer Management and Applications Layer, Service Layer, and Basic
Functions Layer (CLM / AL-SL-BFL);
b) Interface between a Sensor Node to a Sensor Node within a Sensor Network; and
c) Interface between Sensor Network Gateway Node and other networks (ISO/IEC 29182-1, Figure 3
designates “Backbone Network and Access Network” as “Other Networks,” which is also shown in
Figure 9 of this standard).
The interfaces between Sensor Node Hardware Layer and Basic Functions Layer (SNHL / BFL) are
realized by the functions reside in SNHL and those that reside in BFL.
© ISO/IEC 2014 – All rights reserved 5
Figure 2 — Overview of sensor network interfaces in a sensor node, sensor node to sensor node,
and sensor node to the External Environment
Figure 3 describes the physical architecture of a sensor node, which can be mapped to the Sensor Node
Hardware depicted in Figure 2, sensor node physical reference architecture. The sensor node physical
reference architecture includes:
— Computer processing unit (CPU): A CPU embedded in a sensor node enables the node become
intelligent. It hosts an Operating System (OS), application algorithms, and other software. A CPU
could be located outside of a sensor node and a sensor node transmits its measurements to the CPU
for processing.
— Storage: A storage device is a memory unit which can be embedded in a sensor node or can be
located outside of the node. The memory unit stores various event data experienced by the node, e.g.
measurements, processed data if an on-the-node processing is performed, and other event data.
— Sensor: Sensor or sensing element is a measuring device of external environment of a certain
phenomenology. Typically, this device converts raw measurements into a stream of measureable
electrical signal. Depending on the type of a sensing device, the device can measure acoustics,
seismic or vibration, magnetic, various light spectra (e.g. visual, infrared, etc.), electromagnetic (e.g.
radio frequencies), temperature, gas, pressure, motion, contaminants, objects, etc. Depending on
the complexity and technology implemented in the sensor, the sensor can measure 1-dimensional,
2-dimensional, and 3-dimensional signals along with time tagging.
— Communication unit: A communication unit is an essential component of a sensor node. This
communication unit provides either wired or wireless data link which is used to transmit the data
collected by the sensor or sensing element and any processed data if available in real-time or in non-
real-time. For the case of non-real-time data transmission, a type of storage device is required.
— Actuator(s): An actuator may reside in a sensor node or outside of the sensor node. Actuators are
means to interact with physical environments, e.g. automatic temperature control. Actuator(s) can
receive information (e.g. command) directly from sensor after data processing through wired or
wireless data link.
— Power supply: A sensor node will require a power supply. If a sensor node is physically connected
via a wire, such sensor node typically does not require on-board power supply, e.g. batteries. In case
of a wireless sensor node, a battery is required. Power management for a sensor node is a critical
matter, and a power management utility firmware may be hosted in the CPU, especially for the
sensor nodes remotely located wirelessly.
6 © ISO/IEC 2014 – All rights reserved
Power supply to power a sensor node is a critical element for sensor nodes and thus for an entire sensor
network. This criticality becomes even greater for a wireless, geographically dispersed sensor network.
The power supply is typically primary batteries (non-rechargeable); however, the idea of self-generating
power sources leveraging natural phenomena (e.g. sun light (solar), vibration, wind, so-called energy
harvesting methodologies) are under research and development.
The power supply will greatly depend on the type of sensor and sensor node functions. Power management
on remote sensors is of great importance to the functionality of the sensor node. The remoteness of
the sensor node will dictate the power supply capacity and power usage management. The required
frequency of inter-nodal communications will also dictate how the power should be managed.
The interface lines inside of the sensor node shown in Figure 3 are not specified. This is because the
implementation of a sensor node is highly dependent on application requirements and on its hardware
constraints.
Figure 3 — Sensor node physical reference architecture
Figure 4 illustrates a set of functional entities that realizes various sensor network services, and it
depicts the functional view of the sensor network reference architecture. This sensor network functional
architecture lists many significant functions in a sensor network, but this figure does not include all
functions. This functional architecture shows three domains, namely:
— Sensing Domain: This domain interfaces with sensors, gateways, and other entities (e.g. storage
devices) in a sensor network or sensor networks. This domain receives data from the sensor
network(s) and transmits to Service Domain via Network Domain per requests made by users.
Additionally, Sensing Domain can have capabilities to process measurements (e.g. raw data) from
sensors in the sensor network via local area network and/or wide area network.
— Network Domain: This domain provides data/information links between Sensing Domain and
Service Domain.
© ISO/IEC 2014 – All rights reserved 7
— Service Domain: This domain hosts various applications that provide requested services by users. To
perform the required applications, this domain can also support various data processing capabilities
from data (e.g. measurements) and/or information (e.g. data from processing the measurements)
from Sensing Domain via Network Domain.
And this figure also shows two groups, shown in the vertical rectangular box:
— Data, Information, and Communication Group: This group of functions is responsible for data
processing, information generation, and communications of the data and information generated
between the domains and to data/information requesters (e.g. users).
— Control and Management Group: This group of functions is responsible for managing entities within
each domain. Sensing Domain and Service Domain have similar management functions; however,
what these functions manage in each domain are different. For example, for Sensing Domain, the
devices being managed by Device Management are typically sensor entities. For Service Domain,
the devices being managed are typically computer assets. For Network Domain, the devices being
managed by Device Management are communications devices.
Figure 4 — Sensor Network Functional Architecture
In the sensor network functional architecture shown in Figure 4, Sensing Domain transports
data/information to Service Domain through Local Area Networks or Wide Area Network. As shown
in the figure, there are two main groups responsible for data and information generation: Data,
Information, and Communications Group and Control and Management Grou
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...