Continuation of QNX Based Flood Management System

QNX BASED FIRE AND FLOOD MANGEMENT SYSTEM
QNX BASED FIRE AND

FLOOD MANAGEMENT SYSTEM
Project Report
Project Guide: Syndicate:

Lt Cdr P K Roy Lt Manjunath R(52174-A))
Lt Ranjith R (52158-R)
Lt Anish Rajan(52160-W)
INS Valsura
Certificate of Merit
This is to certify that the under-mentioned officers of O-147 have successfully completed
the project “QNX BASED FLOOD MANAGEMENT SYSYTEM” and have been able
to achieve the desired results as a partial fulfillment of requirements for “L”
specialization course at INS Valsura.
Lt Manjunath R(52174-A))
Lt Ranjith R(52158-R)
Lt Anish Rajan(52160-W)
The project report compiled by them is an indication of the successful completion of the
project under my guidance.
(P K Roy)
Lieutenant Commander
Project Guide
INS Valsura
ACKNOWLEDGEMENT
We sincerely acknowledge the invaluable guidance and help of Lt Cdr P K Roy, without
whom this project would not have been completed. His presence throughout the day and
also in off working hours helped us tide over many difficult situations.
In the end we would like to express our gratitude to the staff of Faculty of
Training Projects and also to all the people who have been associated with our project
directly or indirectly, specifically for provision of resources and have contributed to its
successful completion.
Lt Manjunath R(52174-A)
Lt Ranjith R(52158-R)
Lt Anish rajan(52160-W)
INS Valsura
PREFACE
Over a period of time it has been observed that the available system for fire
detection is fast, however, the reaction time in carrying out any action is very large. An
operator manning the DCHQ is required to have absolute knowledge of not only the
whereabouts of the ship’s equipments and of course but also what actions to be taken.
Kill cards are the easiest access to any information he can gather and this most of the
time takes a large amount of time.
The primary requirement of a ships firefighting system is faster response,
minimum latency and a reliable system The idea of Automated Fire and flood Detection
and management System was evolved thus.
Here we have developed a strap on system that can be directly interfaced to the
existing fire detection system onboard. The input from the signals that come to the LED’s
on the Main Control Panel is tapped out to be input to the data acquisition modules
(ADAM4051). These analog signals are converted to digital signal given to the computer
via the RS232 protocol.
The software has been designed around a real time platform keeping in mind that
in case of a fire due to explosion every micro-second counts. Hence a Real time
Operating System (RTOS) is the only way ahead which can solve the concurrent
evolutions in real time with minimum system latency.
The project has been designed based on the Delhi class of ships and fed with all
the data of this ship. The database has been made in MS Access. It can display all the
essential details in case of fire or flood at the click of a mouse. The operator can remotely
perform actions like crash stop ventilation, sound an alarm etc
This system has a large number of advantages such as instant compartment
indication, easy data access; instant instructions to the fire fighters, LAN based remote
control etc.
The project can be further extended to control gas tight integrity of ships
remotely.
INS Valsura
1. CONTENTS
Chapter 1 Introduction 1.1

Chapter 2 Overview
2.1 Problem Definition 2.1
2.2 RTOS v/s GPOS 2.2
2.3 Why QNX? 2.4
Chapter 3 Hardware Description
3.1 Data Acquisition Module 3.1
3.2 Compartment Simulator 3.5
3.3 Operator console 3.9
3.4 Wiring diagram 3.10
Chapter 4 Software Version 1.00 Flow Chart
4.1 Main Window code 4.1
4.2 Group window code 4.2
4.3 Opening/closing fan/alarm 4.3
Chapter 5 Potential and Outlook
5.1 Future Scope 5.1
5.2 Conclusion 5.2
Bibliography
Appendices
AFSM Software Version 1.00 Source Code
INS Valsura
Introduction
1. The purpose of Automated Firefighting System is to quickly detect and prompt the
fire in its incipient stage to enable its control as early as possible, thus saving
extensive damage. In a conventional Fire Alarm System onboard a ship fire in a
compartment is sensed by the fire sensors located in the compartments. These give
signals in the form of glowing LED’s against the compartment number. The further
actions rest with the operator who has to go through the Kill Cards to initiate the
necessary actions. This leads to considerable amount of time loss.
2. The application we have developed is a strap on system that can be directly interfaced
to the existing fire detection system onboard. The input from the fire sensors is given
as input to the Data Acquisition modules. These Data Acquisition modules feed the
digital signals to a computer operating on real time platform viz QNX via RS 232
protocol. The system incorporates features in which the operator gets an instant
indication of the area of fire. The operator can further take actions like sounding an
alarm, crash stop ventilation etc. even the kill cards of all compartments are at his
disposal on a click of mouse.
3. The application is developed in the Integrated Development Environment (IDE) using

Photon Application Builder (PhAB).
4. The purpose of Automatic Fire and flood Detection System is to detect the fire
and flood in its incipient stage to enable its control using local fire extinguishers located
nearby, thus saving extensive damage due to fire. A conventional Fire Alarm System
onboard a ship basically consists of the following:
• Fire and flood Alarm Control Panel.
• Fire,flood Detectors/sensors of various types and
• Auxiliary Equipment and Accessories. (Optional)
• Electrical Wiring for interconnecting various equipments.

