UNIT 2

UNIT-II SYSTEM MANAGEMENT AND PLATFORM DESIGN

UNIT II SYSTEM MANAGEMENT AND
PLATFORM DESIGN
Need for IoT Systems Management- SNMP- Network Operator
Requirements NETCONF - YANG- IoT System Management with
NETCONF-YANG.IoT Platforms Design Methodology - Case
study on Weather Monitoring.
What is IoT Management?
• IoT devices once installed may need software updates or bug fixes.
Sometimes it has to be replaced or repaired. This may result in
downtime.
• In order to solve what can we do?
• We can effectively manage the devices using IoT Device management.
• IoT device management is the method of authenticating, configuring,
monitoring, provisioning and maintaining the software and device
firmware that offers its functional capabilities.
• In order to maintain the security, health, and connectivity of the
IoT devices, effective device management is essential.
• Normally, Solutions along with broad device management will also be
provided by IoT application vendors.
Requirements for IoT Device Management

1.Provisioning and Authentication

2.Configuration and Control
3.Monitoring and Diagnostics
4.Software Updates and Maintenance
Need for IoT Systems Management
• Automating Configuration : IoT system management capabilities can help in automating the
system configuration.
• Monitoring Operational & Statistical Data : Management systems can help in monitoring
operational and statistical data of a system. This data can be used for fault diagnosis or
prognosis.
• Improved Reliability: A management system that allows validating the system
configurations before they are put into effect can help in improving the system reliability.
• System Wide Configurations : For IoT systems that consists of multiple devices or nodes,
ensuring system wide configuration can be critical for the correct functioning of the system.
• Multiple System Configurations : For some systems it may be desirable to have multiple
valid configurations which are applied at different times or in certain conditions.
• Retrieving & Reusing Configurations : Management systems which have the capability of
retrieving configurations from devices can help in reusing the configurations for other
devices of the same type
SNMP
SNMP
• Simple Network Management Protocol (SNMP) is a
networking protocol used for the management and
monitoring of network-connected devices in Internet
Protocol networks.
• The SNMP protocol is embedded in multiple local
devices such as routers, switches, servers, firewalls, and
wireless access points accessible using their IP address.
• SNMP provides a common mechanism for network
devices to relay management information within single
and multi-vendor LAN or WAN environments.
• It is an application layer protocol in the OSI model
framework.
• Typically, the SNMP protocol is implemented using the
User Datagram Protocol (UDP).
• UDP is a connectionless protocol that works like the
Transmission Control Protocol (TCP) but assumes that
error-checking and recovery services are not required.
• Instead, UDP continuously sends datagrams to the
recipient whether they receive them or not.
• SNMP Management Information Bases (called MIBs for
short) are data structures that define what can be
collected from the local device and what can be
changed and configured.
• There are many MIBs defined by standards bodies such
as the IETF and ISO, as well as proprietary MIBs defined
by specific IT equipment vendors such as Cisco and
software vendors such as Microsoft and Oracle.
• There are three different versions of SNMP:
• SNMP version 1 (SNMPv1)—This was the first implementation,
operating within the structure management information specification,
and described in RFC 1157.
• SNMP version 2 (SNMPv2)—This version was improved to support
more efficient error handling and is described in RFC 1901. It was first
introduced as RFC 1441. It is often referred to as SNMPv2c.
• SNMP version 3 (SNMPv3)—This version improves security and
privacy. It was introduced in RFC 3410.
• SNMP version 2 is the most commonly deployed SNMP protocol
version today. The most recent version, SNMP version 3, includes new
security features that add support for authentication and encryption
of SNMP messages as well as protecting packets during transit.
SNMP Runtime Components
• SNMP-managed devices and resources—These are the devices and
network elements on which an agent runs.
• SNMP agent—This software runs on the hardware or service being monitored
by SNMP, collecting data on various metrics like CPU usage, bandwidth usage
or disk space. As queried by the SNMP manager, the agent finds and sends this
information back to SNMP management systems.
• SNMP manager—(also referred to as SNMP server) This component functions
as a centralized management station running an SNMP management
application on many different operating system environments. It actively
requests agents send SNMP updates at regular intervals.
• Management information base (MIB)—This data structure is a text file
(with a .mib file extension) that describes all data objects used by a particular
device that can be queried or controlled using SNMP including access control.
Inside the MIB there are many different managed objects which can be
identified by Object Identifiers. An Object Identifier (OID) is a MIB identifier that
is used to delineate between devices within the MIB. OIDs are uniquely
generated as numeric identifiers used for access to MIB objects.
• In operation, the Simple Network Management Protocol uses one or
several administrative SNMP managers, which oversee groups of
networked computers and associated devices. A continually running
software program, called an agent, feeds information to the managers
by way of SNMP. The agents create variables out of the data and
organizes them into hierarchies described by management information
bases.
• SNMP is one of the most widely deployed networking industry
protocols and is supported on a variety of hardware—from common
network elements like routers, switches, and wireless access points to
endpoints such as printers, scanners, and Internet of Things (IoT)
devices. In addition to hardware, SNMP software can be used to
monitor Dynamic Host Configuration Protocol (DHCP) configuration
services.
• While SNMP is used in a network of any size, its biggest value is when
used in larger networks. By using SNMP, a network administrator will
be able to manage and monitor all SNMP devices from a single
interface.
SNMP Commands

