DEPARTMENT

OF
ELECTRONICS & COMMUNICATION ENGINEERING

CLASS NOTES
of
UG - B.E. COURSE
IN

Introduction to Internet of Things

Course Code : 22ETC15H / 25H
(Emerging Technology Course – ETC)
(Module - 3 / Unit No. 3)
First Year B.E.
July to December 2022
Academic Year : 2022-23

Staff Incharges
Dr. Pavithra G., Dr. Sindhu Sree M.,
Dr. Ninu Rachel Phillips,
Padmavathi M., Likitha K. &
Dr. T.C. Manjunath, Ph.D. (IIT Bombay), Sr. Member IEEE, Chartered Engineer, Fellow IE, Fellow IETE

Dayananda Sagar College of Engineering

Shavigemalleshwara Hills, Kumaraswamy Layout,
Banashankari, Bangalore-560078, Karnataka
Tel : +91 80 26662226 26661104 Extn : 2731 Fax : +90 80 2666 0789
Web - http://www.dayanandasagar.edu Email : [email protected]
( An Autonomous Institute Affiliated to VTU, Approved by AICTE & ISO 9001:2008 Certified )
( Accredited by NBA, National Assessment & Accreditation Council (NAAC) with 'A' grade & NIRF Rated )

1
Course Title: Introduction to Internet of Things (IOT)
Course Code: 22ETC15H/25H CIE Marks 50
Course Type SEE Marks 50
(Theory / Practical ETC Total Marks 100
/ Integrated)
Teaching Hours/Week (L:T:P: S) 02:00:02:00 Exam Hours 03
Total Hours of Pedagogy 40 hours Credits 03
Teaching Department NT/Chem/Phys/Any QP setting NT/Chem/Phy
Engg. Branch s
Module-1 (8 hours of pedagogy)
Basics of Networking: Introduction, Network Types, Layered network models, Functional blocks of
IOT ecosystem, Applications of IoT devices
Emergence of IoT: Introduction, Evolution of IoT, Enabling IoT and the Complex
Interdependence ofTechnologies, IoT Networking Components
Module-2 (8 hours of pedagogy)
IoT Sensing and Actuation: Introduction, Sensors, Sensor Characteristics, Sensorial Deviations,
Sensing Types, Sensing Considerations, Actuators, Actuator Types, Actuator Characteristics.
Module-3 (8 hours of pedagogy)
IoT Processing Topologies and Types: Data Format, Importance of Processing in IoT, Processing
Topologies, IoT Device Design and Selection Considerations, Processing Offloading.
Module-4 (8 hours of pedagogy)
ASSOCIATED IOT TECHNOLOGIES
Cloud Computing: Introduction, Virtualization, Cloud Models, Service-Level Agreement in Cloud
Computing, Cloud Implementation, Sensor-Cloud: Sensors-as-a-Service., Introduction to Embedded
system and application(ARDUINO board)
IOT CASE STUDIES
Agricultural IoT – Introduction and Case Studies
Module-5 (8 hours of pedagogy)
IOT CASE STUDIES AND FUTURE TRENDS
Vehicular IoT – Introduction of Vehicular IoT, Healthcare IoT, Home automation, Smart energy
consumption and AI trained IoT devices – Case studies and IoT Analytics

2
 MODULE 3

IoT Processing Topologies and Types

1. Data Format

The Internet is a vast space where huge quantities and varieties of data are generated regularly
and flow freely. As of January 2018, there are a reported 4.021 billion Internet users
worldwide. The massive volume of data generated by this huge number of users is further
enhanced by the multiple devices utilized by most users. In addition to these data-generating
sources, non-human data generation sources such as sensor nodes and automated monitoring
systems further add to the data load on the Internet. This huge data volume is composed of a
variety of data such as e-mails, text documents (Word docs, PDFs, and others), social media
posts, videos, audio files, and images, as shown in Figure 1. However, these data can be
broadly grouped into two types based on how they can be accessed and stored:

1) Structured data and