INS Valsura
An alarm is generated by the detectors/sensors, which actuated due to fire and thus
generates an audio visual alarm on the Main Control Panel. The system also consists of
various optional Auxiliary Equipment and Accessories such as Repeater Control Panels,
Zonal Local Control Panels, Mimic Panes, Manual Call Points, and Response Indicators.
Electronic Hooters, Electronic Hooters with Flasher Unit etc., including various
accessories such as detector mounting boxes, shock mounts, equipment fixing hardware
etc. for installation of various system components. All the equipment such as Control
Panels, Fire detectors, and Auxiliary equipment are interconnected by means of Electrical
Wiring.
5. The project has been designed based on the Delhi class of ship and fed with all the
data accordingly. The operator gets an instant indication of the compartment in which the
fire takes place. It can display all the essential details of the concerned compartment at
the click of a mouse. It provides recommendations to the operator regarding actions to be
taken. The operator can remotely perform actions like crash stop ventilation, sound an
alarm etc. Further more the system can also be controlled/viewed remotely from a remote
location over the ships existing internal network.
INS Valsura
2
Overview
INS Valsura
2.1 Problem Definition
1. The objective of the project undertaken by our syndicate was to integrate and design a
flood management system with the present fire fighting mate system which is
reliable, fast and required minimum re-engineering when installing onboard ships
2. Our first step was evaluation of the problem and finding a suitable platform to
develop the system keeping in mind the equipments deployed in the field.
3. We also had to study the compatibility of the data Acquisition module with the
environment so that present and future needs could be met.
4. An iterative process led us to zeroing on QNX, which is a RTOS, to develop the

application
5. Next we had to study the hardware control with the environment. We started with the
black box concept in which we used two PC’s to communicate with each other via the
hardware. For the initial checks we used both the PC’s on windows platform. We then
graduated to communication with QNX as one of the platform, windows being the
other. Finally we established communication with both PC’s working on QNX
platforms.
6. Once the hardware compatibility was achieved with the QNX environment we had to
develop a Human-Machine Interface Application. We worked in the Integrated
Development Environment and used Photon Application Builder for the same.
INS Valsura
2.2 RTOS v/s GPOS
The services provided by an RTOS make many computing problems easier to solve,
particularly when multiple activities compete for a system’s resources. Consider, for
instance, a system where users expect immediate response to input. With an RTOS, a
developer can guarantee that operations initiated by the user will execute in preference to
other system activities, unless a more important activity must execute first.
2.2.1 Speed without the expense

An RTOS designed to extract extremely fast (and predictable) response times from
lower-end hardware offers a serious economic advantage.
2.2.2 Task scheduling

In a GPOS, the scheduler typically uses a fairness policy to dispatch threads and
processes onto the CPU. Such a policy enables the high overall throughput required
by desktop and server applications, but offers no guarantees that high-priority, time-
critical threads will execute in preference to lower-priority threads. For instance, a
GPOS may decay the priority assigned to a high-priority thread, or otherwise
dynamically adjust the priority in the interest of fairness to other threads in the
system. A high-priority thread can, as a consequence, be preempted by threads of
lower priority.
In an RTOS, on the other hand, threads execute in order of their priority. If a high-
priority thread becomes ready to run, it will, within a small and bounded time
interval, take over the CPU from any lower-priority thread that may be executing.
Moreover, the high-priority thread can run uninterrupted until it has finished what it
needs to do – unless, of course, it is preempted by an even higher priority thread. This
approach is known as priority-based preemptive scheduling,
2.2.3 Preemptible kernel
INS Valsura
For most GPOSs, the OS kernel is not preemptible. Consequently, a high-priority user
thread can never preempt a kernel call, but must instead wait for the entire call to
complete – even if the call was invoked by the lowest-priority process in the system.
In an RTOS, on the other hand, kernel operations are preemptible.
Fig 2.1
2.2.4 OS customization
An RTOS based on a microkernel design can make the job of OS customization
fundamentally easier to achieve. In a microkernel RTOS, only a small core of
fundamental OS services (such as signals, timers, and scheduling) reside in the kernel
itself. All other components (such as drivers, file systems, protocol stacks, and
applications) run outside the kernel as separate, memory-protected processes (Figure
2.1). As a result, developing custom drivers and other application-specific OS
extensions does not require specialized kernel debuggers.
2.2.5 Fault isolation

The architecture described above also provides superior fault isolation. If a driver,
protocol stack, or other system service fails, it can do so without corrupting other
services or the OS kernel. In fact, software watchdogs can continuously monitor for
such events and restart the offending service dynamically without resetting the entire
system or involving the user in any way. Likewise, drivers and other services can be
stopped, started, or upgraded dynamically, again without a system shutdown.
INS Valsura
Why QNX for Embedded Systems?
1. The main responsibility of an operating system is to manage a computer’s resources.

All activities in the system— scheduling application programs, writing files to disk,
sending data across a network, and so on —should function together as seamlessly
and transparently as possible.
2. Some environments call for more rigorous resource management and scheduling than
others. Realtime applications, for instance, depend on the OS to handle multiple
events and to ensure that the system responds to those events within predictable time
limits.
3. QNX is ideal for embedded realtime applications. It can be scaled to very small sizes
and provides multitasking, threads, priority-driven preemptive scheduling, and fast
context-switching—all essential ingredients of an embedded realtime system.
Moreover, QNX delivers these capabilities with a POSIX-standard API; there’s no
need to forgo standards in order to achieve a small OS.
4. QNX is also remarkably flexible. It can customize the OS to meet the needs of their
applications. From a “bare-bones” configuration of a microkernel with a few small
modules to a full-blown network-wide system equipped to serve hundreds of users,
QNX lets us set up our system to use only those resources we require to tackle the job
at hand.
5. QNX achieves its unique degree of efficiency, modularity, and simplicity through two
fundamental principles:
• microkernel architecture
• message-based interprocess communication
INS Valsura
3
Hardware Description
INS Valsura
3.1 Data Acquisition Module
The ADAM Series is a set of intelligent sensor-to-computer interface modules containing

