Project Report

on
Intelligent Aerial Defence System

Submitted in partial fulfillment for the award of

Post Graduate Diploma in Embedded Systems Designs
From C-DAC, ACTS (Pune)

Guided by:

Mr. Tarun Bharani

Presented by:
Abhishek Kumar 210940130002
Angelina Yadav 210940130008
Anoop kumar 210940130010
Arvind kumar 210940130013
Manish chourey 210940130027
Saniyya P M 210940130044

Centre of Development of Advanced Computing (C-DAC), Pune

i
 CERTIFICATE
TO WHOMSOEVER IT MAY CONCERN
This is to certify that

Abhishek Kumar 210940130002

Angelina Yadav 210940130008
Anoop Kumar 210940130010
Arvind Kumar 210940130013
Manish Chourey 210940130027
Saniyya P M 210940130044

Have successfully completed their project on

Intelligent Aerial Defence System

Under the guidance of
Mr. Tarun Bharani

Project Supervisor Project Guide

ii
 ACKNOWLEDGEMENT

This is to acknowledge our indebtedness to our guide for his constant

guidance and helpful suggestions for the completion of this project
“Intelligent Aerial Defence system ”.

We express our deep gratitude towards him for inspiration, personal

involvement, constructive criticism that he provided beyond technical guidance
during the course of this project. His shared enthusiasm taught us patience and
his word of advice acted as morale booster. We are very thankful to our guide
Mr. Tarun Bharani for his inspiration.

We take this opportunity to thank Ms. Risha P.R. and all staff members for
cooperation provided by them in many ways. It is our great pleasure in expressing
sincere and deep gratitude towards Ms. Namrata Ailawar for his valuable
guidance and constant support throughout this work.

Our most heartfelt thanks goes to Ms. Swati Salunkhe (Course co-ordinator,
PG-DESD)who gave all the required support and kind co-ordination to provide
all the necessities like required hardware, internet facility and extra Lab hours to
complete the project and throughout the course up to the last day here in CDAC

ACTS, Pune.

iii
 ABSTRACT

This project involves the complete prototype of a aerial defense system which can intercept and destroy
incoming threats, using radar system (ultrasonic sensor/doppler sensor), threatened object coming from air
space can be detected,tracked and destroyed. We aimed to develop a compact and highly mobile defense
system that allows operational flexibility. The system can autonomously track and shoot at moving targets,
while also allowing a user to remotely access and control the gun. The mobility, hardiness, and functionality
of this system life allows a reliable replacement for human beings in harsh and hostile environments,
ultimately sparing a.

Based on the information provided by the radar sensor, microcontroller will send data to the AWS
dashboard control through beaglebone using MQTT protocol. Beaglebone and STM32 is connnected
through CAN Bus. From AWS Dashboard we can monitor our air space from anywhere in the world. If
any threatened object come in the range of radar then it will show on AWS cloud and we can send signal
through AWS to microcontroller connected to launcher to set the trajectory of the missile and destroy the
threat before they can cause damage through AWS by publishing the data. We also set the critical range to
STM32 if no signal comes from dashboard then it will automatic launch missile to the threatened object if
comes in critical range.

iv
 TABLE OF INDEX

Topic Page No.

1. Introduction
1.1 History --------------------------------------------------------------------------------- 1
1.2 About Project -------------------------------------------------------------------------- 2
1.3 System Requirement ------------------------------------------------------------------------2

2. Literature Survey

2.1 ARM Cortex M4 Architecture--------------------------------------------- 3

2.2 Controller Area Network---------------------------------------------------- 4

2.2.1 CAN Network

2.2.2 CAN Bus

2.2.3 CAN Bus Levels

2.2.4 CAN Layers

2.2.5 CAN Frames

2.2.6 Bus Arbitration

2.3 Internet of Things(IoT)-----------------------------------------------------15

2.3.1 Definition

2.3.2 Architecture
3. Requirements

3.1 Hardware Requirements----------------------------------------------------18

3.1.1 Introduction to STM32F303 Discovery Board