2) Unstructured data.

Figure 1: The various data generating and storage sources connected to the Internet and the
plethora of data types contained within it

3
What is data?

Data is a distinct piece of information that is gathered and translated for some purpose. Data
can be available in different forms, such as bits and bytes stored in electronic memory,
numbers or text on pieces of paper, or facts stored in a person's mind. These data can be
broadly grouped into two types based on how they can be accessed and stored:

1) Structured data and

2) Unstructured data.

1.1 Structured data

The data which is to the point, factual, and highly organized is referred to as structured data.
It is quantitative in nature, i.e., it is related to quantities that means it contains measurable
numerical values like numbers, dates, and times. These are typically text data that have a pre-
defined structure. The structured data is shown in the Figure 2.

Figure 2 : Structured Data

It is easy to search and analyze structured data. Structured data exists in a predefined format.
Relational database consisting of tables with rows and columns is one of the best examples of
structured data. Structured data generally exist in tables like excel files and Google Docs

4
spreadsheets. The programming language SQL (structured query language) is used for
managing the structured data. Structured data is highly organized and understandable for
machine language. Common applications of relational databases with structured data include
sales transactions, Airline reservation systems, inventory control, and others.

1.2 Unstructured data

In simple words, all the data on the Internet, which is not structured, is categorized as
unstructured. These data types have no pre-defined structure and can vary according to
applications and data-generating sources. Some of the common examples of human-
generated unstructured data include text, e-mails, videos, images, phone recordings, chats,
and others. Some common examples of machine-generated unstructured data include sensor
data from traffic, buildings, industries, satellite imagery, surveillance videos, and others. This
is shown in the Figure 3.

Figure 3 : Unstructured data

Figure 4 : Structured data v/s Unstructured data

5
2. Importance of Processing in IoT

The vast amount and types of data flowing through the Internet necessitate the need for
intelligent and resourceful processing techniques. We first divide the data to be processed into
three types based on the urgency of processing: 1) Very time critical, 2) time critical, and 3)
normal.

Very time critical data: Data from sources such as flight control systems, healthcare, and other
such sources, which need immediate decision support, are deemed as very critical. These data
have a very low threshold of processing latency, typically in the range of a few milliseconds.

6
Time critical data: Data from sources that can tolerate normal processing latency are deemed
as time critical data. These data, generally associated with sources such as vehicles, traffic,
machine systems, smart home systems, surveillance systems, and others, which can tolerate a
latency of a few seconds fall in this category.

Normal data: Normal data can tolerate a processing latency of a few minutes to a few hours
and are typically associated with less data-sensitive domains such as agriculture,
environmental monitoring, and others.

3. Processing Topologies

The identification and intelligent selection of processing requirement of an IoT application are
one of the crucial steps in deciding the architecture of the deployment. A properly designed
IoT architecture would result in massive savings in network bandwidth and conserve
significant amounts of overall energy in the architecture while providing the proper and
allowable processing latencies for the solutions associated with the architecture.

So we can divide the various processing solutions into two large topologies:

1) On-site and

2) Off-site.

The off-site processing topology can be further divided into the following:

1) Remote processing and

2) Collaborative processing.

3.1 On-site processing

The on-site processing topology signifies that the data is processed at the source itself. This is
crucial in applications that have a very low tolerance for latencies. These latencies may result
from the processing hardware or the network (during transmission of the data for processing
away from the processor).

Applications such as those associated with healthcare and flight control systems (real time
systems) have a breakneck data generation rate. These additionally show rapid temporal

7
changes that can be missed (leading to catastrophic damages) unless the processing
infrastructure is fast and robust enough to handle such data.

Figure 5: Event detection using an on-site processing topology

Figure 5 shows the on-site processing topology, where an event (here, fire) is detected utilizing
a temperature sensor connected to a sensor node. The sensor node processes the information
from the sensed event and generates an alert. The node additionally has the option of
forwarding the data to a remote infrastructure for further analysis and storage.