built-in microprocessor. They are remotely controlled through a set of commands issued
in ASCII format and transmitted in RS-485 protocol. They provide signal conditioning,
isolation, ranging, data comparison, and digital communication functions. Some modules
provide digital I/O lines for controlling relays and TTL devices. We have used three
types of ADAM modules in this project.
4055
4520
4051
Fig 3.1 Data Acquisition Modules
As in figure we used three ADAM 4051, one ADAM 4055 and one ADAM 4520
modules. After getting the signal from the fire detection sensor, Data acquisition module
sends the signal to the console panel which houses the system software.
3.1.1 Software Configuration and Calibration

ADAM modules contain no pots or switches to set. By issuing a command from the
host to the computer, you can change the input module to accept several ranges of
voltage input. All the module configuration parameters including I/O address, speed,
parity, HI and LO alarm, calibration parameters setting may be set remotely. Remote
configuration can be done by using either the provided menu- based software (only
for windows platform) or the command sets configuration and calibration command.
INS Valsura
3.1.2 Power requirements

Although the modules are designed for standard industrial unregulated 24V DC
power supply they accept any power unit that supplies power between the range of +
10 V to +30 V DC. The power supply ripple must be limited between a 5V peak to
peak and the immediate ripple voltage must be maintained between + 10 to + 30V
DC.
Fig 3.2 Power Supply unit
3.1.3 System requirements to set up an ADAM network

The following list gives an overview of what is to needed to setup, install and
configure the ADAM environment.
(a) ADAM modules

(b) A console that can output ASCII character with an RB 232C or RS 485 port.
(c) Power supply for the ADAM modules
(d) ADAM Isolated RS 232/ RS484 Converter
3.1.4 Console
Any terminal that can output and ASCII format over either RS 232 or RS 485 can be
connected as a console. When only RS 232 is available, an ADAM RS 232/485
Converter is required to transform the signals to the correct RS 485 protocol.
3.1.5 ADAM Communication Speed

In ADAM Series, the baud rate can be configured from 1200 bps to 38.4 Kbps and
the baud rate must be same for all the modules in the network.
3.1.6 Various modules used in the project
INS Valsura
(a) ADAM- 4051 16 Channel Isolated Digital Input Module

The ADAM- 4051 is a 16 Channel Isolated Digital Input built with 2500V
optical isolation. Different from the other modules it can accept 10 to 50 V inputs to
fit various digital signals such as 12 V, 24V, 48V. The users can read the current
status from the LED indicators on the front panel.
(b) ADAM- 4055 16 Channel Isolated Digital I/O Module

The ADAM- 4055 offers 8 channel isolated digital input and 8 Channel
Isolated Digital Input for critical applications. The inputs accept 10 to 50 V and
output supply 5 to 40 volts open collector. Considered to be user friendly, the ADAM
4055 is also built in with a LED input for easy status reading.
(c) ADAM-4520 RS232/RS485 Converter

The ADAM-4520 RS232/RS485 Converter is used to convert the input data into
computer language. Its connection is shown.
console
Fig 3.3 ADAM-4520 RS 232/ RS 485 Converter
Before placing a module in an existing network, the module should be configured.

Though all the modules are initially configured at the factory, the baud rates have to
be checked.
INS Valsura
3.1.7 ADAM 4000 Series Command set
To avoid communication conflicts when several devices try to send data at the same
time, all actions are instigated by the console. The basic form is a command/response
protocol with the console initiating the sequence. When modules are not transmitting
they are in listen mode. The console issues a command to a module with a specified
address and waits a certain amount of time for the module to respond. If no response
arrives, a timeout aborts the sequence and returns control to the console.
Changing ADAM’s configuration might require the module to perform auto

calibration before changes can take effect. Especially when changing the range, the
module has to perform all stages of auto calibration that it also performs when
booted. When this process is under way, the module does not respond to any other
commands. The command set includes the exact delays that might occur when
modules are reconfigured.
NOTE: ALL COMMANDS SHOULD BE ISSUED IN UPPERCASE CHARACTERS!

(see Appendices)
3.1.8 Connectivity and Programming
ADAM modules can connect to and communicate with all computers and terminals.
They use RS-485 transmission standards, and communicate with ASCII format
commands. The command set for every module type consists of approximately ten
different commands. The command set for input modules is larger because it
incorporates alarm functions. All communications to and from the module are
performed in ASCII, which means that ADAM modules can be programmed in
virtually any high-level language.
INS Valsura
3.1.9 Applications
• Remote data acquisition

