iii

Abstract

Current alarm systems rely on circuit voltage sensing technology for communications between

sensors and control devices. This report details the aims, methods and outcomes of a project to

develop the core communication technology for a new type of alarm system, capable of

detecting a range of conditions such as motion, heat and gas, and communicating these events

over an I.P.-based network. The project included the development of a new protocol for

communicating alarm events and conditions between devices, and the development of software

to implement this protocol between detection devices and a central control panel. A Raspberry

Pi was used to simulate a node device using the GPIO pins for inputs and outputs, but the

project also explored the use of a PIC microprocessor to implement the detection device

processing instead. The PIC hardware was fully designed and build on a prototyping board, but

further developments would be needed to write the software to run the PIC and complete the

implementation using such a device. The final product cost of a system built in this manner

was considered and compared with that of a typical system currently on the market, and based

on the work so far carried out it would seem that there is the potential for significant cost

savings when this system is used for a very large, multi-zone system when compared to the

cost of a currently available system.

Keywords: burglar, alarm, networking, PIC, safety system

iv

Table of contents

1. Introduction and background .............................................................................................. 5

2. Literature review ................................................................................................................. 6

3. Methodology and Theory ................................................................................................... 7

3.1. Hardware Requirements and Selection ....................................................................... 7

3.2. PIC Circuit Design Requirements ............................................................................... 9

3.3. Software Requirements ............................................................................................. 10

3.4. Protocol Requirements .............................................................................................. 12

4. Design ............................................................................................................................... 12

4.1. Protocol Design ......................................................................................................... 12

4.2. PIC Hardware Design................................................................................................ 14

4.3. Software Design and Implementation ....................................................................... 18

5. Description of Final Constructed Project ......................................................................... 23

5.1. Final Constructed Product ......................................................................................... 23

5.2. Cost of Product .......................................................................................................... 26

6. Discussion and Conclusions ............................................................................................. 27

6.1. Comparison of Costs of New System vs. Industry Standard .................................... 28

6.2. Further Developments for a Production-Ready Product ........................................... 29

7. Project Management, Consideration of Sustainability and Health and Safety ................. 30

7.1. Project Management .................................................................................................. 30

7.2. Sustainability ............................................................................................................. 30

7.3. Health and Safety ...................................................................................................... 32

References ................................................................................................................................ 33

Appendices ............................................................................................................................... 33

5

1. Introduction and background

There are a wide range of home safety and security devices designed to protect homes and

businesses currently on the market; from small standalone devices such as battery powered

smoke detectors and carbon monoxide detectors, to full multi-zone (a zone being a sensor input

to a system, with a system often classified by the number of zones it supports) fire or intruder

alarm system. Multi zone intruder alarm systems currently on the market operate by having a

central control panel monitoring the voltage level on signal cables running to each device; when

the detection device registers an event, it switches the voltage level on the cable. Fire alarm

systems come in two main varieties: conventional and addressable. The former work in the

same way as described above, whereas the latter allows multiple devices to be installed along

one cable, with each having a unique “address” which it transmits as part of a digital signal

when alerting the control panel to an alarm event. There are intruder alarm systems on the

market which have the capability to receive fire alarm signals, but these systems are still first

and foremost intrusion detection systems with this offered as an additional feature.

The vision this project works towards is to create a fully combined security and safety system,

with one device in each room having the capability to detect a number of conditions, for

example motion, heat, smoke and carbon monoxide. In addition to this, the system will be fully

IP-based, using existing network technologies and underlying protocols to transmit packets

containing state information between the detection devices and the control panel (from hereon

in referred to as “nodes” and “the core” respectively). This system would be able to provide a

single solution for protecting buildings and their occupants from intrusion, fire, and carbon

monoxide leaks, and by being based on existing network technology would be able to be

expanded using readily available network switches (connecting nodes to each other and the

core) and network cable. This project aims to develop a protocol for communicating between

nodes and the core, and implement this protocol between two network-connected devices

simulating the core and the node. Comparisons will be made between this new type of IP-based

system and existing systems to evaluate the potential this new system has to be a cheaper

alternative to what is currently offered on the market today.

6

2. Literature review

The first patent granted for an electronic burglar alarm was patent no. 9,802 awarded by the

U.S. Patent Office on 21st June 1853 to Augustus Russell Pope, for his design of an “Improved

Magnetic Alarm” [1]. This system used a set of switches connected to windows and doors,

which upon opening completed a circuit containing an electromagnet. When the electromagnet

was energised, it would draw a lever towards the magnet, with the other end of the lever striking

a bell. When energised, this magnet would also have the effect of breaking the connection of

what was an early implementation of a reed switch, causing the circuit to break. This would

de-energise the magnet, allowing the hammer to fall away from the bell, but reconnecting the

circuit once more by allowing the reed switch to engage. This cycle would repeat continuously,

causing the hammer to strike the bell over and over, which is what we would now term as

“ringing”. This designs for this circuit are shown in figure 1.

Figure 1: Circuit diagram of Pope’s Improved Magnetic Alarm [1]

There have been many developments in alarm technology since Pope’s initial design, however

alarm systems available on the market today still use a similar principle: tripping a sensor

completes a circuit and causes the alarm to sound. There are a variety of sensors available today

including, similar to Pope’s system, sensors to monitor windows and doors, and also now

