Configuration of IoT devices - Systems managament

1
SWE4005 Internet of Things
Module 3: IoT System Management with NETCONF-YANG

Module 3- IoT System Management with
NETCONF-YANG
Need for IoT Systems Management, Simple Network
Management Protocol (SNMP), Limitations of SNMP, Network
Operator Requirements, NETCONF, YANG, IoT Systems
Management with NETCONF-YANG- Developing Internet Of
Things -IoT Design Methodology

Need for IoT Systems Management
• https://www.digi.com/blog/post/what-is-iot-device-management
https://www.drpankajdadhich.com/2022/06/need-for-iot-
systems-management.html

IoT systems have complex software, hardware (sensors, actuators), network
resources, data collection, analysis services, communication protocols, and user
interfaces.
The need for managing IoT systems are:
1. Automating Configuration
2. Monitoring Operational & Statistical Data
3. Improved Reliability
4. System-Wide Configuration
5. Multiple System Configurations
6. Retrieving & Reusing Configurations

1. Automating Configuration
 Easy-to-use management capability to automation system configuration when a system
consists of multiple devices or nodes.
 Ensures all devices have the same configuration and variations or errors due to manual
configurations are avoided.
2. Monitoring Operational & Statistical Data:
 Operational data:- the system's operating parameters that are collected by the system at
runtime.
 Statistical data:- system performance (e.g. CPU and memory usage) data for fault diagnosis
or prognosis (forecasting).

3. Improved Reliability:
By validating the system configurations before use.
4. System-Wide Configuration:
 Each device is configured separately (either manual or automated).
 Used in system faults or undesirable outcomes.
 Ensures that the configuration changes are either applied to all devices or to none.
 In the failure, the configuration changes are rolled back.

5. Multiple System Configurations:
Some systems have multiple valid configurations according to different times or in certain
conditions.
6. Retrieving & Reusing Configurations:
 Help in reusing the configurations for other devices of the same type.
 Ensure that when a new device is added, the same configuration is applied.
 The management system can retrieve the current configuration from a device and apply
the same to the new devices.

There are several different steps involved in integrating a device into a network.
Provisioning-Provisioning modifies the device from its original
Authentication-Authentication is the process of confirming a device’s identity
Configuration-Configure any number of devices at one time
Control-you need to be able to control them remotely
Monitoring-Remote monitoring of your IoT devices
Diagnostics-troubleshoot and remediate issues quickly and efficiently.
Software Updates-software-defined attributes to manage their functionality
Maintenance-get alerts, and troubleshoot issues

Simple Network Management Protocol (SNMP)
If an organization has 1000 devices then to check all devices, one by one every day, are
working properly or not is a hectic task. To ease these up, Simple Network Management
Protocol (SNMP) is used.
SNMP is an application layer protocol that used to monitor the network, detect network
faults, and sometimes even used to configure remote devices.
The purpose of SNMP is to provide network devices, such as routers, servers and printers,
with a common language for sharing information with a network management system(NMS)

SNMP components:
There are 3 components of SNMP:
SNMP Manager:
 It is a centralized system used to monitor network. It is also known as Network
Management Station (NMS)
 The NMS will actively request agents to send updates at regular intervals.
 There are several free SNMP managers available, but they are typically limited in their
capabilities or the number of nodes they can support.

SNMP agent:
 It is a software management software module installed on a managed device. Managed
devices can be network devices like PC, routers, switches, servers, etc.
 Agent software runs on the hardware or service being monitored, collecting data about
disk space, bandwidth use and other important network performance metrics.
 When queried by the SNMP manager, the agent sends the requested information back to
the management system.
 An agent may also proactively notify the NMS if an error occurs.
 Most devices come with an SNMP agent pre-installed but it typically needs to be turned on
and configured.

Management Information Base:
MIB consists of information on resources that are to be managed. This information is
organized hierarchically. It consists of objects instances which are essentially variables.
This MIB database is a text file (.mib) that itemizes and describes all objects on a particular
device that can be queried or controlled using SNMP. Each MIB item is assigned an object
identifier (OID).
Each agent has its own MIB, which is a collection of all the objects that the manager can
manage. MIB is categorized into eight groups: system, interface, address translation, ip, icmp,
tcp, udp, and egp. These groups are under the mib object.