3.2 Off-site processing

In the off-site processing topology, the sensor node is responsible for the collection and
framing of data that is eventually to be transmitted to another location for processing. Unlike
the on-site processing topology, the off-site topology has a few dedicated high-processing
enabled devices, which can be borrowed by multiple simpler sensor nodes to accomplish their
tasks. At the same time, this arrangement keeps the costs of large-scale deployments
extremely manageable.

In the off-site topology, the data from these sensor nodes (data generating sources) is
transmitted either to a remote location (which can either be a server or a cloud) or to multiple
processing nodes. Multiple nodes can come together to share their processing power in order
to collaboratively process the data (which is important in case a feasible communication
pathway or connection to a remote location cannot be established by a single node).

8
1. Remote processing

This is one of the most common processing topologies prevalent in present-day IoT solutions.
It encompasses sensing of data by various sensor nodes; the data is then forwarded to a remote
server or a cloud-based infrastructure for further processing and analytics. The processing of
data from hundreds and thousands of sensor nodes can be simultaneously offloaded to a
single, powerful computing platform; this results in massive cost and energy savings by
enabling the reuse and reallocation of the same processing resource while also enabling the
deployment of smaller and simpler processing nodes at the site of deployment. This setup
also ensures massive scalability of solutions, without significantly affecting the cost of the
deployment.

Figure 6 shows the outline of one such paradigm, where the sensing of an event is performed
locally, and the decision making is outsourced to a remote processor (here, cloud). However,
this paradigm tends to use up a lot of network bandwidth and relies heavily on the presence
of network connectivity between the sensor nodes and the remote processing infrastructure.

Figure 6: Event detection using an off-site remote processing topology

2. Collaborative processing

This processing topology typically finds use in scenarios with limited or no network
connectivity, especially systems lacking a backbone network. Additionally, this topology can
be quite economical for large-scale deployments spread over vast areas, where providing
networked access to a remote infrastructure is not viable. In such scenarios, the simplest
solution is to club together the processing power of nearby processing nodes and
collaboratively process the data in the vicinity of the data source itself. This approach also

9
reduces latencies due to the transfer of data over the network. It conserves bandwidth of the
network, especially ones connecting to the Internet.

Figure 7 : Event detection using a collaborative processing topology

Figure 7 shows the collaborative processing topology for collaboratively processing data
locally. This topology can be quite beneficial for applications such as agriculture, where an
intense and temporally high frequency of data processing is not required as agricultural data
is generally logged after significantly long intervals (in the range of hours). One important
point to mention about this topology is the preference of mesh networks for easy
implementation of this topology.

4. Device Design and Selection Considerations

The main consideration of minutely defining an IoT solution is the selection of the processor
for developing the sensing solution (i.e., the sensor node). The main factor governing the IoT
device design and selection for various applications is the processor. However, the other
important considerations are as follows.

• Size: This is one of the crucial factors for deciding the form factor and the energy
consumption of a sensor node. It has been observed that larger the form factor, larger is the
energy consumption of the hardware. Additionally, large form factors are not suitable for a
significant bulk of IoT applications, which rely on minimal form factor solutions (e.g.,
wearables)

10
• Energy: The energy requirements of a processor is the most important deciding factor in
designing IoT-based sensing solutions. Higher the energy requirements, higher is the energy
source (battery) replacement frequency. This principle automatically lowers the long-term
sustainability of sensing hardware, especially for IoT-based applications.

• Cost: The cost of a processor, besides the cost of sensors, is the driving force in deciding the
density of deployment of sensor nodes for IoT-based solutions. Cheaper cost of the hardware
enables a much higher density of hardware deployment by users of an IoT solution. For
example, cheaper gas and fire detection solutions would enable users to include much more
sensing hardware for a lesser cost.

• Memory: The memory requirements (both volatile and non-volatile memory) of IoT devices
determines the capabilities the device can be armed with. Features such as local data
processing, data storage, data filtering, data formatting, and a host of other features rely
heavily on the memory capabilities of devices. However, devices with higher memory tend to
be costlier for obvious reasons.