sensors that monitor for motion in a room or pressure on a floor mat [2]. Fire alarm systems

work using a very similar principle, however are permanently “armed” and use a combination

7

of heat and/or smoke detectors to sense the presence of a fire.

In recent years there has been a growing trend to develop devices for the “Web of Things”

(WoT). As Ryan Boudreaux [3] states:

The Web of Things is a community of developers, researchers, and

designers exploring the future of the physical Web. We want to leverage

Web standards to interconnect all types of embedded devices (sensors,

mobile phones, etc) to make them easier to use and integrate in classic Web

applications. WoT aims to build a future Web of devices that is truly open,

flexible, and scalable, and we believe Web standards are the best way to do

it.

As this explains, the latest goal in technology is to be able to interconnect all forms of

embedded devices, and developing an I.P. based alarm system would be a major step in being

able to integrate alarm systems onto the Web of Things.

3. Methodology and Theory

The requirements for the project were first identified and classified as one of: hardware

requirements; PIC circuit design requirements; software requirements; protocol requirements.

3.1. Hardware Requirements and Selection

The devices needed to communicate with each other over an Ethernet connection, which brings

a major advantage to this system in that it can be connected together using standard off-the-

shelf network switches. This therefore meant the hardware needed to have an on-board Ethernet

RJ-45 socket available, which is the standard connector used in computer networking. The

hardware designed for the node needs to be able to read digital inputs from sensor sources and

provide digital outputs to trigger alarm devices (strobe lights, sounders etc.). Both the node and

core hardware needed to have the capability to process data and carry out computations, as they

both needed to be able to process and interpret the network packets received and carry out

actions depending on the messages received.

The system prototype was built using off-the-shelf hardware, as this provided a stable platform

for rapid development of the software and protocol. The hardware needed to be simple to

program, and have a network interface available for interfacing with the other devices in the

8

system. The device that was selected to fulfil these requirements was the Raspberry Pi, a low-

cost computer with a small form factor capable of running a variety of operating systems [4].

The Raspberry Pi is sold in two versions, A and B, with the latter having additional RAM,

additional USB ports and crucially, Ethernet connectivity [5]. The recommended operating

system for the Raspberry Pi is a distribution of Linux called Raspbian, a free operating system

based on Debian, optimised for the Raspberry Pi hardware and featuring a large repository of

common Debian packages adapted especially to run on the Pi [6].

The Raspberry Pi has also gone through a number of revisions to both its A and B models. The

model selected for this system was the Model B+, featuring a lower power consumption, more

USB ports, and more GPIO (General Purpose Input and Output) pins when compared to its

previous Model B counterpart.

Originally an aim of the project was to implement the node part of the system on a PIC

Microprocessor (from hereon in referred to simply as a PIC) based device, to reduce the cost

and physical size of the nodes. To fully implement the node, certain requirements placed

restrictions on which PICs could be selected for use in the project:

The PIC must have the ability to read inputs and outputs from alarm sources – The

minimum number of inputs/outputs was decided to be eight, allocated as six inputs and

two outputs. This allowed the use of motion, heat, smoke and carbon monoxide sensor

inputs with two spare for future use, and both a light and sound output.

The PIC must have the ability to connect to a network – for an application to transmit

over a network, a device must be able to implement the different layers of the Open

Systems Interconnection Model (OSI Model). It is required that the PIC can implement

the lowest three layers: network; data link; and physical.

Microchip, who manufacture the PICs, provide a TCP/IP stack written in C which implements

the transport layer of the model. The layers above this would be implemented in the software,

which left the lower layers of the model (network layer, data link layer and physical layer) to

be implemented by the PIC. Microchip manufacture a variety of devices for implementing

these layers, such as the ENC624J600 Ethernet Controller which implements all three layers,

and the LAN8710A Physical Layer Ethernet Transceiver, which implements just the Physical

layer; both of these types of devices then interface directly with a PIC. However, it was found

that Microchip manufacture a family of 8-bit PICs that have both a MAC and PHY integrated

9

on the chip: the PIC18F97J60 family. This family of PICs are capable of up to 10Mbps Ethernet

communication, have multiple timers and analog to digital (A/D) convertors and between 64

to 100 pins offering a large number of inputs [7]. It was decided to use the PIC18F67J60 PIC;

firstly because this has the lowest pin count of the family at 64 pins which still provided a

number of inputs/outputs greatly exceeding requirements, and the largest flash memory size

(128Kb) out of the three chips available with this number of pins. It was decided that, for

prototyping, the slightly higher cost of this memory size (advertised at time of writing by the

manufacturer as $3.30, compared to $3.19 for 96Kb and $3.07 64Kb) was negligible, as at that

point in the project the program size had not yet been determined. However, should the

prototype go into production this is an area where cost savings could be made once the memory

requirements have been determined.

3.2. PIC Circuit Design Requirements

The datasheet for the PIC outlines a number of circuit requirements for the PIC18F67J60, of

which the main requirements for the implementation required for the project are as follows:

Every pair of Vss/Vdd pins must be connected to each other by 0.1µF capacitors.

For Ethernet operation, the PIC must be clocked by an external 25Mhz oscillator

A sub circuit (given by the datasheet) composed of a number of components must be

implemented between the various Ethernet pins and the Ethernet socket for proper

interfacing with the network and electromagnetic interference reduction, including