v
 3.1.2 Ultrasonic Sensor(HC-SR04)

3.1.3 CAN Transceiver

3.1.4 Begalebone Black

3.2 Communication Protocol--------------------------------------------------23

3.2.1 MQTT

3.3 Software Requirements------------------------------------------------------25

3.3.1 STM32CubeIDE
4. Design and Flow Chart

4.1 Block Diagram----------------------------------------------------------------27

4.2 Circuit Diagram---------------------------------------------------------------28

5. Hardware Set-up---------------------------------------------------------------------29

6. Results --------------------------------------------------------------------------------30

7. Conclusion and Future Scope- ----------------------------------------------------33

8. References -----------------------------------------------------------------------------34

vi
 LIST OF FIGURES

Figure Page No.

Figure 2.1-ARM Cortex M4 Architecture------------------------------------------------3

Figure 2.2 _CAN Network------------------------------------------------------------------5

Figure 2.3- CAN BUS --------------------------------------------------------------------6

Figure 2.4 -High speed CAN Voltage levels-------------------------------------------8

Figure 2.5 -Low Speed CAN Voltage levels-------------------------------------------8

Figure 2.6 -CAN Layer------------------------------------------------------------------9

Figure 2.7-Data Frame-------------------------------------------------------------------11

Figure 2.8- Standard and Extended Identifier fields---------------------------------11

Figure 2.9-Remote Frame---------------------------------------------------------------12

Figure 2.10-Error Frame-----------------------------------------------------------------12

Figure 2.11-Oveload Frame-------------------------------------------------------------13

Figure 2.12 BUS Arbitation-------------------------------------------------------------14

Figure 2.13 Carrier Sense----------------------------------------------------------------15

Figure 2.14 IOT Architecture------------------------------------------------------------16

Figure 3.1- STM32F303 Discovery Board---------------------------------------------18

vii
Figure 3.2- HC-SR04 ultrasonic Sensor-------------------------------------------------19

Figure 3.3- HC-SR04 ultrasonic Sensor - Working------------------------------------20

Figure 3.4- SN65HVD230 Pin Configuration------------------------------------------21

Figure 3.5- MQTT Protocol---------------------------------------------------------------23

Figure 3.6-STM32Cube Ecosystem------------------------------------------------------25

Figure 4.1 Block Diagram-----------------------------------------------------------------27

Figure 4.2-Circuit Diagram------------------------------------------------------------------28

Figure 5.1 Hardware setup-------------------------------------------------------------------29

viii
 Chapter 1
Introduction
1.1 History
Aerial Defence (AD): A Peep into History

During the Second World War, the Union War Book made a clear distinction by listing out
coastal Air Defence including at Ports and Anti-Aircraft (AA) Defence as Army responsibilities. The
Air Force role comprised of “Home Defence air attack and AD intelligence scheme”. Thus while, the
Royal Indian Air Force was engaged in regaining the command of the air; the Indian Anti-Aircraft
Artillery was employed to defend all vulnerable assets from enemy air force.

Post-1971 war AA Artillery expanded in a big way. Officers were directly commissioned into the AA
Artillery units and new weapon systems were inducted, including state of the art Surface to Air Missiles
(SAM). The training of men too got separated out from Artillery. The responsibility of ground-based
AD at airfields continued with AA Artillery.

In 1993, the proposal for creating a separate arm in the Army to carry out AD functions was on cards.
It was during the same time that the Union War Book was revised, wherein the heading was changed
from “Anti-Aircraft Defence” to “Air Defence”, thus blurring the distinction. Till then the anti-aircraft
defence dealt clearly with Ground-Based Air Defence Weapon Systems (GBADWS) and AD was the
action in the air by Air Force. The inclusion of the revised statement, “The responsibility of providing
AD of Indian Air Space rests with the Indian Air Force”, changed the demarcation. A joint ethos became
disjointed.

AD Responsibility Since 1993