• Processing power: As covered in earlier sections, processing power is vital (comparable to

memory) in deciding what type of sensors can be accommodated with the IoT device/node,
and what processing features can integrate on-site with the IoT device. The processing power
also decides the type of applications the device can be associated with. Typically, applications
that handle video and image data require IoT devices with higher processing power as
compared to applications requiring simple sensing of the environment.

• I/O rating: The input–output (I/O) rating of IoT device, primarily the processor, is the
deciding factor in determining the circuit complexity, energy usage, and requirements for
support of various sensing solutions and sensor types. Newer processors have a meagre I/O
voltage rating of 3.3 V, as compared to 5 V for the somewhat older processors. This translates
to requiring additional voltage and logic conversion circuitry to interface legacy technologies
and sensors with the newer processors. Despite low power consumption due to reduced I/O
voltage levels, this additional voltage and circuitry not only affects the complexity of the
circuits but also affects the costs.

• Add-ons: The support of various add-ons a processor or for that matter, an IoT device
provides, such as analog to digital conversion (ADC) units, in-built clock circuits, connections
to USB and ethernet, inbuilt wireless access capabilities, and others helps in defining the
robustness and usability of a processor or IoT device in various application scenarios.

11
5. Processing Offloading

The processing offloading paradigm is important for the development of densely deployable,
energy-conserving, miniaturized, and cheap IoT-based solutions for sensing tasks. Figure 5
shows the typical outline of an IoT deployment with the various layers of processing that are
encountered spanning vastly different application domains—from as near as sensing the
environment to as far as cloud-based infrastructure. Starting from the primary layer of
sensing, we can have multiple sensing types tasked with detecting an environment (fire,
surveillance, and others). The sensors enabling these sensing types are integrated with a
processor using wired or wireless connections (mostly, wired). In the event that certain
applications require immediate processing of the sensed data, an on-site processing topology
is followed, similar to the one in Figure 5.

Figure 8 : The various data generating and storage sources connected to the Internet and the
plethora of data types contained within it

12
However, for the majority of IoT applications, the bulk of the processing is carried out
remotely in order to keep the on-site devices simple, small, and economical. Typically, for off-
site processing, data from the sensing layer can be forwarded to the fog or cloud or can be
contained within the edge layer. The edge layer makes use of devices within the local network
to process data that which is similar to the collaborative processing topology shown in Figure
8. The devices within the local network, till the fog, generally communicate using short-range
wireless connections. In case the data needs to be sent further up the chain to the cloud, long-
range wireless connection enabling access to a backbone network is essential. Fog-based
processing is still considered local because the fog nodes are typically localized within a
geographic area and serve the IoT nodes within a much smaller coverage area as compared to
the cloud. Fog nodes, which are at the level of gateways, may or may not be accessed by the
IoT devices through the Internet.

Finally, the approach of forwarding data to a cloud or a remote server, as shown in the
topology in Figure 8, requires the devices to be connected to the Internet through long-range
wireless/wired networks, which eventually connect to a backbone network. This approach is
generally costly concerning network bandwidth, latency, as well as the complexity of the
devices and the network infrastructure involved. So, data offloading is divided into three
parts:

1) offload location (which outlines where all the processing can be offloaded in the IoT
architecture),

2) offload decision making (how to choose where to offload the processing to and by how
much), and finally

3) offloading considerations (deciding when to offload).

5.1 Offload location

The choice of offload location decides the applicability, cost, and sustainability of the IoT
application and deployment. We distinguish the offload location into four types:

• Edge: Offloading processing to the edge implies that the data processing is facilitated to a
location at or near the source of data generation itself. Offloading to the edge is done to achieve
aggregation, manipulation, bandwidth reduction, and other data operations directly on an
IoT device .