various resistors, capacitors, common-mode chokes, centre-tapped transformers and

ferrite beads.

Further considerations needed to be made for implementing In-Circuit Serial Programming

(ICSP), a feature available on the PIC which allows for it to be programmed and debugged

whilst soldered in the circuit.

It was discovered that there exists RJ-45 socket modules available to purchase with a large

amount of the sub circuit described above integrated within the module. Figure 2 illustrates the

required circuitry for Ethernet operation, with the part of the circuit integrated in the Ethernet

socket module enclosed in red. The module selected for use in the circuit was the L829-1X1T-

91 10/100Base-TX Ultra Low Profile MagJack module manufactured by Bel Fuse Inc. This

10

module also has two status LEDs integrated into the module to indicate to the user both

connected status and network activity.

3.3. Software Requirements

The requirements for programming can be broken down as follows:

1. Design a method to connect new nodes to the core

2. Design a method to read and process alarm inputs to the node

3. Design a protocol to transmit events between core and nodes

4. Design a method to receive and process events at the core, and send “Alarm” state to

nodes to sound the alarms.

5. Design a method to receive and process system state information on the node from the

core

6. Design a user interface on the core for managing and arming the system

7. The nodes must also be able to operate independently, such as sounding their own

alarms as soon as fire/gas is detected

There are a number of programming languages available that would be able to implement these

Figure 2: Circuitry required to be included for Ethernet operation of the PIC. Enclosed in red is the part of the circuit integrated

into the RJ-45 module

11

requirements, however it was decided that due to a large amount of personal experience with

Python this would be the language used. It was also advantageous for ease of programming the

prototype that Python is an interpreted language, as this allows for quicker editing and testing

of code by not needing to be compiled first. Figure 3 describes the required process sequence

of an active monitoring node.

Figure 3: Flow chart describing the process for monitoring inputs and managing outputs of the node

Node reads input level from pin 1

Has pin state

changed since

last check?

Lookup pin type from local database

Is pin a safety

alarm and

active?

Transmit packet to core

Sound local alarm

No

Yes

Yes

Repeat for next pin

Have any

instructions

been received

from the core?

Process instruction Yes

No

No

12

3.4. Protocol Requirements

The protocol needs to be able to transmit details of what type of alarm is being sensed at the

node, the location of the node detecting the alarm, and whether it has detected the alarm being

raised or removed, so it can notify the core when a previous alarm condition has been cleared.

The protocol must also be able to communicate events from the core to the nodes, such as when

the system has entered an alarm state to inform all nodes to activate their outputs.

4. Design

This section describes the decisions taken in designing and implementing a solution to fit the

requirements detailed in section three.

4.1. Protocol Design

A network protocol, as defined by Bradley Mitchell: “defines rules and conventions for

communication between network

devices.” [8]. The protocol

developed as part of this project had

to outline when devices should

transmit packets, the structure of the

packets, and the expected response

of a device upon receiving different

types of packet.

Current alarm systems on the market today can optionally be fitted with digital communicator

devices to connect the system to a Remote Monitoring Centre, where a dispatcher is notified

when the alarm system is activated and can contact the police for a response. There are already

a number of protocols in existence communication between an alarm and receiving centre;

three common protocols being Fast Format, Contact ID and Security Industry Authority (SIA)

[9]. The Contact ID format operates by sending a packet consisting of an account number, an

event code, and an event status (new event, restored event) to the receiving centre. It also

specifies a very comprehensive mapping of events to three digit event codes, covering a very

Event Pin Type Contact ID

Event Code

Motion Security 130

Heat Safety 114

Smoke Safety 111

Carbon Monoxide Safety 162

Figure 4: Table of event codes used for the protocol

13

wide range of alarm types, and it was decided to use this mapping to define event codes for the

protocol. The event codes used for this system are detailed in figure 4.

The format of a Contact ID message is as follows [10]:

CCCC Q EEE GG ZZZ

CCCC = customer (subscriber account number)

Q = event qualifier, E = new event, R = restore

EEE = event code

GG = partition number, 00-08 (always 00 for non-partitioned panels)

ZZZ = zone ID number reporting the alarm (001-099), or user number for open/close reports.

This was taken as a base for designing the protocol for this system, however a few changes

were made. Changes were required as Contact ID is used for reporting events from a system to

a remote monitoring centre, whereas the protocol designed for this project was to be used for

reporting from a node to a core within a local system. Therefore the customer number was

replaced with a device identifier; partition number and zone ID, which for Contact ID inform

the monitoring centre what part of the system has been activated, were removed as they were

redundant. An additional argument was added to describe the location of the device. This could

have been omitted, with the core using the device ID to look up from a central database the

device location, but it was an aim of the project to keep the system as loosely coupled and have

the nodes being able to operate as independently as possible. Therefore with a location string

included in the message the node is able to describe itself fully. The format of the protocol was

set as follows:

DDDDDDDDDDDD,LLLLLLLLLLLLLLLLLLLL,Q,EEE

D = Device ID (MAC Address)

Q = Event Qualifier, 1 = Raised Alarm, 0 = Removed Alarm

EEE = Event code

L = 20 character location string

In addition to the event codes taken from the Contact ID protocol, some additional codes

were added to the protocol to enable communication from the core back to the node:

020: System alarm: The system is in an alarm state and the node should activate its