Since Air Force became the prime provider of AD in the country, it should have undertaken following
tasks under its wings and delegated/distributed the same based on a clear-cut policy between the three
services:
1. Surveillance of Air Space
2. AD Weapons
3. Control and Reporting (C&R) System
4. Communications, Frequency Management and Electronic Warfare (EW)

1
1.2 About the Project

Through this project, we aim to implement a real time aerial defence system where the real-time data
from the sensor (interfaced on one node) used for detecting the object is sent to another node for intercepting
the object. In addition, the data is also being sent to the cloud instantaneously.
The object detection and the distance at which the object is detected is provided by the ultrasonic
sensor. The sensor data is received at node 1 is transferred to node 2 utilising a robust Controller Area Network
(CAN) communication protocol. The node 2 is connected to the interned which enables sending the data to
the cloud platform. The data is sent to the cloud using Message Queueing Telemetry Transport (MQTT).

1.3 System Requirements

1.3.1 Hardware
• STM32F303 Discovery Board
• HC-SR04 Ultrasonic Sensor
• SN65HVD230 CAN Transceivers
• BeagleBone Black

1.3.2 Software

• STMCubeIDE

2
Chapter 2

Literature Survey
2.1 ARM Cortex M4 Architecture

Figure 2.1 ARM Cortex M4 Architecture

The ARM® Cortex®-M4 processor is a high performance embedded processor with DSP
instructions developed to address digital signal control markets that demand an efficient,
easyto-use blend of control and signal processing capabilities. The processor is highly
configurable enabling a wide range of implementations from those requiring floating point
operations, memory protection and powerful trace technology to cost sensitive devices
requiring minimal area.

3
Key Benefits

1. Gain the advantages of a microcontroller with integrated DSP, SIMD, and MAC
instructions that simplify overall system design, software development and debug

2. Accelerate single precision floating point math operations up to 10x over the equivalent
integer software library with the optional floating-point unit (FPU)

3. Develop solutions for a large variety of markets with a full-featured ARMv7-M

instruction set that has been proven across a broad set of embedded applications

4. Achieve exceptional 32-bit performance with low dynamic power, delivering leading
system energy efficiency due to integrated software-controlled sleep modes,
extensive clock gating and optional state retention.

2.2 Controller Area Network

The Controller Area Network bus is an International Standardization Organization (ISO)

defined serial communications bus originally developed for the automotive industry to replace
the complex wiring harness with a two-wire bus. The Controller Area Network bus, or CAN
bus, is a vehicle bus standard designed to allow devices and microcontrollers to communicate
with each other within a vehicle without a host computer.

CAN is a reliable, real-time protocol that implements a multicast, data-push, publisher

/subscriber model. CAN messages are short (data payloads are a maximum of 8 bytes, headers
are 11 or 29 bits), so there is no centralized master or hub to be a single point of failure and it
is flexible in size. Its real-time features include deterministic message delivery time and global
priority through the use of prioritized message IDs.

4
Bus arbitration is accomplished in CAN using bit dominance, a process where nodes begin to
transmit their message headers on the bus, then drop out of the “competition” when a dominant
bit is detected on the bus, indicating a message ID of higher priority being transmitted
elsewhere. This means bus arbitration does not add overhead because once the bus is “won”
the node simply continues sending its message. Because there is no time lost to collisions on a
heavily loaded network.

CAN is ideal for periodic traffic. Lastly, CAN's reliability features are suited for typically harsh
embedded environments.

CAN was designed for a typical embedded system with periodic, busty traffic, where every
node transmits at regular intervals. Ethernet, on the other hand, was designed for aperiodic,
light traffic and allow number of active transmitters. More significantly, CAN was designed
to achieve tight, real-time schedules, unlike Ethernet.

2.2.1 CAN Network

Figure 2.2 CAN Network

A CAN network consists of a number of CAN nodes which are linked via a physical
transmission medium (CAN bus). In practice, the CAN network is usually based on a line
topology with a linear bus to which a number of electronic control units are each connected via