• SNMP tools perform many functions that rely on a mix of

push and pull communications between network
devices and the network management system. At its
core set of functions, it can execute read or write
commands, such as resetting a password or changing a
configuration setting. It can also find how much network
bandwidth, CPU and memory are in use. Some SNMP
managers can automatically send the administrator an
email or text message alert if a predefined threshold is
exceeded.
The following PDUs, or protocol data units,
describe the messaging commands
supported by the protocol:
• Get Request—A request to retrieve the value of a variable or list of
variables.
• Set Request—Sent by the SNMP manager to the agent to issue
configurations or commands.
• GetNext Request—Sent by the SNMP manager to agent to find the values
of the next record in the MIB's hierarchy.
• GetBulk Request—Sent by the SNMP manager to the agent to obtain large
tables of data by performing multiple GetNext Request commands.
• SNMP Response—Sent by the agent to the SNMP manager
• SNMP Trap—Asynchronous trap messages from SNMP agents alert an
SNMP manager that a significant event such as an error or failure, has
occurred.
• SNMP Inform—Confirms receipt of a trap.
• What is an SNMP port?
• SNMP ports are utilized via UDP 161 for SNMP Managers
communicating with SNMP Agents (i.e. polling) and UDP
162 when agents send unsolicited Traps to the SNMP
Manager.
LIMITATIONS OF SNMP
NETCONF
• Network monitoring systems are tasked with ensuring the availability and
performance of computers and network services and can detect and report
on failures of devices or connections by deploying NETCONF/SNMP in
device.

Definition
• NETCONF is a protocol that that can manage, configure and install new
configuration of network device. Its operations are realized on top of an easy
Remote Procedure Call (RPC) layer. NETCONF uses Extensible Markup
Language (XML) based on data encoding for protocol messages. The
protocol messages are exchanged on the top of a secure transport protocol.
• NETCONF is primarily intended to be used as a device
configuration mechanism, whereas SNMP is ordinarily
used for monitoring, polling, and fault notification. Both
protocols report management information that’s useful
to NNMi. NETCONF is the (only) candidate to replace CLI
for configuration management of programmable
networks. In terms of SDN, NETCONF is usually
referenced as a southbound API from an SDN controller
to network agents like switches and routers due to its
potential for supporting multi-vendor environments.
Types

• NETCONF protocol are often conceptually partitioned into

four layers:
1.The Content layer has a configuration data and
notification data.
2.The Operations layer defines a set of base protocol
operations to retrieve and to edit the configuration data.
3.The Messages layer is responsible for encoding remote
procedure calls (RPCs) and notifications.
4.The Secure Transport layer features a secure and reliable
transport of messages between a client and a server.
NETCONF Notification
• It is an event indicating that a configuration change has occurred. The change
can be a replacement configuration, deleted configuration, or changed
configuration. The notifications are sent at the end of a successful
configuration that shows the set of changes.