outputs

14

021: Silenced Alarm: The system is in a silenced alarm state so only light outputs

should be enabled.

029: Alarm Reset: The system has been reset and all outputs should be cancelled.

For communication between node and core, ports needed to be selected on which to send and

receive packets to and from. To select a port, the Internet Assigned Numbers Authority

(IANA) Service Name and Transport Protocol Port Number Registry database was consulted,

and ports 9431 and 9432 were found to be unassigned. These were therefore designated

within the project to be used for node to core transmission, and core alarm broadcasting

respectively.

4.2. PIC Hardware Design

The PIC circuit was first drawn out by hand, and built up using a combination of the project

requirements and the requirements detailed by the datasheet. As specified by the datasheet,

every pair of Vss/Vdd pins had to be coupled using a 0.1µF capacitor, which were the first

components drawn onto the design. As shown in figure 5, It was required that the MCLR pin

be connected through resistor R2 (see figure 5 for values), after which the connection splits

going through R1 to Vdd and C8 to Vss. The values for these three components were taken

from recommended values provided by the datasheet. Although not shown on the diagram in

figure 5, a jumper was required between R2 and C8 which is disconnected during

programming, as required by the PICkit 3 programmer. The PIC requires that a 25MHz crystal

oscillator be used as an external oscillator source when using the Ethernet function of the PIC.

The crystal was connected across the OSC1/OSC2 pins, with each leg of the crystal also being

connected to Vss via 33pF capacitors. The datasheet also specified a small number of extra

requirements for individual pins, such as the RBIAS pin being connected to Vss via a 2.26kΩ

resistor.

The next stage of the circuit design was to draw out the Ethernet circuitry given in the datasheet

onto Multisim. Multisim provides a large database of components for designing a circuit,

however more specialist components such as PIC microprocessors must be entered into the

database before being available for use in circuit designs. The component wizard tool was used

to generate a layout-only component for the PIC, using a 64-pin TQFP footprint. Each pin was

then labelled using the diagram provided in the PIC datasheet, and the component placed on

the design shown in figure 5. As explained in section 3.1 there is a sub circuit for connecting

15

design. Some of the components in the sub circuit were not essential to the operation of the the

Fig

ure

5:

Cir

cuit

des

ign

ed i

n M

ult

isim

fo

r th

e P

IC-b

ase

d n

od

e

16

the PIC to an Ethernet interface that is provided in the datasheet for inclusion in the main

circuit. Some of the components detailed are only recommended to reduce EMI emissions and

for the purpose of prototyping it was decided that these components would be omitted, as the

ferrite beads required are supplied for surface mount and connecting the large contact pads into

a breadboard would have added a level of complexity that was not required. However, should

the device enter production, these components should be entered back into the circuit design to

reduce EMI emissions from the device.

The L829-1X1T-91 module features two integrated LEDs used to display network connection

status and activity. The PIC datasheet recommended current limiting resistors to be inserted

between the PIC and LEDs, for which 50Ω was calculated to be appropriate.

Finally, the ICSP header pins were added to the

design, connected into the PGC/PGD pins,

Vss/Vdd and MCLR as specified by the PICkit 3

programmer. The PICKit 3 is the recommended

programmer supplied by Microchip for in-circuit

programming.

Once the circuit design was completed, the

design was transferred over to Ultiboard to make

a first draft of the PCB layout. In order to do this,

custom footprints needed to be designed again for

the PIC and Ethernet module. The datasheets for

both parts were used to draw accurate footprints

of the correct size and pin locations. The completed draft shown in figure 6 was then presented

to Roger Perrett to discuss manufacturing the PCB and whether any changes were required to

the design. However in this meeting, it became apparent that the facilities at the University

were only capable of printing PCBs to a minimum trace width and minimum trace clearance

of 0.5 mm each. The footprint of the PIC has a pitch of 0.5mm in total, broken down into

0.3mm pad width and 0.2mm clearance, therefore would not be able to be manufactured using

university facilities.

To overcome this, the PIC was ordered from Proto Advantage, a company based in Canada

that not only sold SMT to DIP adapters (which would still require extremely fine soldering,

Figure 6: Completed PCB design for the node

17

bordering on impossible by hand), but could also order in chips and solder them to the adapter,

supplying it as a finished assembly which was then suitable for prototyping on a breadboard.

Once the circuit was assembled on a breadboard (figure 7), some test programming revealed a

fault within the PIC and adapter assembly that meant one of the pins that drives the Ethernet

LEDs would not respond to an instruction to drive the output high. It was decided to use a

different output pin and control the LED manually in the program.

A large proportion of time was spent

investigating the TCP/IP stack provided by

Microchip for implementing network

programming with the PIC, and it became

apparent very quickly that it would be a far

more complex task than originally

anticipated. Peter Armitage and Dr David

Wakeling were both contacted, with Peter

Armitage being experienced with PICs and

Dr Wakeling with embedded devices, but

neither were familiar with using the stack to

program the PIC in C. Multiple documents

from Microchip were studied, but the

decision was made that the task of

programming the PIC would be too large for

the timescale of the project, and having

made very strong progress with the hardware development this would be left as a future

development to explore should the system move towards production.

To replace the PIC for the node, it was decided to use a second Raspberry Pi. The Raspberry

