IoT using M2M Communication with the OSI Reference Model

Abstract

Machine to Machine (M2M) communication refers to technologies that allow communication through wireless and wired systems with other devices of the same type. M2M uses the OSI reference model to communicate between the devices.

In this document, we will present an overview of M2M communication over a wired network-based motor PID controller. This experiment is considered as IoT using M2M (internet of things), as the motor device is controlled via ethernet-based communication.

In this document, details on the network configuration for multihoming, firewall configuration, and route setup between different LANs (local area network), are discussed.

Introduction

A brief overview of M2M systems and IoT

"IOT" can mean several things including Machine to Machine (M2M) communications. In this document, we focus on M2M over wired networks as a form of IoT, which in turn uses the OSI reference model as a networking framework for communication between devices.

M2M refers to those solutions that allow communication between devices of the same type and unique applications via wired or wireless or both types of communication networks. M2M solutions allow end-users to collect data, such as temperature or inventory levels, on system events. Usually, M2M is implemented to improve efficiency, minimize costs, and increase protection or safety. M2M applications can be seen in the form of remote monitoring, controlling of assets from remote, etc.

Remote device connectivity has been the focus in enterprise scenarios such as connected vending machines, connected laundry machines, and dryers (circuit laundry) or point-of-sale terminals for online credit/debit card transactions.

Commonly implemented systems and objects in the IoT include an embedded computer or microprocessor that can be reached through any connectivity mechanism, usually using wired/wireless connections. The goal of the IoT is to bridge the distance between objects in the natural world, "things" and their abstract representation in information systems.

The IoT has two attributes:

1. it is an Internet application and
2. it deals with device information (things).

"The word Internet of Things was invented and used for the first time by 'Kevin Ashton' over a decade ago. The 'Things' are often referred to as 'objects,' 'devices,' 'end nodes,' 'remotes,' or 'remote sensors,' to name only a few widely used words"
- (Minoli, Daniel, 1952–Building the internet of things (IoT) with IPv6 and MIPv6 / Daniel Minoli).

In this document, we will be presenting the M2M IoT project, in which devices/computers are connected from different networks (local area network-LAN) over ethernet (M2M) and a DC motor connected to one of these devices in the network, which represents a "thing" in IoT.

Aims and Objectives

Aims of this experiment:

1. Part I of the experiment is to establish network connections between the computer devices (RaspberryPi's) present in different LANs. Configure these computers with IPv4 IP addresses and set IP routing between these devices and to the worldwide web. The aim is to determine which gateways to use for routing the packets between different LANs.

2. Part II of the experiment is to connect a DC motor to any one of the above computers or host in LAN (Local area network) and control the motor ("thing" as part of IoT terminology), programmatically using PID controller technique.

Post completion of part 1, i.e., establishing connectivity and network configurations changes, the following objectives must be achieved:

1. Capture the latency and throughput between different LAN devices.

2. Design and develop a "C" program to capture the feedback returned by the motor encoder and use it as an input to the PID controller program. The name of this "C" program is "encoder".

3. Design and develop a "C" program to take encoder data as input, returned by the encoder program, and perform PID calculations using the encoder feedback data to stabilize the motor rotation. The name of this "C" program is "controller".

4. Test the motor functionality by executing both the software programs in the same device, where the DC motor is connected. Also, test the software programs by connecting the DC motor to a different LAN computer host. Capture the magnitude data and plot the graph and analyze data in both scenarios.

5. Understand the concepts of PID controller techniques and their possible applications.

6. Capture network packets using the "tcpdump" command and analyze the data of the packet.

7. Login and logout of the computers in the network, using the "ssh" command. Also, create a private and public key using the "ssh-keygen" command and copy the public key to other computers in the network to login without using a password.

Background on Hardware and Software used

Hardware details:

- RigPi Device – RaspberryPi computers are used as a network host device. These devices are configured as gateways, as well as hosts in the network, using multihoming concepts (please check appendix-1 section for more details).

- DC Motor – DC motor is used as an IoT device, which will be connected to any one of the RigPi devices in the network.

- Driver Board – Electronic board used to provide power and control the DC motor (See Image 2 in this document).

Software details:

- Operating System in RigPi devices - Linux flavored operating systems are used in the RigPi devices.

- C Programming – This programming language is used to develop software programs.

- The editor used – vi editor to write/edit the "C" Program.

- Network Linux commands - ssh, ping, netstat, nslookup, route, iptables, ifconfig.

- GNUPlot - To plot the graph using output data.

Design Specification of Network

"The following diagram provides the details on the LAN design and the corresponding IP addresses for the devices in each network" (from coursework lecture notes).

Diagram-2 – Network Design

In the above diagram, RigPi-A, RigPi-B, RigPi-C, and RigPi-D are all "RaspberryPi" hardware devices running Linux flavored operating system. Their physical LAN connections are depicted as shown in the above diagram. It should be noted that RigPi-A acts as a master device also known as "ManagerPi" and is used to login and logout of other RigPi devices using the SSH command.

These RigPi-X devices must be configured to be part of LAN-1, LAN-2, and LAN-3 networks.

The following table represents, which RigPi device falls under which LAN and its associated IP addresses. Also, note that these network computers will be configured as multihoming devices on a single network interface card, and the IP addresses used are IPv4 Class C addresses.

LAN Number	Devices	IP Addresses
LAN-1	RigPi-A	192.168.23.1
LAN-1	RigPi-B	192.168.23.2
LAN-2	RigPi-B	192.168.132.2
LAN-2	RigPi-C	192.168.132.3
LAN-3	RigPi-C	192.168.133.3
LAN-3	RigPi-D	192.168.133.4

Table 1 – LAN Device IP addresses

Why multihoming?

The hardware device/computer used in this coursework is "RaspberryPi". This device has only one network/LAN interface card. Since we need to have multiple IP addresses associated with each host (as shown in the LAN design specification section), we are using a multihoming concept, where one network interface card can be associated with multiple IP addresses.

Experiments

Configuring RigPi-X Devices with IP addresses

The RigPi devices are running Linux flavored operating system; hence the network interface can be configured with IP addresses as follows:

1. Edit the /etc/network/interfaces file with appropriate IP addresses, mention as per the above diagram/table.

2. Add appropriate hostname entry in the /etc/hosts file to resolve the localhost name.

3. Add entry into /etc/resolv.conf with appropriate domain details.

IP address configuration for the device - RigPi-B

Edit /etc/network/interfaces file with the following IP addresses in it. Please notice that there are two iface defined in the file:

1. eth0:0

2. eth0:1

The following lines correspond to the configuration of multihoming on one network interface. On eth0:0, we have 192.168.23.2 defined and on eth0:1, we have 192.168.132.2.

Add following lines into /etc/resolv.conf file, for www connectivity.

Add "MyRigPiB" hostname into /etc/hosts file, for localhost resolution:

IP address configuration for the device - RigPi-C

Like RigPi-B, add the following lines into the /etc/network/interfaces file to configuration multihoming on one network interface. On eth0:0, we have 192.168.132.3 defined and on eth0:1, we have 192.168.133.3.

Add following lines into /etc/resolv.conf file, for www connectivity.

Add "MyRigPiC" hostname into /etc/hosts file, for localhost resolution:

IP address configuration for the device - RigPi-D

Edit /etc/network/interfaces file with the following IP addresses in it. It could be noticed that this device is not configured for multihoming. Since it is the last device in Network 3 or LAN-3.

Add "MyRigPiD" hostname into /etc/hosts file, for localhost resolution:

Add following lines into /etc/resolv.conf file, for www connectivity.

Reachability of all devices in Network

From Diagram-2, it could be noticed that RigPi-D can communicate to all devices in the LAN-

2 and LAN-3, as the configured gateway to this device is RigPi-C i.e., IP address

"192.168.133.3", however, the response from the RigPi-A and RigPi-B computers will not be received, as there is no return path from LAN-1 to LAN-3, therefore RigPi-A and RigPi-B cannot communicate to RigPi-D. Therefore, a network path must be added manually in the RigPi-B device, so that devices in LAN-1 i.e., RigPi-A and RigPi-B can communicate to RigPi-D computer in LAN-3.

The network path into the routing table can be added manually by using the "route" command in Linux operating system. Executing the following command as superuser (sudo) will add the network path into the routing table.

route add -net 192.168.133.0/24 gw 192.168.132.3

Also, firewall rules have to be added to the host RigPi-B, to receive and forward the packets in the network. i.e., from network 192.168.23.0/23 to network 192.168.133.0/24.

Firewall rules can be added using the "iptables" command as superuser (sudo). Executing the following command will add the firewall rule.

iptables -v -A FORWARD -s 192.168.23.0/24 -d 192.168.133.0/24 -j ACCEPT

By running the above two commands all the computers/hosts can communicate with each other in the network. The connectivity can be tested by using the "ping" command. Also, these computer hosts can communicate to the outside world i.e., internet/www through gateway "192.168.1.1", which are connected to ManagerPi/RigPi-A device.

Performance Metrics

The latency between LAN Devices

The following table shows the latency between different computers in the network. The data shown in Table-2 are calculated on an average time for transmitting and receiving 10 packets in the network.

Source Device Destination Device Latency in milliseconds (avg)

ManagerPi – 192.168.23.1	RigPi-B – 192.168.23.2 (LAN 1)	0.627
ManagerPi – 192.168.23.1	RigPi-B – 192.168.132.2 (LAN 2)	0.608
ManagerPi – 192.168.23.1	RigPi-C – 192.168.132.3 (LAN 2)	1.110
ManagerPi – 192.168.23.1	RigPi-C – 192.168.133.3 (LAN 3)	1.072
ManagerPi – 192.168.23.1	RigPi-D – 192.168.133.4	1.595
RigPi-B – 192.168.23.2 (LAN 1)	Manager Pi – 192.168.23.1	0.684
RigPi-B – 192.168.23.2 (LAN 1)	RigPi-C – 192.168.132.3 (LAN 2)	0.569
RigPi-B – 192.168.23.2 (LAN 1)	RigPi-C – 192.168.133.3 (LAN 3)	0.564
RigPi-B – 192.168.23.2 (LAN 1)	RigPi-D – 192.168.133.4 (LAN 3)	1.012
RigPi-B – 192.168.23.2 (LAN 1)	RigPi-B – 192.168.132.2 (LAN 2)	0.108
RigPi-B – 192.168.132.2 (LAN 2)	ManagerPi – 192.168.23.1	0.674
RigPi-B – 192.168.132.2 (LAN 2)	RigPi-C – 192.168.132.3 (LAN 2)	0.565
RigPi-B – 192.168.132.2 (LAN 2)	RigPi-C – 192.168.133.3 (LAN 3)	0.583
RigPi-B – 192.168.132.2 (LAN 2)	RigPi-D – 192.168.133.4 (LAN 3)	1.023
RigPi-B – 192.168.132.2 (LAN 2)	RigPi-B – 192.168.23.1 (LAN 1)	0.691
RigPi-C – 192.168.132.3 (LAN 2)	ManagerPi – 192.168.23.1	1.182
RigPi-C – 192.168.132.3 (LAN 2)	RigPi-B – 192.168.23.2 (LAN 1)	0.584
RigPi-C – 192.168.132.3 (LAN 2)	RigPi-B – 192.168.132.2 (LAN 2)	0.575
RigPi-C – 192.168.132.3 (LAN 2)	RigPi-D – 192.168.133.4 (LAN 3)	0.560
RigPi-C – 192.168.132.3 (LAN 2)	RigPi-C – 192.168.133.3 (LAN 3)	0.132
RigPi-D – 192.168.133.4	ManagerPi – 192.168.23.1	1.641
RigPi-D – 192.168.133.4	RigPi-B – 192.168.23.2 (LAN 1)	1.051
RigPi-D – 192.168.133.4	RigPi-B – 192.168.132.2 (LAN 2)	1.018
RigPi-D – 192.168.133.4	RigPi-C – 192.168.132.3 (LAN 2)	0.561

RigPi-D – 192.168.133.4	RigPi-C – 192.168.133.3 (LAN 3)	0.559
RigPi-C – 192.168.133.3 (LAN 3)	ManagerPi – 192.168.23.1	1.202
RigPi-C – 192.168.133.3 (LAN 3)	RigPi-B – 192.168.23.2 (LAN 1)	0.564
RigPi-C – 192.168.133.3 (LAN 3)	RigPi-B – 192.168.132.2 (LAN 2)	0.573
RigPi-C – 192.168.133.3 (LAN 3)	RigPi-D – 192.168.133.4 (LAN 3)	0.562
RigPi-C – 192.168.133.3 (LAN 3)	RigPi-C – 192.168.132.3 (LAN 3)	0.120

Table 2- Latency data

between different LAN devices

Throughput between devices in different LAN??????

Analysis of data packets??????

Login into RigPi devices without a password

To login into RigPi-B, RigPi-C, and RigPi-D devices we use RigPi-A, also known as "ManagerPi", which already is configured with required connectivity details. Therefore, from "ManagerPi" one can log in to other RigPi-X devices without using the password.

The user id that could be used to login into RigPi-X devices in this experiment is "pi". The software program that could be used to login from machine to machine is SSH and the command that could be used in Linux is "ssh -l userid hostname", where -l specifies the user id to be used to login into the remote computer.

One can generate the public and private SSH keys and sync the public SSH-Key with other remote hosts in the network. By copying the public ssh keys to the remote host, the key will be added to the authorized keys file on the remote computer for that user. Post copying the public ssh key to the remote device, the user can log in to the remote host without using a password. The authorized_key file will be placed inside the .ssh folder present in the user's home directory. This directory should have restricted permissions, otherwise, someone may gain access to the remote host by adding their key into the authorized_key file.

Command to generate the public and private ssh key:

ssh-keygen

Command to copy the public key to the remote host/machine is:

ssh-copy-id userid@hostname

Discussion

"Ping" command is used to capture the latency data between network computers.

It is evident from the above latency table, that the RigPi-D computer has higher latency to reach the computers/hosts in LAN-1 i.e., Rig-A. Computers in LAN-2 have less latency to reach computers in LAN-1 and LAN-3 networks.

Therefore, connecting the encoder part of the DC motor to the RigPi-D host in the network will have an impact on the performance. Also, there may be other delays such as software programs itself to transmit and receive data in the network.

Design of M2M Device Communication Framework

The M2M device communication framework is illustrated in this experiment, by connecting a DC motor to a host/device in the network. The details on how a DC motor could be controlled by a remote host using the IP address of the host will be discussed later in this document. The protocol used in this M2M experiment is TCP/IP and IPv4 IP Class C addresses. It is important at this point to understand some details on the DC motor (thing in IoT) and its functionality to design the communication framework between the network host/computer and the DC motor.

Components of DC motor – Thing in IoT

The DC motor consists of two parts, the first part is the DC motor shaft and the second one is the encoder, which is connected to the shaft. The purpose of the encoder is to capture and calculate the number of rotations of the shaft. The rotational frequency data is fed back as a feedback input to the software program, which uses this data to perform calculations to control the speed of the DC motor shaft to the desired level.

Internal details of the encoder portion of the DC motor are shown in the below diagram (Image 1). There is a disk, in which 500 cut slots are present. The light emitted by the LED is flashed onto the photodiodes through cut slots present on the disk. Photodiodes are present on the right side of the disk and LED on the left side of the disk. These photodiodes generate the signal pulse when they receive the flash of the LED. For one complete rotation of the disk wheel, 500 pulses are generated, which could be considered as a frequency of 500Hz.

Image 1 - Internals of DC motor encoder

Source – Lecture videos

DC motor connection to M2M - IoT

DC motor is connected to the RigPi-X host through the serial port RS-232 via driver board

(Please refer to Image 2). The motor rotational speed can be controlled by sending commands to the serial port from the RigPi-X host. The encoder part of the DC motor is connected to the GPIO pins (general purpose IO pins) of the RigPi-X host. The GPIO pins used in this case are GPIO-9 and GPIO-10.

Command used to control the speed of DC motor through RigPi-X host

§ echo 770 1\\ > /dev/serial0

It should be noted that the value 737 is zero, which means outputting value 737 to the serial port will stop the motor shaft.

If the value is greater than 737, the motor shaft will start rotating clockwise direction.  echo 800 1\\ > /dev/serial0

If the given value is less than 737, then the shaft starts rotating in the anti-clockwise direction.

§ echo 600 1\\ > /dev/serial0

Image 2- DC motor connected to RigPi-X host

Experiment

The step response data over time is plotted onto a graph using "Gnuplot" software. This graph is used to analyze and tune the PID coefficients. If the PID coefficient values are set high the gain generated is high, which might make the control system unstable. It could be observed in the graph that there is an overshoot in the initial phase due to high gain. Also, there are fluctuations in output over time. Therefore, the coefficients of the PID algorithm must be tuned to produce a stable output and reduce noise. The PID coefficients used to produce these data are as follows: Kp=10, Ki=3, Kd=2.5, and Km=0.08.

The X-axis represents time in milliseconds and Y-axis offset magnitude value to the DC motor.

Control system step response graph over time.

Control System Specification

Control System in the experiment is designed based on the closed-loop feedback system. The system collects the rotational frequency data from the encoder part of the DC motor and passed it as a feedback input to the controller process for corrective measures. A general block diagram of the closed-loop system is given below (Image 3):

Image 3 - Closed Loop System

The above closed-loop system has two components and is Controller and Feedback blocks. They are represented in rectangular boxes connected by arrows showing their relation as inputs and outputs.

In the above system, the output of the controller is taken by the Feedback block via sensor and fed into the comparator, which generates the error value based on the input and feedback data. Consider a value setpoint, which is the expected or the desired output value to make the control system stable. If the output value of the controller is not equal to the setpoint value, the comparator will produce a higher error value based on the feedback data received from the feedback block. This error value is fed back into the controller block to perform corrective calculations to produce a higher output value to bring the control system to a stable state. This process continues indefinitely in a loop to produce and maintain the desired output value to make the control system stable. When the system attains stability the controller output value will be equal to or approximately equal to the setpoint value.

In our experiment, the Closed Loop Control System consists of the following components:

1. The software program "Controller", details are provided in the analysis section.

2. The software program "Encoder", details are provided in the analysis section.

3. DC motor, connected to the Computer RigPi-X via driver hardware.

4. RigPi-X host/computer connected to a network.

Architecture diagram of the Control System

Image 3 – Control System Architecture, Source – Module lecture video

Analysis of Control System

In the above architecture, there are four blocks and the details of these blocks are provided in this section.

The functionality of each block in the Control System architecture diagram is as follows:

1. "Controller" software process: This program controls the speed of the DC motor shaft; this is achieved by taking the feedback input from the encoder program. The calculation to generate the desired setpoint value is done using the "PID" (Proportional, Integral, and Differential) algorithm. The controller program is executed on the RigPi-X computer/host in the network to which the DC motor driver board is connected via serial port (RS-232). The serial port on this host must be configured to output the PID data to the driver board, this in-turn drives the DC motor.

2. "Encoder" software process: The encoder software program polls the signal data from GPIO pins 9 and 10 on the RigPi-X host/computer, to capture the encoder events from the DC motor. The signal data is accumulated for a period of 20 milliseconds and sent back to the Controller program. This program will be executed on the RigPi-X host to which the DC motor's encoder part is connected.

3. Hardware RigPi-X computer: This is a "RaspberryPi" computer connected to the network. If the encoder and controller programs are running on different RigPi-X hosts, then they use the network connectivity between these RigPi computers to communicate the feedback data in the closed-loop system.

There are many ways to achieve connectivity between programs running in a network environment. Two such possible methods of connectivity between the controller and encoder programs are provided in the control system implementation section.

Implementation - Components of the Control System

In this section, we will discuss the implementation of each component of the Control System in detail.

Controller Program

This program uses the PID controller algorithm to calculate the desired setpoint value.

PID controller coefficients are Kp, Ki, and Kd.

Kp – Coefficient for Proportional value and is set to 8 in this experiment.

Ki – Coefficient for Integral value and is set to 1.3 in this experiment.

Kd – Coefficient for Differential value and is set to 2 in this experiment.

Km – Coefficient for motor friction and is set to 0.008 in this experiment.

Details on PID algorithm

Since the controller program implements the PID control algorithm, it is important to understand the basics of the PID controller algorithm and how it helps in achieving the stability of the control system. This algorithm is based on three components and is

Proportional, Integral, and Differential (PID) values. These values are summed up to produce the gain.

The mathematical form of PID:

The overall control function in the time domain is given as:

Where Kp, Ki, and Kd are termed as coefficients for Proportional, Integral, and Derivative terms respectively. Also, denoted as "P", "I", and "D".

- Proportional term – related to the present value of e(t)

- Integral term – related to the history of e(t)

- Derivative term – related to the velocity of e(t)

Proportional Response:

Only the difference between the setpoint and the process variable depends on the proportional factor. This distinction is known as the error. The ratio of output response to the error signal is determined by the proportional gain (Kp). For example, a proportional gain of 10 will produce a proportional response of 100, if the error term has a magnitude of 15. The speed of the control system response would be improved by increasing the proportional gain. However, the process variable will begin to oscillate if the proportional gain is too high. The oscillations will become greater if Kp is further increased and the system will become unstable.

Integral Response:

In time, the integral component sums up the error term. The outcome is that the integral variable will be slowly increased by even a small error term. If the error is not zero, the integral answer will increase continually over time, so the effect is to push the Steady-State error to zero. The final difference between the process variable and the setpoint is the Steady-State error.

Derivative Response:

If the process variable is rapidly increasing, the derivative component causes the output to decrease. The derivative response is proportional to the process variable's rate of change. Increasing the parameter of derivative time (Kd) will cause the control system to respond more strongly to changes in the error term and will increase the overall response speed of the control system. Most control systems use very tiny derivative time (Td) since the Derivative Response in the process variable signal is sensitive to errors. The derivative response will make the control system unstable if the control loop rate is too slow.

Advantages of PID Controller:

1. Not much expertise is required to tune the PID controller, it could be done by trial and error approach. However, there are several other ways to tune.

2. Easy to implement and can be run on less cost hardware.

3. It only works on the error between the desired setpoint value and the control value. Hence, no extra measurements or calculations of the internal state of the system are required. This means it could work with fewer sensors on the output signal, which reduces the overall cost of the system development.

Disadvantages of PID Controller:

PID controllers are not suitable for nonlinear applications. This means the controller may not work in the desired way for changing environments, since PID controllers work well within the fixed operating points.

Flow chart

The controller program flow chart is as shown below.

Image 4 – Flow chart of the Controller program

The above flow chart shows the logic implemented using the "PID" Controller in the continuous-time domain. In this experiment the input frequency is 2Hz and the desired output is 2 rotations on the DC motor shaft per second. For every one complete shaft rotation, the encoder produces 500Hz, as there are 500 cut slots on the disk of the encoder (Please see Image 1). Based on this, we need to produce a 1000Hz frequency to get 2 rotations per second.

Therefore, for 2Hz input, the output should produce 1000Hz i.e., two shaft rotations. The feedback data will be received from the encoder every 20 milliseconds, therefore for every 1 millisecond, the expected encoder output is 1Hz to reach 1000Hz output per 1 second.

Therefore, the input frequency is multiplied with a constant value of 10, to get 20Hz as input frequency for every 20 milliseconds. This input frequency is used to produce the error value by subtracting it with the feedback data.

Therefore, formula for error value is:

error = (2 * 10) – feedback frequency data Similarly, formula for Integral as part of PID controller is:

integral = integral + (error * TIME) //Where TIME is 20 milliseconds, i.e., 20

Formula for differential part of the PID controller is:

differential = (error – previous_error)/TIME // Where TIME is 20 milliseconds, i.e., 20

Final PID formula is:

PID = (error*Kp) + (integral * Ki) + (differential * Kd) // Kp=8, Ki=1.3, Kd=2.

It should be noted that the output value 737 makes zero rotation/speed to the DC motor shaft. Therefore, this value should be used as the offset value for output calculation. So, the PID algorithm should produce the desired output considering this offset value.

Output formula is:

output = 737 + (PID * Km) // Km = 0.008,

Km is considered as a coefficient related to the DC motor friction or any other factors which might contribute to the closed-loop system latency.

The controller program is designed to work as a server program to receive the feedback data from the encoder program via a network socket. The processed output data is sent back by this program to the "IoT" device (Serial port – RS-232), in this case, the DC motor. It could be seen in the flow chart that socket programming is being used to communicate the feedback data between Controller and Encoder software programs.

This program will listen to the port 25000 on the host IP address 192.168.23.2 indefinitely to receive the feedback data.

Encoder Program

Flow chart

The encoder program flow chart is as shown below.

Image 5 – Flow chart of the Encoder program

The above flow chart shows the logic implemented to receive the data from the Encoder portion of the DC motor. The encoder portion of the DC motor is connected to the GPIO pins 9 and 10. To receive this data inside the software program through the GPIO Pins, the following commands are executed using system command. Also, the rotational direction of the DC motor shaft can be determined by the signal data received from these GPIO pins.

Receiving data 1 on GPIO pin 9 represents the DC motor shaft rotating in a clockwise direction and 1 on GPIO pin 10 as an anti-clockwise direction. There will be a phase shift of the signal received between these pins (Please refer to Image-1).

Post executing the above commands, two threads are spawned within the program. One thread is to receive the data from the encoder of the DC motor via GPIO pins and the other thread to write the accumulated data into the network socket every 20 milliseconds. Both threads run inside an indefinite while loop, so the GPIO pins are polled continuously using a poll() function to get encoder data. This data is accumulated and written into the network socket periodically.

Concurrent reading and writing of data into a shared global variable by these threads will create a critical section. So, the mutex lock and unlock mechanism is used to avoid simultaneous access to the shared global variable.

This program opens a network socket with port 25000 and connects to the IP address 192.168.23.2 on which the server program (Controller) listens to receive the feedback data. This program acts as a client in the client-server socket programming.

The value of the global variable is reset to "0" as soon as the data is written into the network socket. This process continues every 20 milliseconds.

Discussion

There are multiple ways to establish client-server connectivity in network programming. We will present two ways of establishing client-server connectivity between programs in this section, and they are:

1. Network socket programming: In this approach, one program acts as a Client and the other program acts as a server. The difference in using socket programming between these programs is that the server program keeps listening to the port on the host indefinitely to receive and send data, whereas the client only makes the connection when it needs to send or receive data.

This closed-loop PID controller experiment uses socket programming concepts to communicate data between the programs, running on different network hosts.

2. SSH pipeline: In this approach "ssh" program is used to create a secured tunnel between network hosts to communicate information. One host act as a client and

the other host acts as a server. The "ssh" program internally uses a Unix socket to create a secured tunnel.

Command to run the client program using "ssh" is

./encoder > ssh -L 25000:localhost:25000 pi@RigPiPi-B -N Command to run the server program using "ssh" is:

ssh -R 25000:192.168.133.4:25000 pi@localhost ./controller

Stability Experiments

Tuning PID coefficients

Tuning is called the process of setting the optimum gains for "P", "I" and "D" to get an ideal response from a control system.

The benefits of a "PID" controller can be accomplished by the process of trial and error. This approach becomes reasonably simple if one recognizes the importance of each gain parameter. The "I" and "D" terms are first set to zero in this system and the proportional gain is increased before the loop output oscillates. The system becomes quicker as one increases the proportional gain, but care must be taken not to render the system unstable. The integral term is increased to stop the oscillations once "P" has been set to obtain a desired quick response. The integral term decreases the error of the steady-state, but overshoot increases. For a fast device, some amount of overshoot is often needed so that it can react immediately to changes. To achieve a minimum steady-state error, the integral term "I" is tweaked. The derivative term is increased until the loop is relatively quick to its set point until the "P" and "I" have been tuned with minimum steady-state error to get the desired fast control process. Increasing derivative term decreases overshoot and produces greater gain in stability, but makes the system highly sensitive.

The following graph is plotted as part of the experiment. The "P", "I", and "D" terms are optimized to yield a stable system and it could be observed that there are no overshoot and the magnitude on Y-axis is stable over time.

The values of P, I, and D coefficients to produce the below graph in the experiment is as follows: Kp – 8, Ki – 1.3, Kd – 2, Km – 0.008.

The graph's X-axis represents time in milliseconds and Y-axis magnitude or output offset value to the DC motor.

The graph (Please refer to Image-7) is a result of toggling input frequency over time (every 20 seconds). This test is performed to check the stability and response of the control system. The graph is a result of input frequency toggled between 0 and 2 Hz. This is for the clockwise rotation of the DC motor. Toggling input frequency in the range 0 and -2Hz makes the motor shaft rotate anticlockwise direction. The DC motor offset value is 737 which is a zero state, but it could be observed in the graph that the zero offset value is in the region of 760, which indicates that the DC motor has a dead zone from input range 737 to 760, beyond this range motor starts rotating.

Image 6 – Step response graph of the control system.

Image 7 – Step response graph of a control system for toggling input.

Operating regions of the DC motor – Linearization

It could be noticed in Image-7 that the DC motor has a dead zone at value 765, which means the motor starts rotating beyond this value. However, the offset value is 737 which states a zero rotation, but it is important to identify the range beyond which the DC motor starts rotating.

The following table gives the non-operating range of the DC motor for clockwise and anticlockwise rotation.

Rotation Direction	Non-operating region	Operating region
Clockwise	737 – 775	< 775
Anticlockwise	737 - 706	> 706

Table 3 – Operating region of DC motor

Conclusion

The learning outcome of the experiments are as follows:

1. Understanding the concepts of the OSI reference model and its application to M2M and IoT.

2. Designing a network and assigning the IP addresses to network devices. Creating a multihomed network and configuring the host with appropriate IP addresses in the network.

3. Find the latency between different network devices. Capture and analyze the IP packets.

4. Add/modify the IP tables, using route and iptables commands.

5. Machine to machine login in a network without using passwords, by copying the "ssh" public key.

6. Configuring a thing or external device to a network host and controlling it via a network, a hands-on approach for IoT.

7. Understanding of closed-loop system using PID algorithm and its applications.

8. Tuning the PID controller to achieve a stable control system.