• Operations
NETCONF is an XML-formatted command and response protocol that runs
primarily over Secure Shell (SSH) transport. The NETCONF protocol is
analogous in some ways to traditional device console Command Line Interface
(CLI), except that the XML-formatted commands and results are designed for
management applications. Details of NETCONF communication between
NNMi and therefore the managed device are transparent to the NNMi user.
However, the subsequent overview could also be helpful for troubleshooting
• A NETCONF client establishes an SSH connection with the NETCONF server on
the managed device. Valid SSH user name and password credentials must be
specified by the client and authenticated by the device.
• The client application and device exchange capabilities in the form of <hello>
messages.
• The client initiates requests to the device in the form of Remote Procedure Call
(RPC) messages; including standard <get> or <get-config> operations, plus any
vendor-specific operations that are defined for the device.
• The device responds with results of the operations within the sort of RPC reply
messages.
• When the client application has finished sending requests and processing the
responses, it sends a <close-session> RPC message to the device.
• The device acknowledges with an <ok> RPC reply message.
• Finally, both sides terminate the SSH connection.
• TCP port 830 assigned to NETCONF by IANA.
• NETCONF develop by the IETF.
• NETCONF is a Connection-Oriented protocol.
• NETCONF must provide authentication, data integrity, confidentiality and replay
protection.
• NETCONF implementation support the SSH transport protocol mapping.
• The NETCONF protocol has been implemented in network devices like routers and
switches by some major equipment vendors.
• NNMi uses NETCONF to gather information about the device during discovery or
rediscovery. NNMi doesn’t use NETCONF to modify device configurations or to
watch status or performance metrics.
• NETCONF may be a relatively new management protocol therefore it’s not as widely
available across device vendors as compared to SNMP.
IoT Systems Management with NETCONF-YANG
• YANG is a data modeling language used to model configuration and state data
manupulated by the NETCONF protocol.
• The generic approach of IoT device management with NETCONF-YANG.
• Roles of various components are:
• 1) Management System
• 2) Management API
• 3) Transaction Manager
• 4) Rollback Manager
• 5) Data Model Manager
• 6) Configuration Validator
• 7) Configuration Database
• 8) Configuration API
• 9) Data Provider API
• Management System : The operator uses a management system to
send NETCONF messages to configure the IoT device and receives
state information and notifications from the device as NETCONF
messages.
• Management API : allows management application to start NETCONF
sessions
• Transaction Manager: executes all the NETCONF transactions and
ensures that ACID properties hold true for the transactions
• Rollback Manager : is responsible for generating all the transactions
necessary to rollback a current configuration to its original state
• Data Model Manager : Keeps track of all the YANG data models and
the corresponding managed objects. Also keeps track of the
applications which provide data for each part of a data model.
• Configuration Validator : checks if the resulting configuration after
applying a transaction would be a valid configuration.
• Configuration Database : contains both configuration and operational
data
• Configuration API : Using the configuration API the application on the
IoT device can be read configuration data from the configuration
datastore and write operational data to the operational datastore
• Data Provider API: Applications on the IoT device can register for
callbacks for various events using the Data Provider API. Through the
Data Provider API, the applications can report statistics and
operational data
Steps for IoT device Management with NETCONF-YANG

• Create a YANG model of the system that defines the configuration and state
data of the system
• Complete the YANG model with the ‗Inctool‗ which comes withLibnetconf.
• Fill in the IoT device management code in the TransAPImodule.
• Build the callbacks C file to generate the libraryfile.
• Load the YANG module and the TransAPImodule into the Netopeer server
using Netopeer manager tool.
• The operator can now connect from the management system to the
Netopeer server using the NetopeerCLI.
• Operator can issue NETCONF commands from the Netopeer CLI. Command
can be issued to change the configuration data, get operational data or
execute an RPC on the IoT device
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, we defined five 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 5: Service Specifications
Step 5: Service Specifications
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.
Implementation: RESTful Web
Services
REST services implemented with Django REST Framework

# Models – models.py
from django.db import models

class Mode(models.Model):
name = models.CharField(max_length=50)
1. Map services to models. Model class State(models.Model):
fields store the states (on/off, name = models.CharField(max_length=50)
auto/manual)

2. Write Model serializers. Serializers allow

complex data (such as model instances) to be
converted to native Python datatypes that can
then be easily rendered into JSON, XML or
other content types.

# Serializers – serializers.py
from myapp.models import Mode, State
from rest_framework import serializers