Pi has a set of GPIO pins which fulfilled the hardware requirement of having input/output pins,

and is capable of both wired and wireless connection to a network. Although the node and core

will both run on Raspberry Pis for the completed prototype, the core does not require anything

further than a network connection, so it was decided for simulation and test purposes the

software for the core could be run on a PC, leaving the Raspberry Pi already purchased for the

project available to be used for the node.

Figure 7: PIC Circuit prototyped on a breadboard

18

4.3. Software Design and Implementation

The software for the node was written in Python and uses a number of threads to operate. When

the program is launched, there are a number of global variables that are set which are used

throughout the code. The first four variables, namely notactive, MAC, location, and pinmap

are user-configurable and are changed to suit the requirements of each node. notactive allows

the user to configure whether the inputs are active high (enter 0) or active low (enter 1). MAC

is the physical MAC address of the unit, location is a user-provided name of the location that

the node should report alarm events as originating from, (i.e. hallway, kitchen), and pinmap is

a dictionary structure defining what alarm/output types are connected to each pin. The inputs

and outputs are designated by setting the dictionary values for each pin to an alarm type from

the table in figure 4 if the pin is an input, or alternatively “000” for a sound output or “001” for

a light output. The second set of variables are not configurable by the user and are used for

various purposes by the program, for example pinnos maps the software pin numbers (1-5) to

physical GPIO pin numbers, and there are also a range of variables such as systemalarm,

silentalarm that are used to represent the state of the system and node.

The final variable before the function definitions, transmitQueue, references a Queue object.

This is an implementation of a class available for import in Python which provides an ability

to implement different types of queuing; two types available are FIFO (First In First Out) and

LIFO (Last In First Out) [11]. This is especially useful in threaded programming to safely

exchange information between threads without blocking the execution of the program, and is

used in this program to queue detected alarm events for transmitting – the reasons for designing

the program in this manner are explained later in this section.

As previously mentioned, this program uses three threads to implement the requirements of the

software, as illustrated in figure 8. The first thread is the monitoring thread, which repeatedly

(with a one second pause between each iteration) checks each input pin using the checkPin

function for any change in input state. It also uses a safetycheck global variable as a flag for if

a “safety alarm” has been detected in this iteration (fire, carbon monoxide) and if so, activates

the node alarms. This check was implemented as a failsafe, so that in the event of a

communication failure between the node and the core, the node could still function as an

independent safety alarm. After checking each pin, the function then checks the state of the

system alarm flags (silentalarm, systemalarm) activated by the core, and activates/deactivates

19

the node alarms where necessary. This completes one iteration of the monitoring thread. The

aforementioned checkPin function takes a software pin number, looks up the mapping to a

physical pin number, and reads the digital value from the hardware pin. It then compares this

to the previously known value of this pin, and if there is a difference updates the saved value

and passes the pin event code, along with its state (active/non-active) to the transmitEvent

function. This function forms a message string ready for transmission to the core, and places it

in the transmit queue.

The second thread is the transmit thread, which constantly checks the queue for any queued

messages, and when a message is placed in the queue transmits it to the core. It was decided to

place this function in a separate thread from the monitoring thread, as had it have been in the

same thread, the transmission process would block execution until transmission has been

completed. Therefore in the event of a transmission failure or delay, the node would no longer

be monitoring inputs and could potentially provide a window for events to pass undetected. By

placing the message in a queue, the monitoring process can continue monitoring inputs without

delay whilst the transmit thread deals with communications with the core. A FIFO queue was

chosen so that events are transmitted in the order in which they occur.

The final thread is the alarm thread, which receives the system alarm state from the core. This

is received in the form of a UDP broadcast packet every second, and the global state variables

in the node program are updated to reflect the system-wide state. The function creates a UDP

socket and enters an infinite loop which waits for a packet, and upon receipt of a packet decodes

and interprets the message. This thread doesn’t alter the physical alarm outputs itself, but as

previously explained the monitoring thread checks the state variables with each iteration, and

deals with output state. This allows the monitoring thread to have complete control over the

outputs, and make a decision on which outputs to activate/deactivate based on the information

it has on both system-wide and local safety alarm state.

After the function definitions is a final section of code which initialises the node on start-up.

First, the node listens for an alarm state broadcast packet sent from the core, which it can then

take and store the I.P. address of the core from for later transmissions back to the core. This

“discovery” process allows for the core I.P. address to not be hard-coded into the node program,

allowing the node to adapt to changes in the network structure. After this, the pins are

20

Fig

ure

8:

Flo

w c

ha

rt s

ho

win

g t

he

pro

cess

im

ple

men

ted

by

the

nod

e so

ftw

are

21

configured for either input or output use depending on the values coded into the “pinmap”, and

finally all three threads are started.

The program for the core was again written in Python, and begins by defining some global

variables to store the system state. The core also uses an implementation of the Queue class;

this time a LIFO queue is used as a system log to store events for reporting to the user. A LIFO

queue was chosen so that events are presented to the user in reverse chronological order, with

most recent events appearing at the top of the log. The program is once again split into three

threads, the first of which is a monitoring thread. This function begins by creating a TCP socket

on the node to core port (9431), then enters an endless loop to wait for the receipt of a packet.

Once a packet has been received, the packet is decoded to retrieve the message, and the message

split into its parts for processing. The core then follows the process illustrated in figure 9 to