• Process monitoring
• Industrial process control
• Energy managment
• Supervisory control
• Security systems
• Laboratory automation
• Building automation
• Product testing
• Direct digital control
3.2 Compartment Simulator
3.2.1 THE VARIOUS TYPES OF SENSORS
FIRE DETECTORS / SENSORS
3.2.1.1 Ionization Smoke Detector
Four smoke detectors are suitable for installation within the closed spaces. The
quantity of detectors is based on the individual requirement. These detectors give an
alarm when pre determined level of smoke density is reached within the detector
chamber head. The signal on the MCP is given by rise in detector current from 20
micro amps. approx. to 15 to 20 milli-amp., when the detector actuates. These
detectors are more sensitive to smaller particles of smoke. They respond much ‘faster
for smoke particle size between 10 microns and .01 microns. They are also more
sensitive for flaming fires.
INS Valsura
3.2.1.2 PHOTO-ELECTRIC SMOKE DETECTOR
Photoelectric smoke detectors are suitable for installation within the closed spaces.
The quantity of detectors is based on the individual requirement. These detectors give
an alarm when predetermined level of smoke density is reached within the detector
head. Fire Alarm on the panel is given by change in current from 35 micro amps. to
15 milli amps, when actuated. These detectors are more sensitive to larger particles of
smoke. They typically respond to smoke particle sizes above 1 micron approx. They
respond much faster to smoldering fire.
3.2.1.3 Functional Description of Photoelectric Smoke Detector:
The photoelectric detector comprises of an infrared LED light source and silicon
photo diode used as ‘receiving’ element. Normally, the receiving element receives no
light from the pulsating light source. When smoke enters the detector, the light is
scattered on to the receiving element. This element then determines the amount of
smoke in the detector head by measuring the amount of scattered light it receives. If
the amount of scattered light exceeds a certain preset level for a number of successive
pulses, a fire signal is transmitted. This method greatly reduces the incidences of false
alarms.
3.2.1.4 ULTRA VIOLET FLAME DETECTOR
UV Flame detectors are suitable for installation within the closed spaces. The
quantity of detectors is based on the individual requirement. These detectors give an
alarm when it receives ultra violet light radiated by a flame for pre-determined time.
The signal on the panel is given by change in current from approximately 200 micro
amps. to 20 milli amp when actuated.
INS Valsura
3.2.1.5 Functional Description of Ultra Violet Flame Detector:
Ultra violet Flame detectors have a UV-tron, which monitors the minute ultra violet
light contained in flames. The detector employs a ‘counter’ circuit to overcome
unwanted triggering, due to .cosmic radiation or lighting. The UV-tron tube consists
of anode and cathode which are positioned face to face’. The tube is filled with
‘argon’ gas. A high voltage is applied between the two electrodes. With sufficient
radiation of UV rays from the flame, the cathode of UV-tron emits photo electrons in
large quantity. When the current flowing through the tube sufficiently increases due
to “avalanche” of electrons, UV-tron repeatedly produces short pulses. The electronic
circuit analyses these pulses and gives an alarm when predetermined number of
pulses are counted in unit time. It is essential to have “line of sight’ between the
flame and the detector, for the detector to give an alarm.
3.2.1.6 MANUAL CALL POINT
When fire is noticed by persons available in the vicinity of the fire, the call point
nearest to the site of fire can be actuated manually by breaking the glass with the help
of hammer attached to it. Actuation of the call point initiates an alarm on the MCP.
An alarm is created on the MOP by change in current from ‘no current’ to 15
milliAmp. Current when actuated. The call points are installed in parallel to the fire
detectors in the same loop.
3.2.1.7 Functional Description of Manual Call Point
Controls & Indications on Manual Call Point:
‘Fire’ LED and Push Button Switch:
When the glass of the manual call point is broken, the push button, which s kept
depressed by the glass, is pushed forward (comes-out), As the push button is spring
INS Valsura
loaded, it immediately pushes the switch out. With this action, ‘red LED’ on the call
point glows, indicating initiation of alarm on the MCP.
3.2.1.8 ELECTRONIC HOOTER
2.6.7.1 Use of Electronic hooter is to give an external alarm within the zone of fire, in
the event of fire. The Electronic hooter receives 24V DC supply from the MCP, when
an alarm is initiated in respective zone by fire detector or manual call point.
3.2.1.9 Functional Description of Electronic hooter:
The audio alarm units are stand-alone, self oscillating type hooters which work on 24
supplies received from fire alarm control panel. Electronic hooter consists of an
oscillator circuit, amplifier circuit and a loud speaker all assembled into a suitable
housing.
When Hooter receives 24 VDC from the Main Control Panel, oscillator circuit
produces pulsed waveform oscillations. This waveform is modulated by a modulator
circuit on the PCB, due to which siren type audio alarm is heard through the speaker.
-
3.2.2 Ionization smoke detector

These detectors give an alarm when pre determined level of smoke density is reached
within the detector chamber head. The signal on the Data Acquisition module is given
by rise in detector current from 20 micro amps. approx to 15 to 20 milli-amp, when
the detector actuates. These detectors are more sensitive to smaller particles of smoke.
They respond much faster for smoke particle size between 10 microns and .01
microns. They are also more sensitive for flaming fires.
INS Valsura
3.2.3 Functional Description of ionization Smoke Detector:
This detector contains two sampling ionization chambers – outer and inner. While
smoke or invisible gases can infiltrate the outer chamber easily, the inner chamber is
considered to be ‘virtually’ closed. Both the chambers are ionized by a small
Americium 241 radio-active source and very small current flows in the chamber
circuit.
The presence of visible smoke or invisible gases alters the current flow in the outer
chamber and causes a change in the voltage ratio between the two chambers. This
difference is then amplified by the electronic circuitry and transmitted to the fire
alarm control unit to which it is connected. The compartment simulator which houses
the smoke sensor is shown in figure.
3.3 Operator Console
The operator console is more or less a PC which works on QNX platform and houses the
application software. The Data Acquisition Module is connected to the console through
Fig 3.5 Compartment Simulator
the RS-232 protocol i.e. COM1.
In case of fire in any compartment, software will get the signal from the Data Acquisition
module and consequently the red indication will be shown on the console panel. The
console panel operator can take the necessary actions just by clicking the mouse.
INS Valsura
Fig 3.6ASFM
ASFM Console
Console
3.5 Wiring diagram