13
• Fog: Fog computing is a decentralized computing infrastructure that is utilized to conserve
network bandwidth, reduce latencies, restrict the amount of data unnecessarily flowing
through the Internet, and enable rapid mobility support for IoT devices. The data, computing,
storage and applications are shifted to a place between the data source and the cloud resulting
in significantly reduced latencies and network bandwidth usage.

• Remote Server: A simple remote server with good processing power may be used with IoT-
based applications to offload the processing from resourceconstrained IoT devices. Rapid
scalability may be an issue with remote servers, and they may be costlier and hard to maintain
in comparison to solutions such as the cloud.

• Cloud: Cloud computing is a configurable computer system, which can get access to
configurable resources, platforms, and high-level services through a shared pool hosted
remotely. A cloud is provisioned for processing offloading so that processing resources can
be rapidly provisioned with minimal effort over the Internet, which can be accessed globally.
Cloud enables massive scalability of solutions as they can enable resource enhancement
allocated to a user or solution in an on-demand manner, without the user having to go through
the pains of acquiring and configuring new and costly hardware.

5.2 Offload decision making

The choice of where to offload and how much to offload is one of the major deciding factors
in the deployment of an offsite-processing topology-based IoT deployment architecture. The
decision making is generally addressed considering data generation rate, network bandwidth,
the criticality of applications, processing resource available at the offload site, and other
factors. Some of these approaches are as follows.

• Naive Approach: This approach is typically a hard approach, without too much decision
making. It can be considered as a rule-based approach in which the data from IoT devices are
offloaded to the nearest location based on the achievement of certain offload criteria.
Although easy to implement, this approach is never recommended, especially for dense
deployments, or deployments where the data generation rate is high or the data being
offloaded in complex to handle (multimedia or hybrid data types). Generally, statistical
measures are consulted for generating the rules for offload decision making.

• Bargaining based approach: This approach, although a bit processing-intensive during the
decision-making stages, enables the alleviation of network traffic congestion, enhances service

14
QoS (quality of service) parameters such as bandwidth, latencies, and others. At times, while
trying to maximize multiple parameters for the whole IoT implementation, in order to provide
the most optimal solution or QoS, not all parameters can be treated with equal importance.
Bargaining based solutions try to maximize the QoS by trying to reach a point where the
qualities of certain parameters are reduced, while the others are enhanced. This measure is
undertaken so that the achieved QoS is collaboratively better for the full implementation
rather than a select few devices enjoying very high QoS. Game theory is a common example
of the bargaining-based approach. This approach does not need to depend on historical data
for decision making purposes.

• Learning based approach: Unlike the bargaining-based approaches, the learning-based

approaches generally rely on past behaviour and trends of data flow through the IoT
architecture. The optimization of QoS parameters is pursued by learning from historical
trends and trying to optimize previous solutions further and enhance the collective behaviour
of the IoT implementation. The memory requirements and processing requirements are high
during the decision-making stages. The most common example of a learning-based approach
is machine learning.

5.3 Offloading considerations

There are a few offloading parameters which need to be considered while deciding upon the
offloading type to choose. These considerations typically arise from the nature of the IoT
application and the hardware being used to interact with the application. Some of these
parameters are as follows.

• Bandwidth: The maximum amount of data that can be simultaneously transmitted over the
network between two points is the bandwidth of that network. The bandwidth of a wired or
wireless network is also considered to be its data-carrying capacity and often used to describe
the data rate of that network.

• Latency: It is the time delay incurred between the start and completion of an operation. In
the present context, latency can be due to the network (network latency) or the processor
(processing latency). In either case, latency arises due to the physical limitations of the
infrastructure, which is associated with an operation. The operation can be data transfer over
a network or processing of a data at a processor.

• Criticality: It defines the importance of a task being pursued by an IoT application. The
more critical a task is, the lesser latency is expected from the IoT solution. For example,

15
detection of fires using an IoT solution has higher criticality than detection of agricultural field
parameters. The former requires a response time in the tune of milliseconds, whereas the latter
can be addressed within hours or even days.