5
a CAN interface. The passive star topology may be used as an alternative. An unshielded
twisted two-wire line is the physical transmission medium used most frequently in applications
(Unshielded Twisted Pair — UTP), over which symmetrical signal transmission occurs.
The maximum data rate is 1 Mbit/s. A maximum network extension of about 40 meters is
allowed. At the ends of the CAN network, bus termination resistors contribute to preventing
transient phenomena (reflections). ISO 11898 specifies the maximum number of CAN nodes
as 32.

2.2.2 CAN Bus

Figure 2.3 CAN Bus

Physical signal transmission in a CAN network is based on transmission of differential voltages

(differential signal transmission). This effectively eliminates the negative effects of
interference voltages induced by motors, ignition systems and switch contacts. Consequently,
the transmission medium (CAN bus) consists of two lines: CAN High and CAN Low.

6
Twisting of the two lines reduces the magnetic field considerably. Therefore, in practice twisted
pair conductors are generally used as the physical transmission medium. Due to finite signal
propagation speed, the effects of transient phenomena (reflections) grow with increasing data
rate and bus extension. Terminating the ends of the communication channel using termination
resistors (simulation of the electrical properties of the transmission medium) prevents
reflections in a high-speed CAN network.

The key parameter for the bus termination resistor is the so-called characteristic impedance of
the electrical line. This is 120 Ohm. In contrast to ISO 11898-2, ISO 11898-3 (low-speed CAN)
does not specify any bus termination resistors due to the low maximum data rate of 125 kbit/s.

2.2.3 CAN Bus Levels

Physical signal transmission in a CAN network is based on differential signal transmission. The
specific differential voltages depend on the bus interface that is used. A distinction is made here
between the high-speed CAN bus interface (ISO 11898-2) and the low-speed bus interface (ISO
11898-3).

ISO 11898-2 assigns logical “1” to a typical differential voltage of 0 Volt. The logical “0” is
assigned with a typical differential voltage of 2 Volt. High-speed CAN transceivers interpret a
differential voltage of more than 0.9 Volt as a dominant level within the common mode
operating range, typically between 12 Volt and -12 Volts. Below 0.5 Volt, however, the
differential voltage is interpreted as a recessive level. A hysteresis circuit increases immunity
to interference voltages. ISO 11898-3 assigns a typical differential voltage of 5 Volt to logical
“1”, and a typical differential voltage of 2 Volt corresponds to logical “0”. The figure

“High-Speed CAN Bus Levels” and the figure “Low-Speed CAN Bus Levels” depict the
different voltage relationships on the CAN bus.

7
High Speed CAN:

Figure 2.4 High speed CAN voltage levels

Low Speed CAN:

Figure 2.5 Low speed CAN voltage levels

2.2.4 CAN Layers

The CAN protocol, like many networking protocols, can be decomposed into the following
abstraction layers.

8
 Figure 2.6 CAN Layers

Data Link Layer:

Most of the CAN standard applies to the transfer layer. The transfer layer receives messages
from the physical layer and transmits those messages to the object layer. The transfer layer is
responsible for bit timing and synchronization, message framing, arbitration,
acknowledgement, error detection and signalling, and fault confinement. It performs:

1. Error Detection

2. Message Validation

3. Acknowledgement

4. Arbitration

5. Message Framing

9
Physical Layer:

CAN bus specify the link layer protocol with only abstract requirements for the physical layer.
As a result, implementation often employs custom connector with various sorts of cables, of
which two are the CAN bus lines. Noise immunity is achieved by maintaining the differential
impedance of the bus at a low level with low-value resistors (120 ohms) at each end of the bus.

2.2.5 CAN Frames

1.Data Frame

2. Overload Frame

3.Remote Frame

4. Error Frame

Data Frame:

The data frame is the most common message type, and comprises the Arbitration Field, the
Data Field, the CRC Field, and the Acknowledgment Field. The Arbitration Field contains an
11-bit identifier and the RTR bit, which is dominant for data frames. Next is the Data Field
which contains zero to eight bytes of data, and the CRC Field which contains the 16-bit
checksum used for error detection. Last is the Acknowledgment Field.