1, 2, 3 and 4 are the relays. 1 and 2 are connected to the two fans respectively and are
used for switching them ON and OFF. Relays 3 and 4 are connected to light and alarm
unit respectively.
5 is ADAM – 4055. it is used for giving output to the 4 relays based on the input it gets
from ADAM – 4520.
6, 7 and 8 are ADAM – 4051. Each has 16 I/O lines and are connected to each of the
groups I, II and III of the application. Line DI6 of module 7 is connected to the
compartment simulator. Whenever fire is simulated in the simulator it sets the DI6 line
high.
9 is ADAM – 4520. It is RS 232/RS 485 converter. It accepts inputs from the console in
RS 232 format and converts in RS 485 format and distributes to the other ADAM
modules in the network.
INS Valsura
10 is the operator console. It operates on QNX platform and the application runs on it.
11 is the power supply unit. 3 power supply units are used one each for ADAM modules,
relays and the compartment simulator.
12 is the compartment simulator. It houses the smoke sensors. It is used for simulating
fire.
13 and 14 are the lights and alarm units used as indication to represent fire.
12 11
13 14
PS PS PS
Light Hooter +
_
Fan 1 Fan 2
1 2 3 4
10
Gnd
5 9
DI6
Data +
Data - Vs
Dgnd
6 7 8
INS Valsura
4
Software Version 1.00 Flow
chart
INS Valsura
4.1 Main Window

Start
Loop runs every 100ms
Open com port 1
Write $026\r to com port 1

(This causes ADAM module
02 to send states of I/O lines)
Read the input from com1 and

store in a buffer
Convert the 2nd, 3rd, 4th and 5th bit to

BCD format and store in another buffer
Check the contents of buffer
Change color
indication to
Is any bit =1
Green and display
‘NORMAL’
Change color indication to Red and

display ‘FIRE’
Close com port 1
INS Valsura
4.2 Group Window
Start
Loop runs every 100ms
Open com port 1
Write $026\r to com port 1

(This causes ADAM module
02 to send states of I/O lines)
Read the input from com1 and

store in a buffer
Convert the 2nd, 3rd, 4th and 5th bit to

BCD format and store in another buffer
Check the contents of each bit
Change color
indication to
Is the bit =1 Green against the
assigned
compartment
Change color indication to red

against the assigned compartment
Close com port 1
INS Valsura
4.3 Switching ON/OFF the Alarm/Ventilation Fan
Start
Open com port 1
Write ‘#041701\r’ to com port 1

(This causes the 17th line of module 04 to
go high)
Change color
Is the line high? indication to
Green
Change color indication to

red
Close com port 1
Stop
The above program will switch on the alarm. Alarm and Ventilation fans can be
switched ON/OFF in a similar way by changing the code to be sent. (See appendices)
INS Valsura
5
Potential and Outlook
INS Valsura
5.1 Future Scope
The aim of the project has been to develop a reliable fire fighting and flood
management system for use onboard Indian Naval Ships. This ASFM system also
provides the users of this system with all the useful data in case of an emergency scenario
instantaneously and also provides the user at a remote position with the controls required
to take effective and decisive action immediately.
The future scope of this project is multi fold.
Firstly, it could be actually implemented in its existing form onboard Indian
Naval Ships. This project has been designed for the Delhi Class of ships. Also since the
system has been designed as a strap on system it could be implemented without any
major changes to the ship or the existing set up on the ship.
Secondly, this ASFM system could be implemented on a touch screen. This
would make the system a little more expensive but it would save on the time required by
the user to react in case an emergency arises. It would also eliminate the need for a
keyboard and a mouse and the overall operation of the system become more user
friendly.
And finally, once all these additional units get incorporated into the ASFM
system, the system will be performing many operations simultaneously. In such a
scenario various tasks could be assigned priorities over the others e.g actions for certain
important compartments could be given higher priority etc. Thus scheduling could be
incorporated in the system to give priorities to certain processes. This would make the
system more reliable.
INS Valsura
5.2 Conclusion
The platform that we used for the project is one of the latest platforms on which
most of the latest weapon systems and modern equipment are based. We have used it
because of the many advantages it offers including reliability, stability, future
compatibility, faster speed among other things.
We have achieved the aim of constructing an ASFM system which is capable of
being installed onboard ships with the least amount of re- engineering involved. And this
system will greatly enhance the fire fighting capability of the ships.
For the construction of this project we have relied on in-house components which
have been salvaged from the spares present in the Faculty of Training Projects. This has
reduced the financial implication of our project to a great extent. But there has been a
great amount of hardware issues that had to be sorted out so as to get the ADAM Module
to interact with the system working on a QNX platform and also for the transfer of data
from the sensors and fan to the ADAM Module.
The prototype version of the software created by us also includes a test module to
detect and alert the user in case of any know defects. This software also facilitates the
control of the system over a network.
INS Valsura
Bibliography
1. http://www.qnx.com
2. http://www.advantech.com
3. ADAM-4000 User’s manual
4. IDE Users guide
5. Photon microGUI Programmer's Guide
6. http://www.google.com
7. http://www.openqnx.com
INS Valsura
Appendix A
ADAM-4051
ADAM-4051 16-channel Digital Input Module
Technical Specification of ADAM-4051
• Channel: 16 (4-channel/group)
• Optical Isolation: 2500 VDC
• Opto-isolator response time: 25 .s
• Over-voltage Protect: 70 VDC
• ESD (Electro Static Discharge): 2000 VDC
• LED Indicator: On: Active; Off: Non-active
• Input Voltage: Logic level 1: 10 ~ 50 V
Logic level 0: 3 V
• Power consumption: 1W
• I/O Connector Type: 13-pin plug-terminal*2
INS Valsura
ADAM-4055
ADAM-4055 16-channel Digital I/O Module
• Number of Input Channel: 8 (4-channel/group)