• Resources: It signifies the actual capabilities of an offload location. These capabilities may
be the processing power, the suite of analytical algorithms, and others. For example, it is futile
and wasteful to allocate processing resources reserved for real-time multimedia processing
(which are highly energy-intensive and can process and analyze huge volumes of data in a
short duration) to scalar data (which can be addressed using nominal resources without
wasting much energy).

• Data volume: The amount of data generated by a source or sources that can be
simultaneously handled by the offload location is referred to as its data volume handling
capacity. Typically, for large and dense IoT deployments, the offload location should be
robust enough to address the processing issues related to massive data volumes.

Introduction to basics of Arduino

Definition :

Arduino is a prototype platform (open-source) based on easy-to-use hardware and software.

It consists of a circuit board, which can be programmed (referred to as a microcontroller) and
an open source software called Arduino IDE (Integrated Development Environment), which
is used to write and upload the computer code to the physical board.

Hardware Description :

The Arduino Uno is a microcontroller board based on the ATmega328. It has 14 digital
input/output pins, 6 analog inputs, a 16 MHz crystal oscillator, a USB connection, a power
jack, memory and a reset button.

Programming basic Syntax :

The arduino code is written in a simple programming language similar to C and C++. The
following are the syntax and its respective condition description.

16
1. Brackets

There are two types of brackets used in the Arduino coding, 1) Parentheses ( ) and 2) Curly
Brackets { }

Parentheses ( )

The parentheses brackets are the group of the arguments, such as method, function, or a
code statement. These are also used to group the math equations.

Curly Brackets { }

The statements in the code are enclosed in the curly brackets. We always require closed
curly brackets to match the open curly bracket in the code or sketch.

Open curly bracket- ' { '

Closed curly bracket - ' } '

2. Line Comment

There are two types of line comments, which are listed below:

● Single line comment - The text that is written after the two forward slashes are
considered as a single line comment. The compiler ignores the code written after the
two forward slashes.

● Multi-line comment - The Multi-line comment is written to group the information for
clear understanding. It starts with the single forward slash and an asterisk symbol (/
*). It also ends with the / *.

17
Programming LED Blinking :

void setup ()

pinMode ( 13, OUTPUT); // to set the OUTPUT mode of pin number 13.

void loop ()

digitalWrite (13, HIGH);

delay (4000); // 4 seconds = 4 x 1000 milliseconds

digitalWrite (13, LOW);

delay (1500); // 1.5 seconds = 1.5 x 1000 milliseconds

A. pinMode ( )

The specific pin number is set as the INPUT or OUTPUT in the pinMode () function.

The Syntax is: pinMode (pin, mode)

Where,

pin: It is the pin number. We can select the pin number according to the requirements.

Mode: We can set the mode as INPUT or OUTPUT according to the corresponding pin
number.

B. digitalWrite( )

The digitalWrite ( ) function is used to set the value of a pin as HIGH or LOW.

Where,

HIGH: It sets the value of the voltage. For the 5V board, it will set the value of 5V, while for
3.3V, it will set the value of 3.3V.

LOW: It sets the value = 0 (GND).

If we do not set the pinMode as OUTPUT, the LED may light dim.

18
The syntax is: digitalWrite( pin, value HIGH/LOW)

C. delay ( )

The delay () function is a blocking function to pause a program from doing a task during the
specified duration in milliseconds.

For example, - delay (2000)

Where, 1 sec = 1000 millisecond

Hence, it will provide a delay of 2 seconds.

Case Study : Arduino board is shown in the Figure 9 along with its specifications.

Figure 9 Arduino board

Pin 1 : Power USB

Arduino board can be powered by using the USB cable from your computer. All you need to
do is connect the USB cable to the USB connection (1)

Pin 2 : Power (Barrel Jack)

Arduino boards can be powered directly from the AC mains power supply by connecting it
to the Barrel Jack (2)

19
Pin 3 : Voltage Regulator

The function of the voltage regulator is to control the voltage given to the Arduino board and
stabilize the DC voltages used by the processor and other elements.