Figure 9: Flow chart describing the process for determining system alarm state

22

determine whether or not to set the global alarm flag as active. In all cases, any received event

is added to the system log.

The next thread deals with alarm messaging, which sends a broadcast packet across the network

to all nodes every second with an event code describing the system status: “029” for not-in-

alarm, “021” for a silenced alarm and “020” for a full alarm. It was decided to use a UDP

broadcast packet as opposed to a TCP unicast packet because by using a unicast packet, there

would need to exist a data store of the addresses of every node. This store would need to be

queried to get a list of destination addresses, and then a packet would need to be individually

transmitted to every destination in turn. This would cause the process time to increases linearly

as the number of nodes on the network grows and could potentially cause a delay in getting an

alarm message to nodes further down the list. Also, a hanging transmission to one node could

further hold up the announcement of an alarm state to further nodes. Although UDP is not as

reliable as TCP owing to the lack of packet receipt confirmation, it was decided this could be

overcome by broadcasting the state of the system every second, with the chance of a node

missing subsequent transmissions being very small so in a worst case scenario there may be a

one or two second delay in a node receiving an alarm notification.

The final thread handles the user interface, which is split over a number of functions for each

section of the interface. When initialised, the thread calls the UI_login function to display a

login screen to the user and the current system armed or disarmed state, shown in figure 10.

After logging in, the user is presented with one of two menus: the in-alarm menu is displayed

when the system is in an alarm state (figure 11); the normal menu when the system is in a

normal, non-alarm state (figure 12). The final view available to the user is the system log,

shown in figure 13, which prints out any events that have occurred since the last time the log

was accessed.

Figure 10: Login screen

23

Figure 11: In-alarm menu

Figure 12: Normal menu

Figure 13: System log

5. Description of Final Constructed Project

5.1. Final Constructed Product

The end result of the project was a working implementation of the communication technology

for a new type of alarm system comprising of an Ethernet connected network of devices,

designated as a single core device and multiple node devices, using a newly developed protocol

to communicate alarm events from the nodes to the core and vice versa. The node was

24

implemented using a Raspberry Pi connected to the network via a Wi-Fi connection and the

sensors simulated by passing a logic high voltage to the node inputs, and the alarm devices

(sounders, strobe lights etc.) simulated by connecting an LED to the output pin. The core was

simulated by running the core Python script on a Windows PC command line and the PC was

connected to the network using a wired Ethernet connection.

As shown in figure 14, the connections to the Raspberry Pi were implemented for the purpose

of prototyping by using a series of cables with female jumper connectors on one end to

connect to the GPIO pins, and connected into a strip of terminal block at the other end. Each

cable was then connected individually through 49.9 ohm current limiting resistors and then

left open to connect a 3.3v voltage level to simulate a logic high state.

Figure 14: Image showing the connections made to the GPIO pins of the Raspberry Pi

A series of tests were conducted to verify the requirements of the system had been met in full,

and as can be seen by the test details in figure 15, all tests produced the expected results,

demonstrating the system meets the requirements set for the project.

25

Figure 15: Table showing test carried out on system and their outcomes

Test Case System

armed?

Expected

Response

Actual Response Notes Pass/Fail

Safety

alarm

activated

Disarmed All outputs

activated

Event logged

in UI.

Node LED

activated

UI displays

“SYSTEM IN

ALARM”

Log prints

“Fire (smoke)

detected”

Tested using

input two,

which in the

simulated set up

was designated

a fire/smoke

input.

PASS

Safety

alarm

activated

Armed All outputs

activated

Event logged

in UI

Node LED

activated

UI displays

“SYSTEM IN

ALARM”

Log prints

“Fire (heat)

detected”

Tested using

input three,

which in the

simulated set up

was designated

a fire/heat input

PASS

Security

alarm

activated

Disarmed No response Node LED not

activated

UI gave no

indication of

alarm state

Log contained

no events

Tested using

input one, which

in the simulated

set up was

designated a

motion input

PASS

Security

alarm

activated

Armed All outputs

activated

Event logged

in UI

Node LED

activated

UI displays

“SYSTEM IN

ALARM”

Log prints

“Intruder

detected”

Tested using

input one, which

in the simulated

set up was

designated a

motion input

PASS

Safety

alarm

activated

with core

disabled

N/A All local

outputs

activated until

alarm

condition is

removed

Node LED

activated when

alarm

condition

present

LED switches

off when

alarm

condition

removed

Tested using

input four,

which in the

simulated set up

was designated

a carbon

monoxide input

PASS

26

Outputs

tested

through

“Test

Alarm”

function in

UI

Disarmed All outputs

activated

Nothing

logged in UI

All outputs

activated

No events

logged in UI

PASS

Outputs

tested in

silenced

state

N/A Audible

outputs

disabled

Light outputs

active

LED disabled

when set as

audible output

LED active

when set as

light output

To test this case,

two tests were

carried out, one

where the output

driving the LED

was set as an

audible output,

and another

where the output

was set as a

light output

PASS

5.2. Cost of Product

Owing to the fact the project requires further developments to form a production-ready product,

the cost will naturally be higher that what can currently be calculated for a complete system.

However, calculating the cost of the system so far will provide a good indication of whether

the final system could potentially be cheaper than current alarm system technology, and if the

current cost is cheaper, will show the margin of which the costs of further developments need