• Opto-isolator response time: 25 µs
• Over-voltage Protect: 70VDC
• ESD (Electro Static Discharge): 2000 VDC
• Input Voltage:
Dry Contact
Logic level 0: Close to GND
Logic level 1: Open
Wet Contact
Logic level 1: 10 ~ 50 V
Logic level 0: 3V
Dry Contact & Wet contact Selectable
• Number of Output Channel: 8 (8-channel/group)
• Opto-isolator response time: 25 µs
• Supply Voltage: Open Collector 5 ~ 40 VDC
• Sink Current: 200 mA max/channel
INS Valsura
• LED Indicator: On: Active Off: Non-active

• Power Consumption: 1W
• I/O Connector Type: 13-pin plug-terminal * 2
INS Valsura
ADAM-4051 Command Set Table
Command Command Name Command Description

Syntax
Sets the address, baud rate, and/or checksum status to a
%AANNTTCCFF Configuration
digital I/O module
Synchronized Orders all digital I/O modules to sample their input values
#**
sampling and store them in special registers
Configuration Returns the configuration parameters of a specified digital
$AA2
Status I/O module
Read Returns the value of a specified digital I/O module that
$AA4 synchronized was stored in the specified register after an #** command
data was issued
Indicates whether a specified digital I/O module was reset
$AA5 Reset status
after the last time that $AA5 command was issued
Returns the values of the digital I/O channel in the
$AA6 Digital data in
addressed module
ADAM-4055 Command Set Table
Command Command Name Command Description

Syntax
Sets the address, baud rate, and/or checksum status to a
%AANNTTCCFF Configuration
digital I/O module
Synchronized Orders all digital I/O modules to sample their input values
#**
sampling and store them in special registers
Configuration Returns the configuration parameters of a specified digital
$AA2
Status I/O module
Read Returns the value of a specified digital I/O module that
$AA4 synchronized was stored in the specified register after an #** command
data was issued
Indicates whether a specified digital I/O module was reset
$AA5 Reset status
after the last time that $AA5 command was issued
Returns the values of the digital I/O channel in the
$AA6 Digital data in
addressed module
Writes specified values to either a single channel or all
#AABB Digital data out
channels simultaneously
INS Valsura
ASFM Software Version 1.00 Source

code
INS Valsura
Main window code
/* Automated Ship borne Firefighting Mate */

/* Version 1.00 */
/* Standard headers */
#include <termios.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <hw/inout.h>
#include <string.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/neutrino.h>
/* Local headers */
#include "ablibs.h"
#include "abimport.h"
#include "proto.h"
extern int win_ctr;