class ModeSerializer(serializers.HyperlinkedModelSerializer):
class Meta:
model = Mode
fields = ('url', 'name')

class StateSerializer(serializers.HyperlinkedModelSerializer):
class Meta:
model = State
fields = ('url', 'name')
 Implementation: RESTful Web Services
# Views – views.py
# Models – models.py from myapp.models import Mode, State
from django.db import models
3. Write ViewSets for the Models which from rest_framework import viewsets
combine the logic for a set of related views in from myapp.serializers import
class Mode(models.Model): a single class. ModeSerializer, StateSerializer
name = models.CharField(max_length=50)
class ModeViewSet(viewsets.ModelViewSet):
class State(models.Model): queryset = Mode.objects.all()
name = models.CharField(max_length=50) serializer_class = ModeSerializer

class StateViewSet(viewsets.ModelViewSet):
queryset = State.objects.all()
serializer_class = StateSerializer

# URL Patterns – urls.py

from django.conf.urls import patterns, include, url
from django.contrib import admin
from rest_framework import routers
4. Write URL patterns for the services.
from myapp import views
admin.autodiscover() Since ViewSets are used instead of views, we
router = routers.DefaultRouter() can automatically generate the URL conf by
router.register(r'mode', views.ModeViewSet) simply registering the viewsets with a router
router.register(r'state', views.StateViewSet) class.
urlpatterns = patterns('',
Routers automatically determining how the
url(r'^', include(router.urls)),
url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework')), URLs for an application should be mapped to
url(r'^admin/', include(admin.site.urls)), the logic that deals with handling incoming
url(r'^home/', 'myapp.views.home'), requests.
)
 Implementation: RESTful Web
Services
Screenshot of browsable
State REST API

Screenshot of browsable
Mode REST API
Implementation: Controller Native
Service #Controller service def runAutoMode():
import RPi.GPIO as GPIO ldr_reading = readldr(LDR_PIN)
if ldr_reading < threshold:
import time switchOnLight(LIGHT_PIN)
Native service deployed locally import sqlite3 as lite setCurrentState('on')
import sys else:
switchOffLight(LIGHT_PIN)
setCurrentState('off')
con = lite.connect('database.sqlite')
cur = con.cursor() def runManualMode():
state = getCurrentState()
GPIO.setmode(GPIO.BCM) if state=='on':
threshold = 1000 switchOnLight(LIGHT_PIN)
setCurrentState('on')
LDR_PIN = 18 elif state=='off':
LIGHT_PIN = 25 switchOffLight(LIGHT_PIN)
setCurrentState('off')
def readldr(PIN):
def getCurrentMode():
reading=0
1. Implement the native service in cur.execute('SELECT * FROM myapp_mode')
GPIO.setup(PIN, GPIO.OUT) data = cur.fetchone()
Python and run on the device GPIO.output(PIN, GPIO.LOW) #(1, u'auto') return data[1]
time.sleep(0.1)
GPIO.setup(PIN, GPIO.IN) def getCurrentState():
cur.execute('SELECT * FROM myapp_state')
while (GPIO.input(PIN)==GPIO.LOW): data = cur.fetchone()
reading=reading+1 #(1, u'on') return data[1]
return reading
def setCurrentState(val):
query='UPDATE myapp_state set name="'+val+'"'
def switchOnLight(PIN):
cur.execute(query)
GPIO.setup(PIN, GPIO.OUT)
GPIO.output(PIN, GPIO.HIGH) while True:
currentMode=getCurrentMode()
def switchOffLight(PIN): if currentMode=='auto':
runAutoMode()
GPIO.setup(PIN, GPIO.OUT) elif currentMode=='manual':
GPIO.output(PIN, GPIO.LOW) runManualMode()
time.sleep(5)
Implementation:
Application # Views – views.py
def home(request):
1. Implement Django Application View out=‘’
if 'on' in
request.P
OST:
valu
e
s