SNMP defines five types of messages: GetRequest, GetNextRequest,
SetRequest, GetResponse, and Trap.

GET Request: Generated by the SNMP manager and sent to an agent to obtain the value of a
variable, identified by its OID, in an MIB
GETNEXT Request: Sent by the SNMP manager to the agent to retrieve the values of the next
OID in the MIB's hierarchy.
SET Request: Sent by the SNMP manager to the agent to issue configurations or commands.
GET Response: Contains the values of the requested variables.
TRAP: An asynchronous alert sent by the agent to the SNMP manager to indicate a significant
event, such as an error or failure, has occurred.

Limitations of SNMP
 SNMP is stateless in nature and each SNMP request contains all the information to process
the request. The application needs to be intelligent to manage the device.
 SNMP is a connectionless protocol which uses UDP as the transport protocol, making it
unreliable as there was no support for acknowledgement of requests.
 MIBs often lack writable objects without which device configuration is not possible using
SNMP.
 It is difficult to differentiate between configuration and state data in MIBs.
 Retrieving the current configuration from a device can be difficult with SNMP.
 Earlier versions of SNMP did not have strong security features.

NETCONF
• Network Configuration Protocol (NETCONF) is a session-based network management protocol. NETCONF
allows retrieving state or configuration data and manipulating the configuration data on network devices.

NETCONF
• NETCONF works on SSH transport protocol.
• The Secure Shell (SSH) protocol is a method for securely sending commands to a computer over an
unsecured network.
• SSH uses cryptography to authenticate and encrypt connections between devices.
• Transport Layer Security (TLS) is a cryptographic protocol that protects Internet
communications. TLS replaced SSL in 1999
• Transport layer provides end-to-end connectivity and ensures reliable delivery of messages.
• NETCONF uses XML-encoded Remote Procedure Calls (RPCs) for framing request and response messages.
• Extensible Markup Language (XML) is a markup language that provides rules to define any data.
• The RPC layer provides a mechanism for encoding of RPC calls and notifications.
• NETCONF provides various operations to retrieve and edit configuration data from network devices.
• The Content Layer consists of configuration and state data which is XML-encoded.
• The schema of the configuration and state data is defined in a data modelling language called YANG.
• NETCONF provides a clear separation of the configuration and state data.
• The configuration data resides within a NETCONF configuration data store on the server.

NETCONF base operations
• The NETCONF protocol supports a set of low-level operations for
retrieving and managing device configuration information. The
operations are specified through XML elements, which are described
in the following table. NETCONF also supports additional operations
based on each device's capabilities.
• <get>. Retrieves all or part of the information about the running
configuration and device state.
• <get-config>. Retrieves all or part of the configuration information
available from a specified configuration datastore.
• <edit-config>. Submits all or part of a configuration to a target
configuration datastore.

NETCONF base operations
• <copy-config>. Creates or replaces a target configuration datastore
with the information from another configuration datastore.
• <delete-config>. Deletes a target configuration datastore, but only if
it's not running.
• <lock>. Locks a target configuration datastore, unless a lock already
exists on any part of that datastore.
• <unlock>. Releases a lock on a configuration datastore that was
previously locked through a <lock> operation.
• <close-session>. Requests the NETCONF server to gracefully
terminate an open session.
• <kill-session>. Forces a session's termination, causing current
operations to be aborted

YANG - Yet Another Next Generation
• YANG is a data modelling language used to model configuration and state data
manipulated by the NETCONF protocol
• YANG modules contain the definitions of the configuration data, state data, RPC calls
that can be issued and the format of the notifications.
• YANG modules define the data exchanged between the NETCONF client and server.
• A module comprises a number of 'leaf' nodes which are organized into a hierarchical
tree structure.
• The 'leaf' nodes are specified using the 'leaf' or 'leaf-list' constructs.
• Leaf nodes are organized using 'container' or 'list' constructs.
• A YANG module can import definitions from other modules.
• Constraints can be defined on the data nodes, e.g. allowed values.
• YANG can model both configuration data and state data using the 'config' statement.