extern PtWidget_t *win[5];
int
rd( PtWidget_t *widget, ApInfo_t *apinfo, PtCallbackInfo_t *cbinfo )
{
int fd;
int numRead=0;
int a1[6];
int i=0; /* counter */
int j=1; /* counter */
int flag =0;
int a2[6];
int d[16]; /* store the BCD vslues */
int x;
int z;
char b[7]={NULL};
char b1[7]={NULL}; /* buffer to store input */
char wr[]={"$026\r"}; /* buffer to store code to write to com1
*/
PtWidget_t *this_window;
/* eliminate 'unreferenced' warnings */

widget = widget, apinfo = apinfo, cbinfo = cbinfo;
/* Get a pointer to the current window. */

this_window = ApGetInstance( widget );
/* open com1 */
INS Valsura
fd = open("/dev/ser1", O_RDWR | O_NOCTTY | O_NDELAY );

delay(10); /* set delay */
/* write contents of buffer to com1 */

write(fd, wr, sizeof(wr));
delay(100);
while(fd!=-1)
{
memset(b1, 0, sizeof(b1));
/* read from com1 */

numRead = read(fd, b1, sizeof(b1));
delay(100);
for (i=0; i<=8; i++)

{
b[i] = b1[i];
}
/* remove the first bit input and store rest in buffer a1 */

i=0;
j=1;
while (i<6)
{
a1[i]=0;
a1[i] = b[j];
i++;
j++;
}
i=0;
while (i<6)
{
if (a1[i]==48)
a2[i]=0;
else
if (a1[i]==49)
a2[i]=1;
else
if (a1[i]==50)
a2[i]=2;
else
if (a1[i]==51)
a2[i]=3;
else
if (a1[i]==52)
a2[i]=4;
else
if (a1[i]==53)
a2[i]=5;
else
if (a1[i]==54)
a2[i]=6;
else
if (a1[i]==55)
a2[i]=7;
INS Valsura
else
if (a1[i]==56)
a2[i]=8;
else
if (a1[i]==57)
a2[i]=9;
else
if (a1[i]==65)
a2[i]=10;
else
if (a1[i]==66)
a2[i]=11;
else
if (a1[i]==67)
a2[i]=12;
else
if (a1[i]==68)
a2[i]=13;
else
if (a1[i]==69)
a2[i]=14;
else
if (a1[i]==70)
a2[i]=15;
i++;
/* convert the contents of buffer to BCD and store in buffer ‘d’*/

i=0;
j=0;
x= a2[0];
for (i=0 ;i<4 ;i++)

{
z=x%2;
x=x/2;
d[i]=z;
}
x= a2[1];
for (i=4 ;i<8 ;i++)
{
z=x%2;
x=x/2;
d[i]=z;
/* check for any high bit in buffer ‘d’ */

if (d[i] == 1)
{
flag=1;
}
}
if (flag==1)
INS Valsura
/* if flag is set change the indication to red */

PtSetResource(
ApGetWidgetPtr( this_window, ABN_ind1 ),
Pt_ARG_FILL_COLOR, Pg_RED, 0 );
}
flag=0;
x= a2[2];
for (i=8 ;i<12 ;i++)
{
z=x%2;
x=x/2;
d[i]=z;
if (d[i] == 1)
{
flag=1;
}
}
if (flag==1)
{
PtSetResource(
}
flag=0;
x= a2[3];
for (i=12 ;i<16 ;i++)
{
z=x%2;
x=x/2;
d[i]=z;
if (d[i] == 1)
{
flag=1;
}
}
if (flag==1)
{
PtSetResource(
}
flag=0;
for(i=0;i<16;i++)
{
INS Valsura
if (d[i] == 1)
{
flag=1;
}
}
if (flag==1)
{
PtSetResource(
ApGetWidgetPtr( this_window, ABN_clr3 ),
PtSetResource(
ApGetWidgetPtr( this_window, ABN_list ),
Pt_ARG_TEXT_STRING, "FIRE", 0);
}
else
{
PtSetResource(
ApGetWidgetPtr( this_window, ABN_clr3 ),
Pt_ARG_FILL_COLOR, Pg_GREEN, 0 );
PtSetResource(
ApGetWidgetPtr( this_window, ABN_list ),
Pt_ARG_TEXT_STRING, "NORMAL", 0);
}
/* close com1 */
close(fd);
return 0;
return( Pt_CONTINUE );
}
}
INS Valsura
Group window code

/* Version 1.00 */
#include <termios.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <hw/inout.h>
#include <string.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/neutrino.h>
/* Local headers */
#include "ablibs.h"
#include "proto.h"
extern int win_ctr;

extern PtWidget_t *win[5];
int
rd_gp1( PtWidget_t *widget, ApInfo_t *apinfo, PtCallbackInfo_t *cbinfo )
{
int fd;
int numRead=0;
int a1[6];
int i=0; /* counter */
int j=1; /* counter */
int flag =0;
int a2[6];
int d[16]; /* store the BCD vslues */
int x;
int z;
char b[7]={NULL};
char b1[7]={NULL}; /* buffer to store input */
char wr[]={"$026\r"}; /* buffer to store code to write to com1
*/
PtWidget_t *this_window;

/* Get a pointer to the current window. */

this_window = ApGetInstance( widget );
/* open com1 */
fd = open("/dev/ser1", O_RDWR | O_NOCTTY | O_NDELAY );
delay(10); /* set delay */
INS Valsura
/* write contents of buffer to com1 */

write(fd, wr, sizeof(wr));
delay(100);
while(fd!=-1)
{
memset(b1, 0, sizeof(b1));
/* read from com1 */

numRead = read(fd, b1, sizeof(b1));
delay(100);
for (i=0; i<=8; i++)

{
b[i] = b1[i];
}
/* remove the first bit input and store rest in buffer a1 */

i=0;
j=1;
while (i<6)
{
a1[i]=0;
a1[i] = b[j];
i++;
j++;
}
i=0;
while (i<6)
{
if (a1[i]==48)
a2[i]=0;
else
if (a1[i]==49)
a2[i]=1;
else
if (a1[i]==50)
a2[i]=2;
else
if (a1[i]==51)
a2[i]=3;
else
if (a1[i]==52)
a2[i]=4;
else
if (a1[i]==53)
a2[i]=5;
else
if (a1[i]==54)
a2[i]=6;
else
if (a1[i]==55)
a2[i]=7;
else
if (a1[i]==56)
INS Valsura
a2[i]=8;
else
if (a1[i]==57)
a2[i]=9;
else
if (a1[i]==65)
a2[i]=10;
else
if (a1[i]==66)
a2[i]=11;
else
if (a1[i]==67)
a2[i]=12;
else
if (a1[i]==68)
a2[i]=13;
else
if (a1[i]==69)
a2[i]=14;
else
if (a1[i]==70)
a2[i]=15;
i++;
/* convert the contents of buffer to BCD and store in buffer ‘d’*/

i=0;
j=0;
x= a2[0];
for (i=0 ;i<4 ;i++)

{
z=x%2;
x=x/2;
d[i]=z;
}
x= a2[1];
for (i=4 ;i<8 ;i++)
{
z=x%2;
x=x/2;
d[i]=z;
}
/* if any bit in ‘d’ high change color to red else green */

if (d[0]==1)
{
PtSetResource(
ApGetWidgetPtr( this_window, ABN_1_b ),
}
else
{
INS Valsura
PtSetResource(
}
if (d[1]==1)
{
PtSetResource(
ApGetWidgetPtr( this_window, ABN_1_d ),
}
else
{
PtSetResource(
}
if (d[2]==1)
{
PtSetResource(
ApGetWidgetPtr( this_window, ABN_1_d1 ),
}
else
{
PtSetResource(
}
if (d[3]==1)
{
PtSetResource(
}
else
{
PtSetResource(
}
if (d[4]==1)
{
PtSetResource(
}
else
{
PtSetResource(
}
INS Valsura
if (d[5]==1)
{
PtSetResource(
}
else
{
PtSetResource(
}
if (d[6]==1)
{
PtSetResource(
}
else
{
PtSetResource(
}
if (d[7]==1)
{
PtSetResource(
ApGetWidgetPtr( this_window, ABN_2_dk0 ),
}
else
{
PtSetResource(
ApGetWidgetPtr( this_window, ABN_2_dk0 ),
}
if (d[8]==1)
{
PtSetResource(
ApGetWidgetPtr( this_window, ABN_2_dkd ),
}
else
{
PtSetResource(
ApGetWidgetPtr( this_window, ABN_2_dkd ),
}
if (d[9]==1)
{
PtSetResource(
INS Valsura
}
else
{
PtSetResource(
}
if (d[10]==1)
{
PtSetResource(
}
else
{
PtSetResource(
}
if (d[11]==1)
{
PtSetResource(
}
else
{
PtSetResource(
}
if (d[12]==1)
{
PtSetResource(
}
else
{
PtSetResource(
}
if (d[13]==1)
{
PtSetResource(
ApGetWidgetPtr( this_window, ABN_1_e ),
}
else
{
PtSetResource(
INS Valsura
}
if (d[14]==1)
{
PtSetResource(
ApGetWidgetPtr( this_window, ABN_2_e00 ),
}
else
{
PtSetResource(
ApGetWidgetPtr( this_window, ABN_2_e00 ),
}
if (d[15]==1)
{
PtSetResource(
}
else
{
PtSetResource(
}
close(fd);
return 0;
}
}
INS Valsura
Switching ON Fan

/* Version 1.00 */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <fcntl.h>
/* Local headers */
#include "ablibs.h"
#include "proto.h"
int
alarm_code( PtWidget_t *widget, ApInfo_t *apinfo, PtCallbackInfo_t
*cbinfo )
char buffer[]={"#041400\r"};
int fd;

/* open com1 */
fd=open("/dev/ser1", O_RDWR | O_NOCTTY | O_NDELAY );
/* write #041401\r to com1. This sets the 14th line of 4th module
high. \r is for carriage return */
write(fd, buffer, sizeof(buffer));
/* close com1 */
close (fd);
return 0;
INS Valsura
INS Valsura

Continuation of QNX Based Flood Management System

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Continuation of QNX Based Flood Management System

Hochgeladen von

Copyright:

Verfügbare Formate

QNX BASED FIRE AND FLOOD MANGEMENT SYSTEM

QNX BASED FIRE AND

Project Guide: Syndicate:

Chapter 1 Introduction 1.1

3. The application is developed in the Integrated Development Environment (IDE) using

• Fire and flood Alarm Control Panel.

• Fire,flood Detectors/sensors of various types and

• Auxiliary Equipment and Accessories. (Optional)

• Electrical Wiring for interconnecting various equipments.

2.1 Problem Definition

4. An iterative process led us to zeroing on QNX, which is a RTOS, to develop the

2.2 RTOS v/s GPOS

2.2.1 Speed without the expense

2.2.2 Task scheduling

2.2.3 Preemptible kernel

2.2.5 Fault isolation

Why QNX for Embedded Systems?

1. The main responsibility of an operating system is to manage a computer’s resources.

3.1 Data Acquisition Module

The ADAM Series is a set of intelligent sensor-to-computer interface modules containing

Fig 3.1 Data Acquisition Modules

3.1.1 Software Configuration and Calibration

3.1.2 Power requirements

Fig 3.2 Power Supply unit

3.1.3 System requirements to set up an ADAM network

(a) ADAM modules

3.1.5 ADAM Communication Speed

3.1.6 Various modules used in the project

(a) ADAM- 4051 16 Channel Isolated Digital Input Module

(b) ADAM- 4055 16 Channel Isolated Digital I/O Module

(c) ADAM-4520 RS232/RS485 Converter

Fig 3.3 ADAM-4520 RS 232/ RS 485 Converter

Before placing a module in an existing network, the module should be configured.

3.1.7 ADAM 4000 Series Command set

Changing ADAM’s configuration might require the module to perform auto

NOTE: ALL COMMANDS SHOULD BE ISSUED IN UPPERCASE CHARACTERS!

3.1.8 Connectivity and Programming

performed in ASCII, which means that ADAM modules can be programmed in

virtually any high-level language.

• Remote data acquisition

3.2 Compartment Simulator

3.2.1 THE VARIOUS TYPES OF SENSORS

FIRE DETECTORS / SENSORS

3.2.1.1 Ionization Smoke Detector

3.2.1.2 PHOTO-ELECTRIC SMOKE DETECTOR

3.2.1.3 Functional Description of Photoelectric Smoke Detector:

3.2.1.4 ULTRA VIOLET FLAME DETECTOR

3.2.1.5 Functional Description of Ultra Violet Flame Detector:

3.2.1.6 MANUAL CALL POINT

3.2.1.7 Functional Description of Manual Call Point

Controls & Indications on Manual Call Point:

‘Fire’ LED and Push Button Switch:

3.2.1.8 ELECTRONIC HOOTER

3.2.1.9 Functional Description of Electronic hooter:

3.2.2 Ionization smoke detector

3.2.3 Functional Description of ionization Smoke Detector:

3.3 Operator Console

3.5 Wiring diagram

4.1 Main Window

Open com port 1

Write $026\r to com port 1

Read the input from com1 and