{
"
n
a
m
e
"
:

"
o
n
"
}
r=requests.put('http://127.0.0.1:8000/state/1/', data=values, auth=(‘username', ‘password'))
result=r.text
output = json.loads(result)
out=output['name']
if 'off' in request.POST:
values = {"name": "off"}
r=requests.put('http://127.0.0.1:8000/state/1/', data=values, auth=(‘username', ‘password'))
result=r.text
output = json.loads(result)
out=output['name']
if 'auto' in request.POST:
values = {"name": "auto"}
r=requests.put('http://127.0.0.1:8000/mode/1/', data=values, auth=(‘username', ‘password'))
result=r.text
Implementation:
Application <div class="app-content-inner">
<fieldset>
<div class="field clearfix">

2. Implement Django Application <label class="input-label icon-lamp" for="lamp-state">Auto</label>

<input id="lamp-state" class="input js-lamp-state hidden" type="checkbox">
{% if currentmode == 'auto' %}
Template <div class="js-lamp-state-toggle ui-toggle " data-toggle=".js-lamp-state">
{% else %}
<div class="js-lamp-state-toggle ui-toggle js-toggle-off" data-toggle=".js-lamp-state">
{% endif %}
<span class="ui-toggle-slide clearfix">
<form id="my_form11" action="" method="post">{% csrf_token %}
<input name="auto" value="auto" type="hidden" />
<a href="#" onclick="$(this).closest('form').submit()"><strong class="ui-toggle-off">OFF</strong></a>
</form>
<strong class="ui-toggle-handle brushed-metal"></strong>
<form id="my_form13" action="" method="post">{% csrf_token %}
<input name="manual" value="manual" type="hidden" />
<a href="#" onclick="$(this).closest('form').submit()"><strong class="ui-toggle-on">ON</strong></a>
</form></span>
</div></div>
<div class="field clearfix">
<label class="input-label icon-lamp" for="tv-state">Light</label>
<input id="tv-state" class="input js-tv-state hidden" type="checkbox">
{% if currentstate == 'on' %}
<div class="js-tv-state-toggle ui-toggle " data-toggle=".js-tv-state">
{% else %}
<div class="js-tv-state-toggle ui-toggle js-toggle-off" data-toggle=".js-tv-state">
{% endif %}
{% if currentmode == 'manual' %}
<span class="ui-toggle-slide clearfix">
<form id="my_form2" action="" method="post">{% csrf_token %}
<input name="on" value="on" type="hidden" />
<a href="#" onclick="$(this).closest('form').submit()"><strong class="ui-toggle-off">OFF</strong></a>
</form>
<strong class="ui-toggle-handle brushed-metal"></strong>
<form id="my_form3" action="" method="post">{% csrf_token %}
<input name="off" value="off" type="hidden" />
<a href="#" onclick="$(this).closest('form').submit()"><strong class="ui-toggle-on">ON</strong></a>
</form>
</span>
{% endif %}
{% if currentmode == 'auto' %}
{% if currentstate == 'on' %}
<strong class="ui-toggle-on">&nbsp;&nbsp;&nbsp;&nbsp;ON</strong>
{% else %}
<strong class="ui-toggle-on">&nbsp;&nbsp;&nbsp;&nbsp;OFF</strong>
{% endif %}{% endif %}
</div>
</div>
</fieldset></div></div></div>
Finally - Integrate the
System
• Setup the device
• Deploy and run the REST and Native services
• Deploy and run the Application
• Setup the database

Django Application

REST services implemented with Django-REST framework

SQLite Database

Native service implemented in Python

OS running on Raspberry Pi

Raspberry Pi device to which sensors

and actuators are connected
Weather Monitoring System

A design of a weather monitoring IoT system:

• Collect data on environmental conditions such as temperature,
pressure, humidity and light in area using multiple end nodes.
• The end nodes send the data to the cloud where the data is
aggregated and analyzed.
• The end nodes are equipped with various sensors (such as
temperature, pressure, humidity and light).
Weather Monitoring System

• Deployment design
Weather Monitoring System

• Controller service
Weather Reporting Bot

A design of a weather reporting bot:

• Report weather information by sending tweets on Twitter.
• The end nodes are comprised of a Raspberry Pi mini-computer,
temperature, pressure, humidity and light sensors. In addition to the
sensors, a USB webcam is also attached to the device.
• To send tweets:
• Using a Python library for Twitter called tweepy.
• With tweepy we can use the Twitter REST API to send tweets.
Weather Reporting Bot

• Schematic diagram – device and sensors.

Weather Reporting Bot

• Screenshot of a weather update tweeted.