Pin 4 :Crystal Oscillator

The crystal oscillator helps Arduino in dealing with time issues. It helps to calculate the time
and the crystal frequency is 16,000,000 Hertz or 16 MHz.

Pin 5-17 : Arduino Reset

This pin is used to reset the whole system. It induces two modes

1) Reset button on the board and

2) External device reset to the Arduino board.

Pin 6-9 : Pins (3.3, 5, GND, Vin)

3.3V (6) − Supply 3.3 output volt

5V (7) − Supply 5 output volt

GND (8)(Ground) − There are several GND pins on the Arduino, any of which can be used to
ground your circuit.

Vin (9) − This pin also can be used to power the Arduino board from an external power source,
like AC mains power supply.

Pin 10 : Analog pins

The Arduino UNO board has five analog input pins A0 through A5. These pins can read the
signal from an analog sensor like the humidity sensor or temperature sensor and convert it
into a digital value that can be read by the microprocessor.

Pin 11 : Main microcontroller

Each Arduino board has its own microcontroller (11). You can assume it as the brain of your
boar

Pin 12 : ICSP pin

ICSP (In-Circuit Serial Programming) pins are for bypassing the USB port and interfacing the
Arduino directly as a serial device. This port is necessary to re-boot. Load your chip if it
corrupts and can no longer be connected to your computer

20
Pin 13 : Power LED indicator

This LED should light up when you plug your Arduino into a power source to indicate that
your board is powered up correctly. If this light does not turn on, then there is something
wrong with the connection.

Pin 14 : TX and RX LEDs

On your board, you will find two labels: TX (transmit) and RX (receive). They appear in two
places on the Arduino UNO board. First, at the digital pins 0 and 1, to indicate the pins
responsible for serial communication. Second, the TX and RX led (13). The TX led flashes with
different speed while sending the serial data. The speed of flashing depends on the baud rate
used by the board. RX flashes during the receiving process.

Pin 15 : Digital I/O

The Arduino UNO board has 14 digital I/O pins (15) (of which 6 provide PWM (Pulse Width
Modulation) output. These pins can be configured to work as input digital pins to read logic
values (0 or 1) or as digital output pins to drive different modules like LEDs, relays, etc. The
pins labeled “~” can be used to generate PWM.

Pin 16 : AREF

AREF stands for Analog Reference. It is sometimes used to set an external reference voltage
(between 0 and 5 Volts) as the upper limit for the analog input pins.

21
 Vision & Mission of the Institute

Vision:
 To impart quality technical education with a focus on Research and Innovation emphasizing
on Development of Sustainable and Inclusive Technology for the benefit of society.

Mission:
 To provide an environment that enhances creativity and Innovation in pursuit of Excellence.
 To nurture teamwork in order to transform individuals as responsible leaders and
entrepreneurs.
 To train the students to the changing technical scenario and make them to understand the
importance of sustainable and inclusive technologies.

Vision & Mission of the Department

Vision :
 To achieve continuous improvement in quality technical education for global competence with
focus on industry, societal needs, research and professional success.

Mission:
 Offering quality education in Electronics and Communication Engineering with effective
teaching learning process in multidisciplinary environment.
 Training the students to take-up projects in emerging technologies and work with team spirit.
 To imbibe professional ethics, development of skills and research culture for better placement
opportunities.

Program Education Objectives

After four years, the students will be
PEO1: Successful in industry, academia, or entrepreneurship as a result of a strong teaching
learning process, with keen interest in pursuing higher studies in various domains.
PEO2: Capable of leading technological and managerial projects for serving industry and society
with knowledge of Electronics and Communication Engineering.
PEO3: Competent professional capable of adapting to changing technological scenarios and
societal needs, with expertise in relevant domains.
Program Specific Outcomes

PSO1 : Design, develop and integrate electronic circuits and systems using current practices and
standards.
PSO2 : Apply knowledge of hardware and software in designing Embedded and Communication
systems.

22