YANG Module – Example
• This YANG module is a YANG version of the toaster
MIB.
• The toaster YANG module begins with the header
information followed by identity declarations which
define various bread types.
• The leaf nodes (‘toasterManufacturer’,
‘toasterModelNumber’ and toasterStatus’) are
defined in the ‘toaster’ container.
• Each leaf node definition has a type and optionally
a description and default value.
• The module has two RPC definitions (‘make-toast’
and ‘cancel-toast’).

IoT Systems Management with NETCONF-YANG
• Management System
• Management API
• Transaction Manager
• Rollback Manager
• Data Model Manager
• Configuration Validator
• Configuration Database
• Configuration API
• Data Provider API

IoT Systems Management with NETCONF-YANG

 Introduction
 Step 1: Purpose & Requirements Specification
 Step 2 :Process Specification
 Step 3 : Domain Model Specification
 Step 4 : Information Model specification
 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
Overview

IoT system design methodology
Introduction
 IoT Platform Methodology is aimed at IoT stakeholders such as IoT
product managers and solutions architects.
 The Primary goal of designing is to continuously develop IoT best
practices and make them available to the end user in the form of a
framework that is technology independent, reusable and open source.
 IoT systems contain multiple components and deployment tiers.
 There are ten IoT system levels
 Each level is suited for different applications and has different component
and deployment configurations.

Introduction
 The methodology described in this concept is based on the IoT Reference
model described with the specified following objectives.
o Provide a reference model of architecture based on: Interoperability
,Scalability and Security and Privacy.
o Provide guidelines to design IoT architecture with the definition of a
set of views.
o Provide a common language and concepts to improve communication
between partners means IoT Domain Model.

Introduction
• Purpose and requirements Specification
• Process Model Specification
• Domain Model Specification
• Information Model Specification
• Service Specifications
• IoT Level Specification
• Functional View Specification
• Operational View Specification
• Device and Component Integration
• Application Development
Steps involved in IoT system design methodology

Step 1: Purpose & Requirements Specification
 The first step in IoT System design methodology is to define the purpose
and requirements of the System.
 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.
 Applying this to an example of a Smart Home Automation System, the
purpose and requirements for the System may be described as follows:

Step 1: Purpose & Requirements Specification
 Purpose: To control lights remotely using web application.
 Behavior: Auto and manual modes.
 System Management Requirement: Remote monitoring and control
functions.
 DataAnalysis Requirement: local analysis of the data.
 Application Deployment Requirement: deployed locally on the device,
but should be accessible remotely.
 Security Requirement: basic user authentication.

Step 2: Process Specification
 The use cases of the IoT system are formally described and derived on the
Requirements specification specified in Step 1 of the design phase.
The process diagram for the home automation systems

Step 3: Domain Model Specification
 The Domain model should describe
o The main concepts, entities and objects
o define the attributes of the objects and relationships between objects.
o Provide an abstract representation of the concepts, objects and entities
in the IoT domain, independent of any specific technology or
platform.
o For the example of Home Automation System , The confined list of
entities, objects and concepts defined in the domain model are
Physical Entity, Virtual Entity, Device, Resource, Service

 Physical Entity
o identifiable entity in the e.g. a room, a light, a car etc.
o information of entity using sensors
o In the example physical entities involved are room in the home
 Virtual Entity
o Representation of the physical entity in the real world
o In example there is one virtual entity for the room to be monitored,
another for the appliance to be controlled.
 Device
o Devices provides a medium for interactions between physical entities
and virtual entities.
o Devices are used to gather information about physical entities e.g.
from sensors, perform actuation on physical entities using actuators.
o In example, Device is a single board a mini computer which has light
sensor and actuator attached to it.

 Resource
o Resources are of 2 types, “on-device” or “network-resources”.
o On-device resources are hosted on the device and include software
components
o Network resources include the software components that are available
in network.
o In the example, the on-device resource is the operating system that
runs on the single-board minicomputer.
 Service
o Services provide an interface for interacting with the physical entity.
o Services access the resources hosted on the device or the network.
o In the example, there are 3 services which are as follows
A service that sets mode to auto or manual, or retrieves the current
mode.
A service that sets the light appliance state to on/off, or retrieves
the current light state
A controller service that runs as a native service on the device