10
 Figure 2.7 Data Frame

Figure 2.8 Standard and Extended identifier fields

Remote Frame:

The intended purpose of the remote frame is to solicit the transmission of data from another
node. The remote frame is similar to the data frame, with two important differences. First, this
type of message is explicitly marked as a remote frame by a recessive RTR bit in the arbitration
field, and secondly, there is no data.

11
 Figure 2.9 Remote frame

Error Frame:

The error frame is a special message that violates the formatting rules of a CAN message. It is
transmitted when a node detects an error in a message, and causes all other nodes in the network
to send an error frame as well. The original transmitter then automatically retransmits the
message. An elaborate system of error counters in the CAN controller ensures that a node
cannot tie up a bus by repeatedly transmitting error frames.

Figure 2.10 Error frames

12
Overload Frame:

The overload frame is mentioned for completeness. It is similar to the error frame with regard
to the format, and it is transmitted by a node that becomes too busy. It is primarily used to
provide for an extra delay between messages.

Figure 2.11 Overload frame

2.2.6 Bus Arbitration

The CAN communication protocol is a carrier-sense, multiple-access protocol with collision

detection and arbitration on message priority (CSMA/CD+AMP). CSMA means that each node
on a bus must wait for a prescribed period of inactivity before attempting to send a message.
CD+AMP mean that collisions are resolved through a bit-wise arbitration, based on a
preprogrammed priority of each message in the identifier field of a message. The higher priority
identifier always wins bus access. That is, the last logic-high in the identifier keeps on
transmitting because it is the highest priority.

Whenever the bus is free, any unit may start to transmit a message. If two or more units start
transmitting messages at the same time, the bus access conflict is resolved by bit-wise
arbitration using the Identifier. The mechanism of arbitration guarantees that neither
information nor time is lost. If a data frame and a remote frame with the same identifier are

13
nitiated at the same time, the data frame prevails over the remote frame. During arbitration
every transmitter compares the level of the bit transmitted with the level that is monitored on
the bus. If these levels are equal the unit may continue to send. When a ’recessive’ level is sent
and a ’dominant’ level is monitored, the unit has lost arbitration and must withdraw without
sending one more bit.

Figure 2.12 Bus Arbitration

14
 Figure 2.13 Carrier Sense

2.3 Internet of Things (IoT)

2.3.1 Definition

IoT is simply the network of interconnected things/devices which are embedded with sensors,
software, network connectivity and necessary electronics that enables them to collect and
exchange data making them responsive.

More than a concept Internet of Things is essentially an architectural framework which allows
integration and data exchange between the physical world and computer systems over existing
network infrastructure.

The fundamental components that make internet of things a reality are:

• Hardware- Making physical objects responsive and giving them capability to retrieve
data and respond to instructions

15
 • Software- Enabling the data collection, storage, processing, manipulating and
instructing.

Communication Infrastructure- Most important of all is the communication infrastructure

which consists of protocols and technologies which enable two physical objects to exchange
data

2.3.2 Architecture

IoT system consists of three main parts viz. sensors, network connectivity and data storage
applications. The same has been depicted in figure-1. As shown in the figure, Sensors in the
IoT devices either communicate directly with the central server for data storage or communicate
via gateway devices.

Figure 2.14 IoT Architecture

Sensors for various applications are used in different IoT devices as per different applications
such as temperature, power, humidity, proximity, force etc. Gateway takes care of various
wireless standard interfaces and hence one gateway can handle multiple techologies and
multiple sensors. The typical wireless technologies used widely are 6LoWPAN, Zigbee,
Zwave, RFID, NFC etc. Gateway interfaces with cloud using backbone wireless or wired
technologies such as WiFi, Mobile , DSL or Fibre.

16
As shown IoT supports both IPv4 and IPv6 protocols. Due to support of IPv6 which has
about 128-bit long IP address length, there are enough addresses available to growing demand
of IoT devices. DTN (Delay Tolerant Networks) is the unique feature of IoT which takes care
of large variable delay requirement of IoT based networks compare to traditional computer
networks.