to stay within to make the overall system a cheaper alternative. The costs of the project so far

are detailed in the table below.

Part Cost (£)

Core

Raspberry Pi 20.35 (RS Components – 05/02/2015)

Raspberry Pi 5v power supply 5.89 (RS Components – 05/02/2015)

Total for Core 26.24

27

Raspberry Pi Node

Raspberry Pi 20.35 (RS Components – 05/02/2015)

Raspberry Pi 5v power supply 5.89 (RS Components – 05/02/2015)

5x 51Ω resistor 5% 0.0448 (Farnell – 28/04/2015)

Total for Raspberry Pi Node 26.28

PIC Node

PIC18F67J60 3.59 (Farnell – 28/04/2015)

8x 0.1µF 50V ceramic capacitor 0.2472 (Farnell – 28/04/2015)

1x 25MHz crystal oscillator 0.438 (RS Components – 28/04/2015)

1x 10KΩ resistor 5% 0.028 (RS Components – 28/04/2015)

1x470Ω resistor 1% 0.05 (RS Components – 28/04/2015)

6x 49.9Ω resistor 1% 0.3 (RS Components – 28/04/2015)

2.26kΩ resistor 1% 0.01 (RS Components – 28/04/2015)

Bel Fuse Inc L829-1X1T-91 4.27 (Digikey 28/04/2015)

Total for PIC Node 8.94

As explained, these cost calculations are provided purely as an indication of costs to this point

in development.

6. Discussion and Conclusions

This project has laid solid foundations for the development of a completely I.P.-based

combined safety and security system. Over the course of the project, a new protocol has been

designed and developed for the communication of alarm events between multiple devices on a

network, and it has been shown how the communication side of the system can be implemented

using Raspberry Pi devices for both the core and the node, and the hardware design work has

been completed for the circuitry that could implement the node device using a PIC18F67J60

microprocessor.

28

6.1. Comparison of Costs of New System vs. Industry Standard

For indicative purposes, the cost calculations previously stated were used to provide an

estimated cost of an eight zone system and a two hundred zone system, and compared with the

cost of systems currently available on the market. To provide such a comparison, a quotation

was obtained from an independent security company, PCB Security Systems Ltd. (Included in

appendix B), and the comparison is detailed as follows:

8 zone system: To implement an 8 zone system using this project’s technology, one

core and eight nodes would be required, connected using a 16-port switch:

o TP-Link TL-SF1016D 16-port switch - £15.88 (Comms-Express.com accessed

28/04/2015)

o 8 PIC Nodes – £71.52

o 1 Core – £26.24

o Total Cost for IP system: £113.64

o Cost from Quotation: £142

200 zone system: To implement a 200 zone system using this project’s technology, one

core and 200 nodes would be required, connected using four 48-port switches and one

16-port switch:

o TP-Link TL-SF1016D 16-port switch - £15.88 (Comms-Express.com accessed

28/04/2015)

o 4x TP-Link TL-SF1048 48-port switch - £339.92 (Comms-Express.com

accessed 28/04/2015)

o 1 Core - £26.24

o 200 PIC Nodes - £1788

o Total Cost for IP system - £2170.04

o Cost from Quotation - £4293.00

Again, it must be stressed that the cost calculations provided are purely for the purposes of

giving an indication to potential cost savings, and there are a number of factors that would need

to be considered for an accurate price comparison such as:

o Bulk production would enable lower parts cost

o Production costs have not been included

29

o PCB printing costs have not been included

o There are further parts required to be added before the system is production ready

o The quotation price will include a profit margin from manufacturer to supplier

However, these comparisons would seem to indicate that there is potential for this system to

be a cheaper alternative to a system currently available on the market when used for a large

scale system, but this would need to be assessed further once further developments have been

carried out.

6.2. Further Developments for a Production-Ready Product

The project has developed a fully functioning backbone that after some further developments

could enter production as a complete I.P.-based combined security and safety alarm system.

Firstly from the point of security, as it is currently designed, the system does not monitor the

health of the connection between the core and nodes, therefore it would be possible to sever

the physical connection between the core and a node, and the core would not detect this and

alert the user. Therefore developments to the software should be made to monitor the

connection and alert the user in the event of a communication failure.

The next step for developing node devices would be to design the circuitry to physically sense

alarm conditions, such as fire or motion, to feed into the inputs of the node device. The

Raspberry Pi used to implement the node device in this project was powered by a mains to

micro USB +5v power supply, which in a production environment would not be practical,

owing to the fact that detection devices are commonly mounted at ceiling level, and this would

therefore need a mains power socket located at the site of installation of every node. It is

recommended that research is carried out into using Power over Ethernet (PoE) technology,

which could potentially supply power to the node through the network infrastructure, enabling

one cable to be used for both communication and power supply.

The last main development required would be for an interactive core device; the current

implementation of the core is only interactive through the command line, so a graphical user

interface (GUI) needs to be developed and some additional hardware added to the core to allow

the user to interact with and operate the system.

30

7. Project Management, Consideration of

Sustainability and Health and Safety

7.1. Project Management

A number of measures were taken to manage the tasks for the project and ensure the project

remained on track. Firstly, Microsoft Project was used to plan out the tasks required for the

project, in the form of a task list and a Gantt chart, displayed in figure 16. These were referred