Step 4: Information Model specification
 Information model defines the structure of the information in the IoT
system.
 For example, attributes of Virtual Entities, relations etc but does not describe
the specifics of how information is being represented or stored.
 To define the information model, virtual entities are listed to define in the
domain model.
 In the example, there are two virtual entities, one is for the light appliance
and another is for the room.
The information model for the Home automation system example

Step 5: Service Specifications
 Service specifications define the services in the IoT System such as
Service types, Service inputs/output, Service endpoints, Service schedules,
Service preconditions and Service effects.
 From the Process specification and Information model, identify the states
and attributes. For each state and attribute define a service, these services
either change the state or attribute values or retrieve the current values
Deriving services from process specification and information model for home
IoT system
automation

Step 6: IoT Level Specification
 The IoT Levels are generally categorized at most 5 levels IoT Level-
1,2,3,4, 5.
 IoT Level-1: A level-1 IoT system contains single node that does the
operation of sensing and actuation, stores data, performs analysis
Deployment design of the home automation IoT system

• IoT Level-2: The Level-2 IoT system has a single node that performs
sensing and actuation. Data is stored in the cloud and the entire application
is cloud-based. Level-2 IoT systems are suitable for solutions where the
data involved is big, the primary analysis requirement is not intensive and
can be done locally itself.

 IoT Level-3: A level-3 IoT system has a single node and they are suitable
for solutions where the data involved is big and the analysis requirements
are computationally intensive.

 IoT Level-5: This system consists of multiple nodes placed in different
locations for monitoring.

Step-7 Functional view Specification
 The Functional View defines the functions of the IoT systems grouped into
various Functional Groups.
 Each Functional Group either provides functionalities for interacting with
instances of concepts defined in the Domain Model or gives information
related to these concepts.
 The Functional Group included in a Functional View include: Device,
Communication, Services, Management, Security, Application.

Step-7 Functional view Specification
 Device: The device FG contains devices for monitoring and control
 Communication: communicationAPI’s such as REST and Web socket
 Services: for device control, device monitoring, device discovery and data
publishing services.
 Management: to configure and manage IOT system.
 Security:Authentication,Authorization and data security
 Application: to control and monitor various aspects of the IOT system.

Step-8 Operational View Specification
 In this particular step, various options pertaining to the IoT system
deployment and operation are defined namely service hosting options,
storage options, device options, application hosting options etc.
 Devices: Computing Device is Raspberry Pi Light dependent resistor is
sensor Relay switch is actuator.
 Communication APIs: REST APIs
 Communication Protocols: Link Layer-802.11, Network
Layer- IPv4/IPv6, Transport layer-TCP, Application Layer-HTTP.
 Services: Controller Service- Hosted on device, implemented in Python
and it runs as a native service.
 Mode of service- REST-ful web service, hosted on device and it is
implemented with Django- REST Framework

Step-8 Operational View Specification
 State service- REST-ful web service, hosted on device, implemented with
Django-REST Framework.
 Application: Web Application- Django Web Application Application
Server- Django App Server Database Server- MySQL
 Security: Authentication: Web App, Database
 Authorization: Web App, Database
 Management: Application Management – Django App Management
Database Management- MySQL DB Management Devise Management-
Raspberry Pi devise Management.

Step-9 Device & Component Integration
 The ninth step in the IoT design methodology is the integration of the
devices and components. Considering the same example of Home
automation IoT system. The devices and components can be used in this
example may be Raspberry Pi minicomputer, LDR sensor and relay switch
actuator.

Step-10 Application developments
 Finally Developing IoT application is the important step in the IoT design
methodology. Figure 4-10 shows an exemplary way of interpreting an
application like Home Automation web application. This application
Home automation web application screenshot

Step-10 Application developments
Mapping functional groups to operational view for home automation system

Configuration of IoT devices - Systems managament

Recommended

Recommended

More Related Content

Similar to Configuration of IoT devices - Systems managament

Similar to Configuration of IoT devices - Systems managament (20)

Recently uploaded

Recently uploaded (20)

Configuration of IoT devices - Systems managament