17
Chapter 3

Requirements
3.1 Hardware Requirements
3.1.1 Introduction To STM32F303 Discovery Board

The STM32F303xx family is based on the high-performance

ARM® Cortex®-M4 32-bit RISC core with FPU operating at a frequency of up to 72 MHz,
and embedding a floating-point unit (FPU), a memory protection unit (MPU) and an embedded
trace macrocell (ETM). The family incorporates high-speed embedded memories (up to 1
Mbytes of Flash memory, up to 192 Kbytes of RAM) and an extensive range of enhanced I/Os
and peripherals connected to two APB buses.

They also feature standard and advanced communication interfaces: up to two I2Cs, up to three
SPIs (two SPIs are with multiplexed full-duplex I2Ss), three USARTs, up to two UARTs, CAN
and USB. To achieve audio class accuracy, the I2S peripherals can be clocked via an external
PLL. The STM32F303xB/STM32F303xC family operates in the -40 to +85 °C and -40 to +105
°C temperature ranges from a 2.0 to 3.6 V power supply. A comprehensive set of power-saving
mode allows the design of low-power application

Figure 3.1 STM32F303 Discovery Board

18
3.1.2 Ultrasonic sensor

An ultrasonic sensor is an electronic device that measures the distance of a target object by emitting
ultrasonic sound waves, and converts the reflected sound into an electrical signal. Ultrasonic waves
travel faster than the speed of audible sound (i.e., the sound that humans can hear). Ultrasonic sensors
have two main components: the transmitter (which emits the sound using piezoelectric crystals) and
the receiver (which encounters the sound after it has travelled to and from the target).

In order to calculate the distance between the sensor and the object, the sensor measures the time
takes between the emission of the sound by the transmitter to its contact with the receiver. The formula
for this calculation is D = ½ T x C (where D is the distance, T is the time, and C is the speed of sound
~ 343 meters/second). For example, if we set up an ultrasonic sensor aimed at a box and it took 0.025
seconds for the sound to bounce back, the distance between the ultrasonic sensor and the box would
be:
D = 0.5 x 0.025 x 343
or about 4.2875 meters.

Figure 3.2- HC-SR04 ultrasonic Sensor

19
 Figure 3.3- HC-SR04 ultrasonic Sensor - Working

This module has an ultrasonic transmitter, ultrasonic receiver, and control circuit. With this module, we
can measure distances from 2cm to 400cm with a ranging accuracy that can reach up to 3mm. Each HC-
SR04 module includes an ultrasonic transmitter, a receiver and a control circuit. The module has 4 pins:

• VCC: 5V power input pin

• Trig: Trigger pin
• Echo: Echo pin
• GND: Ground pin

Trig and Echo pins are used to communicate with the microcontroller.

20
.

3.1.3 CAN Transceiver(SN65HVD230)

The SN65HVD230 is a high-speed CAN, fault-tolerant device that serves as the interface
between a CAN protocol controller and the physical bus. The SN65HVD230 device provides
differential transmit and receive capability for the CAN protocol controller, and is fully
compatible with the ISO-11898-2 standard, including 24V requirements. It will operate at
speeds of up to 1 Mb/s. Typically, each node in a CAN system must have a device to convert
the digital signals generated by a CAN controller to signals suitable for transmission over the
bus cabling (differential output). It also provides a buffer between the CAN controller and the
high voltage spikes that can be generated on the CAN bus by outside sources (EMI, ESD).

Features

• Supports 1 Mb/s operation

• Implements ISO-11898-2 standard physical layer requirements
• Suitable for 12V and 24V systems
• Externally-controlled slope for reduced RFI emissions
• Detection of ground fault (permanent Dominant) on TXD input

Figure 3.4 SN65HVD230 Pin Configuration

21
 3.1.4 Beagle bone Black

Beagle Bone Black is a low-cost, community-supported development platform for

developers and hobbyists. Boot Linux in under 10 seconds and get started on
development in less than 5 minutes with just a single USB cable.