to regularly throughout the project, and updated where tasks were completed early or late, to

ensure time was allocated and used as efficiently as possible. Regular meetings were also held

with the project supervisor, Prof. C. David Wright, to discuss project progress and gain advice

where there were obstacles that needed to be overcome. A project risk assessment was also

carried out, shown in figure 17, to attempt to foresee any problems that may occur and pre-plan

how they can be resolved with minimal impact on the project timeline.

7.2. Sustainability

Environmental impacts were considered throughout this project in a number of ways. Firstly,

circuit designs were developed to minimise material usage, such as forming a PCB design that

used the smallest amount of board as possible. Also, where additional hardware was developed,

such as the additional circuitry for connecting to the GPIO pins of the Raspberry Pi,

components that were already to hand were used (49.9Ω resistors), rather than ordering new

parts. Where possible, all parts were sourced from UK-based suppliers to minimise the

environment impact of shipping packages, only one part had to be ordered from abroad which

was the SMT-to-DIP adapter for the PIC which was imported from Canada.

31

Fig

ure

16

: G

an

tt c

ha

rt o

f p

roje

ct t

imel

ine

32

Figure 17: Project Risk Assessment

ID Risk item Effect Cause

Lik

elih

oo

d

Sev

erit

y

Imp

orta

nce

Action to minimise risk

1 Parts being

delayed

Delays the

manufacture phase

Supply delays 2 2 Low Parts will be ordered before

PCB design but after circuit

design. Parts not needed until

after circuit design. If parts are

late, software design can be

worked on early.

2 Parts being

blown

Delays while parts are

replaced

Incorrect

polarity/static

discharge

2 2 Medium Inexpensive parts will have

spares ordered. Care will be

taken to ground self before

working with components

3 Lab

unavailability

Unable to solder

PCB/program pic

Not planning

sessions

1 3 High All lab sessions will be pre

planned and scheduled to ensure

facilities will be available.

7.3. Health and Safety

A risk assessment was carried out for this project to identify any areas where there was a

potential for injury or damage, and this was used to plan how the risk could be managed and

reduced to as low level as possible. The risk assessment is shown in the table below.

ID Risk item Effect Cause

Lik

elih

oo

d (

1 l

ow

– 5

hig

h)

Sev

erit

y (

1 l

ow

– 5

hig

h)

Imp

orta

nce

Action to minimise risk

1 Electrocution Personal

injury/death

Incorrect use of

power supply

equipment

1 5 5 A maximum of 5 volts is required for the

electronics in this project, so a low voltage

power supply with a valid electrical test

certificate will be used to deliver this low

voltage. Electronic work will be carried out

in the lab where circuit protection exists to

minimise this risk.

2 Burns from

soldering iron

Personal

Injury

Improper use of

soldering iron

2 3 6 The work area must be clear when using the

equipment to ensure the conditions are as

safe as possible

3 Fire from

soldering iron

Fire damage Improper use of

soldering iron

1 5 5 The work area must be clear when using the

equipment to ensure the conditions are as

safe as possible

4 Injury from

wire cutting

equipment

Personal

Injury

Improper use of

tools

1 1 1 Extra care must be taken at all times when

using sharp tools

33

References

[1] Donnelly, Karen C. S. (1992). Domestic Security: The Holmes Burglar Alarm Telegraph,

1853-1876. (Masters Thesis). University of Pennsylvania, Philadelphia, PA.

[2] Harris, Tom. (2001) How Burglar Alarms Work [Online] Available from:

http://home.howstuffworks.com/home-improvement/household-safety/security/burglar-

alarm.htm [Accessed 26th March 2015]

[3] Boudreaux, R (2012) The Web of Things: A web-connected world of smart devices

[Online] Available from: http://www.techrepublic.com/blog/web-designer/the-web-of-

things-a-web-connected-world-of-smart-devices/ [Accessed 26th March 2015]

[4] Verry, Tim (2012) What is the Raspberry Pi? [Online] Available from:

http://www.extremetech.com/computing/124317-what-is-raspberry-pi-2 [Accessed: 14th

February 2015].

[5] Raspberry Pi (Undated) Model B [Online] Available from:

https://www.raspberrypi.org/products/model-b/ [Accessed: 14th February 2015].

[6] Raspbian (Undated) Welcome to Raspbian [Online] Available from http://raspbian.org

[Accessed: 14th February 2015].

[7] Microchip (Undated) PIC18F97J60 Family [Online] Available from

http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en026439

[Accessed 25th February 2015]

[8] Mitchell, Bradley (Undated) What is a Network Protocol? [Online] Available from

http://compnetworking.about.com/od/networkprotocols/g/protocols.htm [Accessed 3rd

March 2015]

[9] Honey, G. (2007) Intruder Alarms. Third Edition. Oxford: Elsevier

[10] Ademco (2012) Ademco Contact ID Reporting [Online] Available from

http://library.ademconet.com/MWT/fs2/685/List-of-Contact-ID-codes.PDF [Accessed

15th March 2015]

[11] Python Software Foundation (2015) Queue – A Synchronised Queue Class [Online]

Available from https://docs.python.org/2/library/queue.html [Accessed 20th March

2015]

Appendices

Appendices available on request from Prof. C. D. Wright:

APPENDIX A: Software source code

APPENDIX B: Quotation from PCB Security Systems Ltd.