Processor: AM335x 1GHz ARM® Cortex-A8

▪ 512MB DDR3 RAM

▪ 4GB 8-bit eMMC on-board flash storage
▪ 3D graphics accelerator
▪ NEON floating-point accelerator
▪ 2x PRU 32-bit microcontrollers

Connectivity

▪ USB client for power & communications

▪ USB host
▪ Ethernet

Software Compatibility

▪ Debian
▪ Android
▪ Ubuntu
▪ Cloud9 IDE on Node.js w/ Bone Script library

Board Feature Highlights

▪ Beagle Bone Black mechanical and header compatibility

▪ 1GB RAM and 16GB on-board eMMC flash with high-speed interface
▪ USB type-C for power and super speed dual-role controller; and USB type-A host
▪ Gigabit Ethernet, 2.4/5GHz Wi-Fi, and Bluetooth
▪ Micro HDMI
▪ Zero-download out-of-box software experience with Debian GNU/Linux

22
3.2 Communication Protocol
3.2.1 MQTT

Figure 3.5 MQTT Protocol

MQTT stands for MQ Telemetry Transport. It is a publish/subscribe, extremely simple and

lightweight messaging protocol, designed for constrained devices and low-bandwidth,
highlatency or unreliable networks. The design principles are to minimise network bandwidth
and device resource requirements whilst also attempting to ensure reliability and some degree
of assurance of delivery. These principles also turn out to make the protocol ideal of the
emerging “machine-to-machine” (M2M) or “Internet of Things” world of connected devices,
and for mobile applications where bandwidth and battery power are at a premium.

23
These characteristics make it ideal for use in constrained environments or low-bandwidth networks
with limited processing capabilities, small memory capacities and high latency. The MQTT design
minimizes network bandwidth requirements while attempting to ensure reliability of data.
As technology evolves, more devices connect to each other across the internet evolving into what
has sometimes been called the "internet of things". The messages sent from one place to another
can be interpreted and acted upon intelligently by a machine, rather than with human intervention.

MQTT is a technology capable of connecting all these remote data-collecting devices. The
Extended Reach (XR component) of WebSphere MQ enables devices at the edge of the network to
connect into the messaging backbone. With the new capability devices such as smart energy meters,
phones, cars, trains, satellite locations, and personal health care devices can now be connected,
enabling transmissions from remote sensors to reach the central systems for processing and for
control commands to be sent out to the devices.

Embedded sensor instrumentation can measure the condition of devices and exchange
that data with other machines, enabling analysis and response to the data in real time.
This may include tiny passive or intelligent devices which may have low bandwidth and
unreliable networks such as radio-frequency identification (RFID) chips which can be
embedded in everyday things such as ID cards. Having the ability to use small hardware
which can utilize MQTT technology to connect to the internet allows everyday objects
to transport data from one device to another. These tiny devices publish messages which
then using the MQTT protocol are received by the subscribers and may trigger an event
based on data received. Some very real and useful examples of ways to exploit the
MQTT technology can be the use of hardware chips to transmit information for health
care monitoring of pacemakers, energy meters, cars/trucks, et

24
3.3 Software Requirements
3.3.1 STM32CubeIDE

STM32CubeIDE is the first integrated development environment from ST, and it will serve as
a reference to developers creating solutions for their STM32 microcontrollers. Many use a
toolchain from a third-party vendor, and we will continue to work with IAR Systems, Arm
Keil, and others, to ensure that they offer an exceptional experience to their users.
STM32CubeIDE is nonetheless a highly symbolic initiative because it provides a free and
uniquely feature-rich environment to enthusiasts and professionals, thanks to the integration of
tools like STM32CubeMX that will enable a more efficient workflow. STM32CubeIDE is
available for Windows, macOS, and Linux, with a version specific for Debian/Ubuntu,
Fedora and a more general installer for the other distributions. ST will continue to update it by
including additional STM32Cube software within STM32CubeIDE.

Figure 3.6-STM32Cube Ecosystem

Launched five years ago, the STM32Cube brand designates the solutions we provide to help
developers design products and applications. This software ecosystem relies on two pillars:
embedded packages and software tools. There are two types of STM32Cube Packages: MCU
Packages and Expansion Packages. The MCU Packages (STM32CubeF4, for instance) contain
drivers, low-level APIs, as well as demo and example codes for Nucleo and Discovery boards.
The STM32Cube Expansion Packages serve as a complement to the MCU Packages by

25
offering additional middleware or drivers, as we recently saw with X-CUBE-AI, the first
package in the industry to enable the conversion of a neural network into the optimized code
for STM32 MCUs. Finally, the STM32Cube software tools for PCs assist in the design of
applications. For instance, STM32CubeMonUCPD is a monitoring tool that works with all our
USB-C PD interfaces and libraries to facilitate testing and implementation operations.

26
Chapter 4

Design and Circuit diagram

4.1 Block Diagram

Block diagram of the system is as shown in below figure. The system consists of following modules.

1. STM32f303V6 Discovery Board

2. Ultrasonic sensor
3.CAN Trans-receiver
4.BeagleBone black

Figure 4.1: Block Diagram of Intelligent Aerial Defence system using IoT

27
4.2 Circuit Diagram

MQTT

Figure 4.2: Circuit Diagram of Intelligent Aerial Defence system using IoT

28
CHAPTER 5
Hardware Set-up

Fig 5.1 Hardware setup

29
Chapter 6
Results

30
31
32
Chapter 7
Conclusion and Future Scope

7.1 Conclusion

The Air Defence Command will provide a big boost to the Aerial Defence of the nation.
Optimisation of AD weapons is the need of the hour. In this project a radar system which
controls the missile launching vehicle triggering and positioning was designed with the help of
STM32F303V6 Microcontroller, Beaglebone Black, AWS IoT, CAN Tx Rx Module and
ultrasonic sensor, which can detect the position, distance of obstacle which comes in its way
and converts it into visually representable form in the STM32F303V6 processing software and
transmit the data to AWS via Beaglebone Black which receives information through CAN Rx
Tx, from there we can decide to take appropriate action needed. This system can be used in
defence for object detection and destruction system.

7.2 Future Scope

1. By using Artificial Intelligence camera and sensors we can identify any moving object in air
space in future.

2. In Future it can be used as an advanced tracking system along with high intensity camera to
track a real target(say a Missile or aerial vehicals/ enemies aircraft or attack helicoptors).

3. The advantage of this unit is that to run the system we can use video camera and other sensors
to see the live moving target from anywhere in the world. Further extension to the project can be
manipulating and controlling the system from a remote place from the information collected
from sensors.

33
Chapter 8
References
1. https://elearning.vector.com/vl_can_introduction_en.html

2. Renesas CAN pdf

3. Ultrasonic senor document

4. CAN primer

5. STM32F303 Discovery User Manual

6. Beaglebone black document

7. http://internetofthingsagenda.techtarget.com/definition/MQTT-MQTelemetryTransport
8. http://nodemcu.com/index_en.html

9. https://www.arm.com/products/processors/cortex-m/cortex-m4-processor.php

10. https://us-east-1.console.aws.amazon.com/iot/home?region=us-east-1#/learnHub

11. https://aws.amazon.com/iot/resources/?iot-resources-videos.sort-by=item.additionalFields.sortOrder&iot-resources-
videos.sort-order=asc&awsf.event-series=*all&awsf.audience-type=*all&awsf.industry-type=*all&awsf.product-
type=*all&awsf.iot-features=*all&iot-resources-cards.sort-by=item.additionalFields.sortOrder&iot-resources-cards.sort-
order=asc&awsf.iot-resources-filter-content-type=*all&awsf.iot-resources-filters-audience=*all&awsf.iot-resources-
filters-industry-type=*all&awsf.%20iot-resources-filters-product=*all&awsf.iot-resources-filters-feature=*all

12. https://docs.aws.amazon.com/iot/latest/apireference/Welcome.html?icmpid=docs_iot_console_secure_overview

34