ATM Monitoring System

A Report submitted in partial fulfillment of the

Requirements for the degree of
B.Sc. (HON)
In
Electrical and Electronic Engineering

Under Supervision of

Dr. Iman Abuel Maaly

By
Amjad Mohieldeen Bushra Awad

To
Department of Electrical and Electronic Engineering
Faculty of Engineering and Architecture
University of Khartoum
July 2009
 Dedication

To my parents

To my supportive family

To my beloved country

To all the people of the Middle East

i
 Acknowledgement
Thanks to Dr. Iman Abu-Almaali for her patient, support and helpful
advice

Thanks for my partner Kamil Izz-Aldeen for being open minded,

supportive and cooperative.

Thanks to all who helped

ii
 Table of Contents
Dedication .................................................................................................................................. i
Acknowledgement ..................................................................................................................... ii
Table of Contents...iii
List of Abbreviations ................................................................................................................. v
List of Figures .......................................................................................................................... vi
Abstract ................................................................................................................................... vii
.................................................................................................................................. viii
Chapter One Introduction .......................................................................................................... 1
1.1 Introduction ..................................................................................................................... 1
1.2 Importance of ATMs ........................................................................................................ 1
1.3NDC+ ................................................................................................................................. 2
1.4 Problem Definition .......................................................................................................... 3
1.5 Objectives ........................................................................................................................ 3
1.6 Methodology and Tools ................................................................................................... 3
1.6.1 Methodology.................................................................................................. 3
1.6.2 Tools .............................................................................................................. 4
1.7 Thesis Layout ................................................................................................................... 4
Chapter Two LITERATURE REVIEW .................................................................................... 5
2. 1 About ATM...................................................................................................................... 5
2.1.1 Historical background.................................................................................... 5
2.1.2 Hardware ....................................................................................................... 6
2.1.3 Work scenario ................................................................................................ 8
2.1.5 Financial networks......................................................................................... 9
2.2 The standard Financial Transaction Card Originated Messages format ....................... 10
2.2.1 Message Type Identifier (MTI) ................................................................... 12
2.2.2 Bit Maps ...................................................................................................... 13
2.2.3 Data Elements .............................................................................................. 13
2.3 Host Security Module (HSM) ......................................................................................... 13
2.4 The NDC+ Software System ........................................................................................... 14
2.4.1 Terminal Application................................................................................... 14
2.4.2 Central Application...................................................................................... 14
2.4.3 NDC+ Modes............................................................................................... 15
2.4.4 Creating a NDC+ System ............................................................................ 16
2.4.4 Changeable data in the NDC+1 ................................................................... 16
2.4.5 NDC+ Operation ......................................................................................... 17
2.4.6 Unrequested Status Messages...................................................................... 18

iii
 2.5 Types of ATM Errors ..................................................................................... 19
Chapter Three Design and Implementation ............................................................................. 20
3.1 Introduction .................................................................................................... 20
3.2 Problem Definition ........................................................................................................ 20
3.3 Problem solution ........................................................................................................... 20
3.4 Server client model of the software system ................................................................. 20
3.5 Analysis modeling of the problem ................................................................................. 22
3.5.1 Data Objects Modeling ................................................................................ 22
3.5.2 Scenario Based Analysis ............................................................................. 23
3.6 System design ................................................................................................................ 24
3.6.1 Data Abstraction .......................................................................................... 24
3.7 Components Design....................................................................................................... 25
3.6.4 Interfaces Design ......................................................................................... 26
3.6.5 Architectural Design .................................................................................... 28
3.6 Implementation ............................................................................................................. 29
3.6.1 Implementation Tools .................................................................................. 29
Data Sets ............................................................................................................... 31
Chapter Four Results ............................................................................................................... 35
4.1 System modes ............................................................................................................... 35
4.2 Testing: .......................................................................................................................... 36
4.2.1 The connection ............................................................................................ 36
4.2.2 Data reader................................................................................................... 37
4.2.3 CUT_STAT testing...................................................................................... 39
4.2.3 Sending SMS: .............................................................................................. 44
4.2.4 Timer testing:............................................................................................... 45
Chapter 5 Conclusion & Comments ........................................................................................ 46
5.1 Results ........................................................................................................................... 46
5.2 Technical Limitations ..................................................................................................... 46
5.3 Future work: .................................................................................................................. 47
References ............................................................................................................................... 48
Appendix A: ATM Monitoring System Code ......................................................................... 49
Appendex B: The Softwares help document .......................................................................... 57
Appendex C: The Softwares Forums (Interface) ................................................................... 59

iv
 List of Abbreviations
ATM Automated Teller Machine

NCR National Cash Register

NDC NCR Direct Connect

PIN Personal Identification Number

POS Point Of Sale

SST State Service Terminal

MTI Message Type Indicator

HSM Host Security Module

v
 List of Figures
Figure 1.1 2
Figure 2.1 6
Figure 2.2 11
Figure 2.3 12
Figure 3.1 21
Figure 3.2 22
Figure 3.3 23
Figure 3.4 24
Figure 3.5 25
Figure 3.6 29
Figure 3.7 32
Figure 3.8 33
Figure 4.1 36
Figure 4.2 37
Figure 4.3 39
Figure 4.4 40
Figure 4.5 41
Figure 4.6 42
Figure 4.7 43

vi
 Abstract
ATM is one of the most significant computerized services that recently banks provide.
The advantages of ATM that it allows customers to access their bank accounts to
make cash withdrawals (or credit card cash advances) and check their account
balances as well as purchasing mobile cell phone prepaid credit.

In order to make this service useful ATMs should be repaired as soon as any error
happens to it, to do so the team which is responsible of repairing ATMs should be
notified with these errors as soon as they happen. In Sudans ATM network the
monitoring is done manually which leads to a lot of delays in the repairing process.

The aim of this project is to develop a software system which is purpose is to monitor
the status of the ATMs and to forward errors to the repair team immediately.
Furthermore the errors that occur to the ATMs are contained in an Oracle database
server. So the monitoring system should access the Oracle database server to read the
errors database. After that it should analyze the read database to check if there is new
error or not. If new errors found it should send them to a GSM Modem one by one.

The system was designed according to standard client server design model in the
software engineering science. The system was developed as set of components to
make it easy to design, understand and implement. The system was implemented
using Visual Basic 2008, .Net framework and ADO.net. The system was implemented
to work under the environment of Windows operating system.

Testing codes had been used to validate the system correctness and the satisfaction of
it intended requirements. The obtained results clearly reflected the project success.

vii

.

.

.


.

.
.

.

.
. Visual Basic .Net Framework
. ADO.net . Windows

.
.

viii
 Chapter One Introduction

1.1 Introduction
An automated teller machine (ATM) is a device that combines computerized
communications functions to provide the customers of a financial institution with
access to financial transactions in a public space without the need for a human clerk
or bank teller. On most modern ATMs, the customer is identified by inserting a plastic
ATM card with a magnetic stripe or a plastic smartcard with a chip that contains a
unique card number and some security information, such as an expiration date.
Security is provided by the customer entering a personal identification number (PIN).

1.2 Importance of ATMs

Using an ATM, customers can access their bank accounts in order to make cash
withdrawals (or credit card cash advances) and check their account balances as well
as purchasing mobile cell phone prepaid credit.

ATMs are placed not only near or inside the premises of banks, but also in locations
such as shopping centers/malls, airports, grocery stores, petrol/gas stations,
restaurants, or any place large numbers of people may gather. These represent two
types of ATM installations: on and off premise. On premise ATMs are typically more
advanced, multi-function machines that complement an actual bank branch's
capabilities and thus more expensive. Off premise machines are deployed by financial
institutions and also ISOs (or Independent Sales Organizations) where there is usually
just a straight need for cash, so they typically are the cheaper mono-function devices.

Most ATMs are connected to interbank networks, enabling people to withdraw and
deposit money from machines not belonging to the bank where they have their
account or in the city where their accounts are held.

1
 Figure 1.1: ATM system Elements

Most host processors can support either leased-line or dial-up machines. Leased-line
machines connect directly to the host processor through a four-wire, point-to-point
dedicated telephone line. Dial-up ATMs connect to the host processor through a
normal phone line using a modem and a toll-free number, or through an Internet
service provider using a local access number dialed by modem. Leased-line ATMs are
preferred for very high-volume locations because of their throughput capability and
dial-up ATMs are preferred for retail merchant locations where cost is a greater factor
than throughput. The initial cost for a dial-up machine is less than half that for a
leased-line machine. The monthly operating costs for dial-up are only a fraction of the
costs for leased-line. The host processor may be owned by a bank or financial
institution, or it may be owned by an independent service provider. Bank-owned
processors normally support only bank-owned machines, whereas the independent
processors support merchant-owned machines.

1.3NDC+
Mostly ATM systems use the NDC+ software system which is a terminal control
application from NCR. It is table-driven and can be customized to meet the wanted
requirements.
The NDC+ software system is made up of two parts:
l. Terminal application
II. Central application. Although which is not supplied from the corporation.

2
1.4 Problem Definition
In Sudan every bank takes care of its own ATMs by manually sending a car
periodically to take a look at its ATMs to troubleshoot them if necessary or to see if
there is a lack in paper or money or there is some kind of security violation.
Furthermore this process will take a lot of time to cover all the ATMs, cost a lot of
money since some of the covered ATMs may not need maintenance and costs a lot of
effort to be done perfectly.

1.5 Objectives
The project's objective is to make a monitoring system for all the distributed ATMs in
Sudan for a company. The monitoring system objectives are:
1. Sniff the error messages that come from the ATMs.
2. Transform the sniffed NDC+ error message to text message.
3. Route the text message into Mobile system.
4. The laptop or small pc should send the error message to the operator
that is responsible for troubleshooting in the area of the ATM that sent
the error message.

1.6 Methodology and Tools

1.6.1 Methodology

The methodology of the project contains the following:

1. Read about NDC+ protocol to create the application that will transform the error
message (in the NDC+ format) into text message.

2. Read about Oracle.

3. Read about Visual basic.NET 2008.

4. Create software on the laptop or small PC that will forward the text message to the
company's Operator.

3
 1.6.2 Tools

The tools which should be used in the system:

1. Fully functional ATM testing environment (ATM and Switch (host computer)).

2. Laptop or small PC with CDMA or GSM module to send SMS.

3. Software: Visual basic.NET 2008 program.

1.7 Thesis Layout

The project background about the ATM and is defined in chapter 2. Chapter 3
contained the analysis, design and implementation of the system. Chapter 4 is
about the results. Conclusion and recommendations of future-work are discussed
in chapter 5.

4
 Chapter Two LITERATURE REVIEW

2. 1 About ATM
ATMs are made to reduce the time and effort that you need to retrieve your bank
account to make a financial transaction and to make this service available any time
(24 hours a day).

2.1.1 Historical background

The first mechanical cash dispenser was developed and built by Luther George
Simjian and installed in 1939 in New York City by the City Bank of New York, but
removed after 6 months due to the lack of customer acceptance [6].

Thereafter, the history of ATMs paused for over 25 years, until De La Rue developed
the first electronic ATM, which was installed first in Enfield Town in North London,
United Kingdom on 27 June 1967 by Barclays Bank. This instance of the invention is
credited to John Shepherd-Barron, although various other engineers were awarded
patents for related technologies at the time. Shepherd-Barron was awarded an OBE in
the 2005 New Year's Honours List. The first person to use the machine was the
British variety artist and actor Reg Varney. The first ATMs accepted only a single-use
token or voucher, which was retained by the machine. These worked on various
principles including radiation and low-coercivity magnetism that was wiped by the
card reader to make fraud more difficult. The machine dispensed pre-packaged
envelopes containing ten pounds sterling. The idea of a PIN stored on the card was
developed by the British engineer James Goodfellow in 1965 [6].

In 1968 the networked ATM was pioneered in Dallas, Texas, by Donald Wetzel who
was a department head at an automated baggage-handling company called Docutel.

5
In 1995 the Smithsonian's National Museum of American History recognized Docutel
and Wetzel as the inventors of the networked ATM.ATMs first came into wide UK
use in 1973; the IBM 2984 was designed at the request of Lloyds Bank. The 2984 CIT
(Cash Issuing Terminal) was the first true Cash point, similar in function to today's
machines; Cash point is still a registered trademark of Lloyds TSB in the U.K. All
were online and issued a variable amount which was immediately deducted from the
account [6].

2.1.2 Hardware

Figure 2.1: ATM hardware [1].

6
2.1.2.1 Input
ATM composed of the following input devices:
1. Card reader - The card reader captures the account information stored on the
magnetic stripe on the back of an ATM/debit or credit card. The host
processor uses this information to route the transaction to the cardholder's
bank.

2. Keypad - The keypad lets the cardholder tell the bank what kind of transaction
is required (cash withdrawal, balance inquiry, etc.) and for what amount. Also,
the bank requires the cardholder's personal identification number (PIN) for
verification. Federal law requires that the PIN block be sent to the host
processor in an encrypted form.

2.1.2.2 Output
ATM composed of the following output devices:
1. Display screen - The display screen prompts the cardholder through each step
of the transaction process. Leased-line machines commonly use a
monochrome or color CRT (cathode ray tube) display. Dial-up machines
commonly use a monochrome or color LCD.

2. Receipt printer - The receipt printer provides the cardholder with a paper
receipt of the transaction.

3. Cash dispenser - The heart of an ATM is the safe and cash-dispensing

mechanism. The entire bottom portion of most small ATMs is a safe that
contains the cash.

7
2.1.2.2 Rest of components
The following ATM components implement the security and control of input and
output devices:
1. Safe or the Vault it contain the money.
2. ATM CPU contain the hardware and the software of the ATM that organize its
function.
3. Rollers.
4. Suction Cups.
5. Suction device.

2.1.3 Work scenario

Work scenario means how the machine would respond when a specific order is
chosen by a bank client.

2.1.3.1 Withdrawing cash:

When a bank client reaches the ATM for a withdrawal the following steps would
occur:
a. After the users ATM card and the personal identification number (PIN) are
approved the ATM screen displays set of available options.
b. After the amount of withdraws is entered the ATM opens one of four boxes by
activating a door that rolls up to expose the face of bills.
c. At the same time a suction device pulls up the correct number of bills.
d. The bills are placed on rollers and moved to holding area until they are dispensed.
e. If the wrong number of bills is pulled or bills are damaged the ATM drops them
into a reject box and repeats the process.
f. The bills are dispensed.
g. A receipt is printed and the transaction is recorded.

8
2.1.3 .2 Depositing checks or cash
When a bank client reaches the ATM to make a deposit the following steps would
occur:
a. After the users ATM card and the personal identification number (PIN) are
approved the ATM screen displays set of available options.
b. Once a deposit envelope is filled out and inserted into the deposit slot, it is pulled
by the rollers into a box.
c. Before it is dropped into the box, the date, users account number, and deposit total
is printed on the envelope.
d. A receipt or complete bank statement is printed, and the transaction is recorded [2].

2.1.5 Financial networks

Most ATMs are connected to interbank networks, enabling people to withdraw and
deposit money from machines not belonging to the bank where they have their
account or in the country where their accounts are held (enabling cash withdrawals in
local currency) [6].

ATMs rely on authorization of a financial transaction by the card issuer or other

authorizing institution via the communications network. This is often performed
through an ISO 8583 messaging system. Many banks charge ATM usage fees. In
some cases, these fees are charged solely to users who are not customers of the bank
where the ATM is installed; in other cases, they apply to all users. Many people
oppose these fees because ATMs are actually less costly for banks than withdrawals
from human tellers [6].

In order to allow a more diverse range of devices to attach to their networks, some
interbank networks have passed rules expanding the definition of an ATM to be a
terminal that either has the vault within its footprint or utilizes the vault or cash
drawer within the merchant establishment, which allows for the use of a scrip cash
dispenser [6].

ATMs typically connect directly to their ATM Controller via either a dial-up modem
over a telephone line or directly via a leased line. Leased lines are preferable to POTS

9
lines because they require less time to establish a connection. Leased lines may be
comparatively expensive to operate versus a POTS line, meaning less-trafficked
machines will usually rely on a dial-up modem. That dilemma may be solved as high-
speed Internet VPN connections become more ubiquitous. Common lower-level layer
communication protocols used by ATMs to communicate back to the bank include
SNA over SDLC, TC500 over X.25, and TCP/IP over Ethernet [6].

In addition to methods employed for transaction security and secrecy, all

communications traffic between the ATM and the Transaction Processor may also be
encrypted via methods such as SSL [5].

2.2 The standard Financial Transaction Card Originated

Messages format

ISO 8583 Standard for Financial Transaction Card Originated Messages - Interchange
message specifications is the International Organization for Standardization standard
for systems that exchange electronic transactions made by cardholders using payment
cards [5].

ISO 8583 defines a message format and a communication flow so that different
systems can exchange these transactions. The vast majority of transactions made at
Automated Teller Machines use ISO 8583 at some point in the communication chain,
as do transactions made when a customer uses a card to make a payment in a store. In
particular, both the MasterCard and Visa networks base their authorization
communications on the ISO 8583 standard, as do many other institutions and
networks [5].

Cardholder-originated transactions include purchase, withdrawal, deposit, refund,

reversal, balance inquiry, payments and inter-account transfers. ISO 8583 also defines
system-to-system messages for secure key exchanges, reconciliation of totals, and
other administrative purposes. Although ISO 8583 defines a common standard, it is
not typically used directly by systems or networks. Instead, each network adapts the
standard for its own use with custom fields and custom usages.

10
The placement of fields in different versions of the standard varies; for example, the
currency elements of the 1987 and 1993 versions are no longer used in the 2003
version, which holds currency as a sub-element of any financial amount element. As
of writing, ISO 8583:2003 has yet to achieve wide acceptance [5].

Figure 2.2: The interaction between the E-switch and the HBI [5].

An ISO 8583 message is made of the following parts:

1. Message Type Indicator (MTI)

2. One or more bitmaps, indicating which data elements are present
3. Data elements, the fields of the message.

11
 Figure 2.3: ISO 8583 message format.

2.2.1 Message Type Identifier (MTI)

This is a 4 digit numeric field which classifies the high level function of the message.
A Message Type Indicator includes the ISO 8583 version:

Table 2.1: Message type indicator.

12
2.2.2 Bit Maps

The ISO 8583 uses the bit map technique as an index of data elements that are
present. The bit map structure shows if a data element is present or absent.
There are two types of bit maps:

Primary bit map

A primary bit map which shows the presence or absence of fields 1 to 64, a primary
bit map is required in every message [5].

Secondary bit map

A secondary map which shows the presence or absence of fields 65 to 128, a
secondary bit map is optional and its presence is indicated in the first bit of primary
bit map [5].

2.2.3 Data Elements

The third component of a message consists of a series of data elements or fields.

These fields contain the actual transaction data required by interface of host bank
system and the switch interface to process the transactions across the network [5].

2.3 Host Security Module (HSM)

The HSM is a tamperresistant device that provides the cryptographic facilities
necessary for securing transactions in financial networks. The HSM is used to secure
a multitude of financial applications around the world ranging from ATM and POS
networks to interbank funds transfer and share dealing systems. It is available in
standard and high speed variants with a wide range of connectivity options and
protocols allowing connection to all types of host systems such as:
1. Automatic Teller Machine (ATM) systems
2. Electronic Funds Transfer at point-of-sale (EFTPOS) systems
3. Electronic trading and matching systems for bonds and securities
4. Financial Electronic Data Interchange (EDI) systems

13
5. Key management.
6. Internet Commerce [5].

2.4 The NDC+ Software System

The NDC+ software system is made up of two parts:
I. Terminal application
II. Central application.

2.4.1 Terminal Application

The terminal application gathers transaction details from the cardholder and sends
these details in a Transaction Request message to Central. When the terminal receives
a Transaction Reply command from Central, it completes the transaction. The
terminal application responds to Terminal commands from Central, such as Go-In-
Service or Go-Out-Of-Service, and requests for information, such as tallies, by
sending Solicited Status messages to Central. An unexpected event can be reported to
Central using an Unsolicited Status message [5].

2.4.2 Central Application

The Central application receives Transaction Request messages from the terminal,
and determines whether the transaction should be approved or declined. It controls the
terminal by sending Terminal commands to it and acting on responses received.
The Central application must be able to decode and act on the messages it receives
from the terminal. The Central application must also be able to code messages in the
form that the NDC+ software in the terminal understands. When you switch the
terminal on, after loading it with the NDC+ terminal software, it sends a power-up
message to Central. Central downloads any necessary data to the terminal in a series
of messages. After each message is sent, the terminal sends an acknowledgement to
Central [3].

14
When Central has sent all the download data successfully, it will put the terminal in
service. When the terminal processes a transaction, it gathers the details from the
cardholder and card, and sends the information in a Transaction Request message to
Central. Central sends a Transaction Reply command, and the terminal completes the
transaction [5].

If a fault occurs, the terminal sends a message to Central and waits for a further
Transaction Reply command before completing the transaction. Once the transaction
has been completed successfully, the terminal sends a message to Central to confirm it
[5].

2.4.3 NDC+ Modes

There are currently two variations of NDC+:

I. Native mode
II. Diebold Emulation mode

2.4.3.1 Native Mode

Native mode supports all NDC features available with 4th generation terminals. Native
mode also supports Native mode status reporting [5].

2.4.3.2 Diebold Emulation Mode 1

The NDC Self-Service Terminal (SST) is compatible with a standard Diebold TABS
900 series terminal, operating in direct connect mode. This means that when running
in Diebold Emulation mode, the NCR terminal can emulate Diebold TABS 910/911
and 920/921 terminals, without modification to either the Central application or the
Diebold terminal configuration data. An NCR 4th generation or SHUVRQD6
terminal can therefore fit into a Diebold network without any modification to the
Central application [5].

15
2.4.4 Creating a NDC+ System

When you create an NDC+ system you will find that there are two distinct tasks
involved:
l. Creating the customization data.
II. Creating the Central control application.

2.4.4 Changeable data in the NDC+1

The changeable data consists of the following:

State Tables:
These contain the sequence of states that determine how the terminal processes
transactions.

Financial Institution Tables (FITs): 1

These define which institutions the terminal supports. For each institution, the table
defines whether PIN verification is local or remote, the type of data encryption, and
the position of details on the card.

Screens: 1
These are displayed while the cardholder is using the terminal.

Keyboards:
These define the type of keyboard which is used. This may be a fixed physical
keyboard layout or a touch screen keyboard which is displayed on the screen.

Configuration Parameters 1
These are local configuration parameters, such as camera control, Amount Buffer
size, card reader/writer error thresholds, and timers.

16
Creating a NDC+ System:
The Central control application uses the following commands and messages:

Terminal Commands 1
These send instructions to the terminal.

Transaction Reply Commands 1

These are sent in response to a Transaction Request message from the terminal. They
tell the terminal how to complete the transaction.

Customization Data Commands 1

These download customization data to the terminal.

Interactive Transaction Response 1

This option allows you to send a message to the terminal to prompt the cardholder for
more information.

2.4.5 NDC+ Operation

States control the information-gathering part of cardholder transactions. NDC+

includes a set of standard states. NDC+ also provides mechanisms which enable you
to replace standard states or add new ones. States which you write yourself are called
Exit States. In this chapter we describe the function of each of the standard state table
types and its format. The state table is made up of the state number, state type and
table data. Most states include a screen number and a next state number as part of the
table data [5].
In general, where a screen is present it is displayed when the state is entered, the
terminal performs the action specified by the state type, and the transaction flow
continues from the specified next state. These screens can also reference associated
keyboard layouts. During transaction processing, before entry to each state, NDC+
checks the keyboard layout to be used. If the screen that is about to be used references
a keyboard number but the keyboard layout does not provide definitions of all the
required keys, the transaction flow proceeds to the default close state [5].

17
If the next state specified is invalid or undefined, due to either the state table or the
Transaction Reply specifying a state that has not been downloaded, the transaction
flow continues from a default close state. If the Digital Audio Service is configured,
then in certain states the cardholder keyboard will be audibly echoed as the cardholder
uses it. This is turned off in sensitive states those concerned with PIN Entry and those
in which the echo on the cardholder display is shown by asterisks [5].
The Digital Audio Service can also make various announcements during transaction
processing. When the default close state is executed, it will complete the cardholder
transaction by delivering a receipt or statement, and delivering or capturing the card
as specified. The number of the last state executed is displayed in the top left hand
corner of the CRT screen. This allows you to check the parameters of the last state
executed to find out which state the terminal was attempting to execute. From this you
can specify the missing state and include it in the download. You customize the state
by assigning values to its parameters [5].

To build a state flow, you select different state types and place them in the application
flow by linking the states together - one state references another with one or more of
its parameters or entries. When you have finished customizing the state tables, Central
downloads the information to the terminal in Customization Data commands [5].

2.4.6 Unrequested Status Messages

Unrequested Status messages are used to report any change of condition at the
terminal. These include:
I. Recognition of an external event.
II. Device errors.
III. Supplies problems. Unsolicited status messages do not require a reply from
Central.
They are sent under the following conditions:
I. Power failure. A message is sent on power-up.
II. An external event is detected. This includes bin inserted/removed, alarm activated,
supervisor keys and switches.

18
The reporting of supervisor switch changes is delayed if a card is inserted l A device
fault is detected as a result of processing a Transaction Reply command, but the fault
condition does not require Central recovery action. This means that Transaction Reply
processing can continue as if no fault had occurred l A device fault is detected which
is not the result of processing a Transaction Reply command [5].
For example, printer/MCR errors l If an alarm is activated during a power failure or
communications loss, a message is sent when power or communications are restored l
If supervisor/supply switch values are changed while off-line, the last change of both
switches is reported when communications are restored l If the message mode option
is set to enable the Cancel key while a Statement and Wait function is being carried
out and the cardholder presses the Cancel key. Device fault status information varies
according to whether Native or Diebold Emulation mode status reporting is used [5].

2.5 Types of ATM Errors

There are two types of errors that occur to the ATM:

a. Fatal Errors: Errors that fully disables the ATMs service such as:

1. User Command.
2. Loss of Communication.
3. System Malfunction Message Handling Error.
4. System Malfunction Expression Handling.
5. Error.
6. Cash Handler Error.
7. Journal Error.
8. Encryptor Error.
9. Supervisor Mode Entry.
10. Sensor Activated.

b. Functional Errors: Errors that disables one of the ATMs supporting services [3].

19
 Chapter Three Design and Implementation
3.1 Introduction

Design is all about understanding the problem and demonstration of how it should be
solved. So for a design to be done the problem must be known first. Then this
problem must be analyzed to extract the data objects. Further a model for the solution
will be developed using diagrams and methods such as object oriented modeling.

3.2 Problem Definition

Current ATM system monitors the status of the system components and this status is
contained in an Oracle database server. One of the tables of this database contains the
errors that are related to ATMs functionality and the services that it delivers. This
database has a team which his objective is to monitor it manually in a separate way
from the team that actually repairs it. That separation causes a lot of problems such as
delays in repairing fatal errors, conflicts and overhead to the system.

3.3 Problem solution

Our aim is to develop a software that is going to check the errors table in the Oracle
database every predefined time interval to see if there is new record or not. If there is
a new record it transforms it into predefined patterned text. Then it sends that text
message to the mobile of who is responsible of repairing that error as an SMS.

3.4 Server client model of the software system

The ATM is server client system since all the ATM's in the network should
contact one server to fulfill its function. The server in this system is a

20
transaction server since the client sends a request that invokes remote procedures at
the server site. The remote procedures are a set of SQL statements. A transaction
occurs when a request results in the execution of the remote procedure with the result
transmitted back to the client.

Figure 3.1: The general architecture of Server/Client software system [4].

The ATM monitoring system software will act as Client for the Oracle database
server. This client will initiate a connection to the server to read the errors table as
mentioned previous. This puts a spot on one of the biggest advantage of the client
server systems is the enables the roles and responsibilities of a computing system to
be distributed among several independent computers that are known to each other
only through a network.

Furthermore all the data is stored on the servers, which generally have far greater
security controls than most clients. Servers can better control access and resources, to
guarantee that only those clients with the appropriate permissions may access and
change data.

21
 Figure 3.2: The internal construction of S/C software [4].

3.5 Analysis modeling of the problem

Analysis modeling is the bridge between the requirements (the problem definition)
and the design of a software project. It starts with the definition of data objects and
their relationship which is known as data objects modeling. Then data objects are
added to related procedures to form components.

3.5.1 Data Objects Modeling

Data objects modeling focuses on the data domain to define data objects at the lowest
level of abstraction. A data object is an object which is described by a set of attributes
and will be manipulated within the system [4].

Data objects in the previous problem demonstration:

1. The Errors Table in the DB.

22
Attributes of the data object:
Object: Errors Table.
Number of Records
Number of Fields
Fields names

3.5.2 Scenario Based Analysis

Use-Cases are a scenario that describes a thread of usage for a system. They are
simply an aid to defining what exists outside the system (actors) and what should be
performed by the system [4].

External characters (such as: people, device) represented in the use cases are
categorized into the two types:

a. Actors represent roles people or devices play as the system functions

b. Users can play a number of different roles for a given scenario.

Figure 3.3: The Use-Case diagram for the ATM monitoring system.

23
3.6 System design
The design is the step after defining the attributes (data) and the behavior (procedures)
and their relationship (components). The design gives a general view of how data
objects, components, and overall architecture should be implemented. So it starts with
data abstraction then adds procedures to them to design components then shows the
overall software architecture [4].

Figure 3.4: The Project workspace block diagram (The red blocks are the projects
blocks).

3.6.1 Data Abstraction

Data abstraction is defining (naming) the data collection that describes a specific data
object [4]. The following is the abstraction of the data object in this software system:

a. Errors Table: Contains the records that are wanted to be sent to the repair
team.
b. Trace Number: Contains the number of the last record sent or the record
that the systems administrator wants the monitoring to start from.

24
3.7 Components Design
Components design gives more details about the components in the system
focusing on their behavior. The system should contain the following
components:
1. Data reader: It should check if there is new record in the Errors table.
2. Timer: It should invoke the data reader every certain period.
3. SMS sender: It receives its input from the Data reader and transforms it according
to certain pattern to text and sends it to a GSM modem.
4. Last checked error: contain the trace number. This trace number is the id of the last
record checked by the software system.

The relationship between these components is that the timer should invoke the
last checked error component every given time. When the last checked is
invoked it invokes the data reader component and passes the value of the trace
number to it. The data reader reads the errors database and compares the id of
last error with the trace number to find if there is new error or not. If the data
reader detects a new error it invokes the SMS sender and passes error record
fields to it. The SMS sender should transform the received error record fields
to SMS message to be sent.

Figure 3.5: Components Block diagram.

25
3.6.4 Interfaces Design

By referring to the diagram of the projects work space and noting that the software
project would be running on the small computer block we conclude that the system
needs the following interfaces:

1. The user interface (UI).

2. External interface (to the GSM modem).
3. Internal interfaces between different components.

3.6.4.1 User Interface

User interface is the bridge between the user and the software system. It
accepts the users inputs and passes them to the software system.

User interface should be:

1. Simple and easy to deal with.
2. Allows the user to change the time interval of the checking procedure.
3. Allows the user to enter the user name and password of the database.

3.6.4.2 External Interfaces

External interfaces are the connection between the computer that hosts the
software system and an external device (such as modem, printer). The only
external interface that exists in the system is the interface to the GSM modem.
External Interface to the GSM modem should be either Serial port or the USB.

3.6.4.2 Internal Interfaces

Internal interfaces are the connections between different objects in the system.
Furthermore the concepts of information hiding and controlled interfaces between
different components are used to reduce errors and to make it easier to detect them.
The internal interfaces in the system are:
1. Time component:
Contains two interfaces which are:
a. The wait time interval which can be set by the user (input interface).

26
b. The wait function which will invoke the data reader object (output interface).

2. The data reader component:

Contains three interfaces:

a. The check for last status function which will invoke the last checked error object
(output interface).

b. The current status which contains the output of the last error checked object (input
interface).

c. The pass the error fields function which will pass the fields of the error record the
SMS object (output interface).

3. Last error checked component:

Contains one interface:

Pass current status which will pass the number of last error checked to the data
reader object.

4. SMS component

This component contains variables that will receive the values of the error record to
construct the SMS message.

27
3.6.5 Architectural Design

The design is the overall structure of the software and the ways in which that structure
provides conceptual integrity for a system [4]. The architecture of the system is as
follows: the main program invokes a timer component which has a Wait function that
waits for a certain time interval and then invokes the data reader object. The data
reader object will first invoke its connect function which would initiate a connection
to the Oracle database and reads the errors database and passes it to the find last error
number function. The find last error checked function will find the id of the last error
in the database then this component will invoke the last checked error component.
The last checked error component only passes the last error checked number by the
function pass current status to the compare function in the data reader component. The
compare function will compare between the last errors number which was found by
the find last error number function and the number passed from the last checked error
component. If the compare finds a difference between the two it enters a loop for the
difference between the two numbers in which it passes the fields of each new error to
the SMS sender component. The SMS sender component will transform the error
record fields to a predefined SMS pattern by the transform into SMS pattern function.
After that SMS sender component will invoke the pass SMS to the GSM modem
function which will send the previously formed SMS to the GSM modem.

28
 Figure 3.6: Architectural design using object oriented design structure.

3.6 Implementation
After the problem solution is well defined in the systems design, the implementation
phase comes in which the design should be transformed into code.

3.6.1 Implementation Tools

The tools which were used in the implementation are the following:

3.6.1.1 ODBC

Open Data Base Connectivity, a standard database access method developed by the
SQL Access group in 1992. The goal of ODBC is to make it possible to access any
data from any client application, regardless of which database management system
(DBMS) is handling the data. ODBC manages this by inserting a middle layer, called
a database driver, between an application and the DBMS. The purpose of this layer is

29
to translate the application's data queries into commands that the DBMS understands.
For this to work, both the application and the DBMS must be ODBC-compliant -- that
is, the application must be capable of issuing ODBC commands and the DBMS must
be capable of responding to them.

3.6.1.2.1 ADO.net

ADO.NET is a combination of computer software components that can be used by

programmers to access data and data services. It is a part of the base class library that
is included with the Microsoft .NET Framework. It is commonly used by
programmers to access and modify data stored in relational database systems, though
it can also be used to access data in non-relational sources.

It is used to access the ODBC data service through which it can access the oracle
database.

3.6.1.2.2 Construction of ADO.net

The ADO.net is constructed from the following:

1. Data provider

These classes provide access to a data source, such as a Microsoft SQL Server or
Oracle database and OLEDB data provider. Each data source has its own set of
provider objects, but they each have a common set of utility classes:

Connection: Provides a connection used to communicate with the data source.

Also acts as an abstract factory for command objects.
Command: Used to perform some action on the data source, such as reading,
updating, or deleting relational data.
Parameter: Describes a single parameter to a command. A common example is
a parameter to a stored procedure.
Data Adapter: A bridge used to transfer data between a data source and a Data
Set object (see below).

30
 Data Reader: Used to efficiently process a large list of results one record at a time.
It allows records to be accessed in a read-only, forward-only mode, i.e., records
have to be accessed in sequential order; they can neither be randomly accessed nor
can a record which has been processed previously be accessed again(which will be
used here since it is only needed to read the database not to change it).

Data Sets

Data Set objects, a group of classes describing a simple in-memory relational

database, were the star of the show in the initial release (1.0) of the Microsoft
.NET Framework. The classes form a containment hierarchy:

a. A Data Set object represents a schema (either an entire database or a subset of

one). It can contain tables and relationships between those tables.
b. A Data Table object represents a single table in the database. It has a name,
rows, and columns.
c. A Data View object "sits over" a Data Table and sorts the data (much like a
SQL "order by" clause) and filters the records (much like a SQL "where"
clause) if a filter is set. An in-memory index is used to facilitate these
operations. All Data Tables have a default filter, while any number of
additional Data Views can be defined, reducing interaction with the underlying
database and thus improving performance.
d. A Data Column represents a column of the table, including its name and type.
e. A Data Row object represents a single row in the table, and allows reading and
updating of the values in that row, as well as retrieving any rows that are
related to it through a primary-key foreign-key relationship.
f. A Data Row View represents a single row of a Data View. The distinction
between a Data Row and Data Row View is important when iterating over a
result set.
g. A Data Relation is a relationship between tables, such as a primary-key
foreign-key relationship. This is useful for enabling Data Row's functionality
of retrieving related rows.

31
h. A Constraint describes an enforced property of the database, such as the
uniqueness of the values in a primary key column. As data is modified any
violations that arise will cause exceptions.

3.6.1.3 Software Implementation

First of all an ODBC driver was installed and configured on the client side to be
able to read the oracle database that is in the server side as shown in the figure
below.

Figure 3.7: ODBC configuration.

This made the ODBC ready to receive connection request from ADO.net.

Using Visual Basic.net 2008 the software was made of the parts which was mentioned
in the design section earlier in this chapter with a small alter in the trace object which
contained in the new arrangement access the part which reads the database to find out
last error number.

32
 Figure 3.8: ATM Monitoring System Interface.

As the banker starts the execution of the software the previous figure pops out but it
wont start to monitor immediately. It will give the operator time to alter settings
using edit menu to change the mobile phones for the repairing teams. After changes
are made if wanted the operator now can click start on the execution menu to start
monitoring.

This will invoke the timer which contains the main procedure of the program which
will create objects in the following sequence:

1. The trace object:

It is the first object which will be created and it has two main functions:

a. Find current trace:

It will find out the last error number in the Oracle database by connecting to the
ODBC driver and executing a data Reader.

33
b. Read Previous Trace number:

It will pass these two parameters two the data Reader Object which is invoked next.

2. The data Reader object:

It will receive the two trace numbers and it will enter a loop between the two. In this
loop it will start with the most previous error and go on until it reads all the errors that
happened in the time interval of the timer. Every time the loop is invoked it creates a
connection to the ODBC executes a Data Reader and reads the records of the error
and put them into variables It will pass this variables to the SMS object which is
invoked next.

3. SMS object:

This object will receive the error record fields from the data Reader object and it will
transform them into predefined text pattern and it will send it to the serial port with
the settings of the SMS service (meant by the serial port which the GSM modem is
connected to).

34
 Chapter Four Results
ATM Monitoring System was deployed to work with the latest versions and
technologies such as 3GPP modem, Oracle 11g, Visual Basic.net 2008, ADO.net,
and ODBC 11. So in the following parts shows how the steps of how the software
was tested.

4.1 System modes

In the previous chapter in the interface section was mentioned that the software after
being invoked it wont start to monitor until it is asked to, and that to make the
operator change the following parameters:
1. Oracle System ID (SID) is used to uniquely identify a particular database on a
server, the host server name or IP and the port number of the oracle server
listener the listener is a separate process that runs on the database servers
computer. It receives incoming client connection requests and manages the traffic
of these requests to the database server.
2. GLOBAL_DBNAME Use to identify the database service. While processing a
client connection request, the listener tries to match the value of this parameter
with the value of the SERVICE_NAME parameter in the client connect
descriptor. If the client connect descriptor uses the SID parameter, then the
listener does not attempt to map the values. This parameter is primarily intended
for configurations with Oracle8 release 8.0 or Oracle7 databases (where dynamic
service registration is not supported for dedicated servers). This parameter may
also be required for use with Oracle9i and Oracle8i database services by some
configurations and management tools.

The value for this parameter is typically obtained from the combination of the
DB_NAME and DB_DOMAIN parameters (DB_NAME.DB_DOMAIN) in the
initialization parameter file, but the value can also contain any valid name used
by clients to identify the service.

3. The oracle database username and password.

4. Time interval for the reading from database.

35
5. Optional to add the trace number (the record of the last error number field in the
database primary key)

4.2 Testing:
Note that the following windows in the figures that are in this section are not a part
of the actual system. They are only provided to show how the different parts of the
software implementation.

4.2.1 The connection

The testing procedure started by checking the connection from the client side to the
Oracle database using ODBC driver. The ODBC driver needs to be configured with
the Oracle database server information to be able to connect to it. The first entered
parameters to the ODBC are not completed so the ODBC driver will not be able to
connect to the Oracle database server as the following figure shows the output of
when a test connection is invoked to the ODBC:

Figure 4.1: connection to database failed

36
In this time the correct parameters are passed to the system:

Figure 4.2: connection successful.

4.2.2 Data reader

The data reader reads the fields of the error records from the oracle server through
the ODBC and the oracle client.

37
 The database layout is as follows in the figure:

NUM EN_DATE BNK_CODE TRM_NAME SIGNON SIGNOFF CUT_STAT Details Reason

319722 05/03/2009 08:28:32 2001 SUFHSH012 05/03/2009 08:32:46 05/03/20091
319723 05/03/2009 08:28:32 2161 FARLFO030 05/03/2009 08:32:46 05/03/20091
319724 05/03/2009 08:29:36 2281 ISCMZO023 05/03/2009 08:30:39 05/03/20091
319725 05/03/2009 08:30:38 1981 SSDMGF017 05/03/2009 08:31:42 05/03/20091
319726 05/03/2009 08:30:38 2021 TISTMO008 05/03/2009 08:31:42 05/03/20091
319727 05/03/2009 08:33:48 1901 FISPCK050 05/03/2009 08:34:52 05/03/20091
319728 05/03/2009 08:33:48 1901 FISSHK039 05/03/2009 08:34:52 05/03/20091
319729 05/03/2009 08:33:49 2161 FARTSK010 05/03/2009 08:34:53 05/03/20091
319730 05/03/2009 08:33:49 2181 ANRGDK008 05/03/2009 08:44:24 05/03/20091
319731 05/03/2009 08:33:50 5961 BYBMRK004 05/03/2009 08:34:54 05/03/20091
319732 05/03/2009 08:35:56 2001 SUFKFN029 05/03/2009 08:45:26 05/03/20091
319733 05/03/2009 08:35:56 2021 TISJDK007 05/03/2009 08:38:03 05/03/20091
319734 05/03/2009 08:35:57 5961 BYBASK001 05/03/2009 08:38:04 05/03/20091
319735 05/03/2009 08:36:59 1901 FISSOB040 05/03/2009 08:38:02 05/03/20091
319736 05/03/2009 08:37:00 2161 FARTWK026 05/03/20092 001
319737 05/03/2009 08:38:02 1881 EXPBHB004 05/03/20092 073

Table 4.1: oracle database layout

The data reader only needs to read the records that the CUT_STATUS equal to 2
because the CUT_STATUS field means the following:

CUT_STATUS Meaning
1 In service
2 Out of service

Table 4.2: The meaning of CUT_STATUS .

38
4.2.3 CUT_STAT testing

First adding record to oracle database in the server that the CUT_STAT equal 1:

Figure 4.3: adding CUT_STATUS equal 1.

The figure 4.3 above shows the the oracle database after adding new error record
with CUT_STATUS = 1 .

39
The datareader no response:

If the orcale database was tested by the data reader with its current status (one
record that has CUT_STATUS = 1) the data reader should ignore this record as the
followign figure shows:

Figure 4.4: data reader no response.

40
If a new record was added to the database with CUT_STATUS = 2 as the following
figure shows:

Figure 4.5: adding CUT_STATUS =2.

41
If the database was tested using the same procedure as above the data reader now
will read the fields of the error record and it will find that it has CUT_STATUS =1
so it will show its fields as the following figure shows:

Figure 4.6 :data reader response.

42
Then the data reader was tested to make sure that it is able to read errors even when
the administrator of the Oracle database is editing it. The following figure shows
that the trace number was read while the administrator is making changes:

Figure 4.7: data reader read a specific trace number

The following figure shows the Detail_Reason codes and there corresponding
meaning.

detail reasoReason Label

000 User Command
001 Loss of Communication
002 System Malfunction Message Handling Error
003 System Malfunction Expression Handling Error
051 Hash Handler Error
067 Journal Error
068 Encryptor Error
004 Supervisor Mode Entry
073 Sensor Activated
Table 4.3: detail reason corresponding meanings.

43
 Bank CodeBank Name mobile
1 BOS Reference Bank
1881 Export Development Bank 09xxxxxxxx
1901 Faisal Islamic Bank
1921 Sudanese Agricultural Bank
1941 Bank of Khartoum
1961 El Nilein Industrial Development Bank Group
1981 Saving & Social Development Bank
2001 Sudanese French Bank
2021 Tadamon Islamic Bank
2041 Sudanese Islamic Bank
2061 Al Baraka Sudanese Bank
2081 Saudi Sudanese Bank
2101 Workers National Bank
2121 Al Shamal Islamic Bank
2141 Commercial & Real State Bank
2161 Farmers Commercial Bank
2181 Animal Resources Bank
2201 Financial Investment Bank
2281 Islamic Co-Operative Development Bank
2681 Blue Nile Mashreg Bank
3481 Omdurman National Bank
3101 Bank of Sudan
3501 Industerial Development Bank
3521 Al Salam Bank
3541 Sudanese Egyptian Bank
5561 CSC LEBANON
3961 Capital Bank
4361 The National Bank of Sudan
4761 123 EGYPT
6361 Elgazeera Sudanese Jordanian Bank
5961 Byblos Bank
6761 Banque Sahelo-Saharinne

Table 4.4: Banks codes and there corresponding names.

4.2.3 Sending SMS:

The SMS object will send the error SMS after converting error record fields to a
predefined text pattern to make it understandable by the person who responsible for
repairing the error.

44
The pattern of the SMS:
The bank name (45 characters): terminal number (12 character): error reason (50)
:time (8 character).
Example:-
El Nilein Industrial Development Bank Group: WONMGK004: System Malfunction
Expression Handling Error: 1:00 AM.

4.2.4 Timer testing:

For the timing two timers were tested. The first one is a built- in timer in the visual
basic. The second one is implemented from scratch. The results of testing the built in
timer:

Input time interval by administrator Output time interval

minutes seconds Minutes seconds
2 00 2 15
6 00 6 32
12 00 12 47
Table 4.5: The time interval

It shows that the timer which is used will add addition time to the set time which will
make a delay in the monitoring process which is in average 12.5%. Note that a new
timer was implemented to solve this problem. The new timer showed significant
improvement to the system. It has nearly 1% percent error.

45
 Chapter 5 Conclusion & Comments

5.1 Conclusion
The project results are satisfying all the objectives and goals. The system has
advantage of network protocol independent which is very great in advantage in server
client systems. The software is lightweight, easy to manage, and efficient.

The lightweight feature comes from using XML file to contain the database of the
phone numbers for the banks instead of using other files for database (such as
Microsoft Access or SQL database) which will make the software take more power to
execute by the CPU.

5.2 Technical Limitations

The system has the following technical limitation:

1. The GSM modem

It has a limited number of SMS to send per minute (6-30).

2. The SMS service

It is not reliable, even though it has been one of the requirements which were
submitted by the bank.
3. The timer

The default Visual Basic.net 2008 timer which was used in the implementation
of the project wasnt accurate (it has 12.5% delay as mentioned previously).

46
5.3 Future work:
The following features could be added to the system in the future:

1. A new web feature for the software to be able to send feed back to an email.
This tool will make the it able to connect the operators of the system with its
creators.
2. New feature should be added to the system view strip menu to view the
statistics of the errors.

47
 References
1. Globalis International, Sophisticated Banking Machines for Cash Despenser Applications,
[Online] www.globalis.com,

Accessed on 29/12/2009.

2. How Stuff Works , How ATM Works, [Online] http://www.howstuffworks.com/,

Accessed on 4/12/2009.

3. NCR. 2007. ProCash/NDC ProConsult/NDC User Guide. 2007.

4. Roger S.Pressman, Software Engineering A Practitionor's Approach. s.l. : McGraw-Hill,

2001.

5. Kingsway West, , NCR NDC+ Programmers Reference Manual. s.l. : NCR Corporation,
2001.

6. Wikipedia free encyclopedia, Automated Teller Machine, [Online] www.en.wikipedia.org,

Accessed on 12/12/2009.

48
 Appendix A: ATM Monitoring System Code

1.The data Reader Code:

Imports Oracle.DataAccess.Client

Imports Oracle.DataAccess.Types

Public Class Data_Reader

Public Trace As Long

Public Bank_Code, ATM_ID, Error_type, Reason As String

'Trace number which should be passed by the Trace Object

'This is the Data Reader Compenent which is ment to read the ATM Transaction's
table in the Oracle db that contains

'the status of all the components in the ATM network.The output of this component
(object) is the fields of the

'error record.Which will be contained in the following strings

Bank_Code:BNK_CODE=BANK,ATM_ID:TRM_NAME=ATM_ID

',Error_Type:CUT_STAT,Reason:Details Reason

Sub Orc_connection() 'this function sub is made to make try works and to be
invoked to read from the db

Dim username As String = "scott"

Dim password As String = "kamil"

49
 'definition of the username and password of the db

Dim conn As New OracleConnection

conn.ConnectionString = _

"Data Source=(DESCRIPTION=" _

+
"(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=kamil)(PORT=1521))
)" _

+
"(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=orcl.kamil)));"
_

+ "User Id=scott;Password=kamil;"

conn.Open()

Dim parmuser As New OracleParameter

parmuser.OracleDbType = OracleDbType.Char

Dim TxtUsername As String = "scott"

Dim TxtPassword As String = "kamil"

parmuser.Value = TxtUsername

Dim parmpass As New OracleParameter

parmpass.OracleDbType = OracleDbType.Char

parmpass.Value = TxtPassword

Dim sql As String = "select BNK_CODE,CUT_STATUS,DETAIL_REASON

from ATM_TRANSACTION where NUM=" & Trace ' Visual Basic

50
 Dim cmd As New OracleCommand(sql, conn)

cmd.CommandType = CommandType.Text

Dim dr As OracleDataReader

dr = cmd.ExecuteReader()

cmd.CommandType = CommandType.Text

dr.Read()

conn.Close()

Error_type = dr.Item("CUT_STATUS")

If Error_type = "2" Then

Bank_Code = dr.Item("BNK_CODE")

'ATM_ID = dr.Item("TRM_NAME")

Reason = dr.Item("DETAIL_REASON")

End If

conn.Dispose()

End Sub

End Class

2.The Trace code:

Imports Oracle.DataAccess.Client

Imports Oracle.DataAccess.Types

Imports System.IO

51
Public Class Trace_Number

Public Trace_N As Long

Public Trace_OUT As Long

Sub Orc_connection_Trace() 'this sub is made to make try works

'definition of the username and password of the db

Dim strConn As String = "Data Source=(DESCRIPTION=" _

+
"(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=kamil)(PORT=1521))
)" _

+
"(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=orcl.kamil)));"
_

+ "User Id=scott;Password=kamil;"

Dim Connection As New OracleConnection(strConn) 'initiate an Oracel db

connection object

Try 'is made to catch any exception that may occure while working with the db

Connection.Open()

'invoke the member function open of the Connection object which was
initiated before

Dim parmuser As New OracleParameter

parmuser.OracleDbType = OracleDbType.Char

52
 Dim TxtUsername As String = "scott"

Dim TxtPassword As String = "kamil"

parmuser.Value = TxtUsername

Dim parmpass As New OracleParameter

parmpass.OracleDbType = OracleDbType.Char

'defintion of oracle command

'o1Command for selecting field

'Trace number which should be passed by the Trace Object

'selects the bank id of the new error record

Dim sql As String = "select MAX(NUM) from ATM_TRANSACTION "

Dim o2Command As New OracleCommand(sql, Connection)

o2Command.CommandType = CommandType.Text

Dim DR1 As OracleDataReader

DR1 = o2Command.ExecuteReader()

DR1.Read()

Trace_N = DR1.Item("MAX(NUM)") 'Now Trace_N contains a number that

is higher than the ID of the last error in the table by 1

'Trace_N now contains the ID (number) of the last error in the table

Connection.Close()

Connection.Dispose()

Catch ex As Exception

53
 System.Windows.Forms.MessageBox.Show(ex.ToString())

End Try

End Sub

Sub Check_if() 'checks if there is previously saved trace number or not. if not it
creates one

If My.Computer.FileSystem.FileExists("E://Trace.txt") Then

Dim TraceStreamReader As New System.IO.StreamReader("E:\Trace.txt")

'stream to read the previous trace first

Trace_OUT = Trace_N - TraceStreamReader.ReadLine

'This should be the output of this object

TraceStreamReader.Close()

Dim TraceStreamWriter As System.IO.StreamWriter

TraceStreamWriter = New StreamWriter("E:\Trace.txt")

TraceStreamWriter.WriteLine(Trace_N)

'Trace.txt should contain the new value of the trace number

TraceStreamWriter.Close()

Else 'if there is no Trace file that means the monitoring process just started and
there is no previous value

54
 Dim TraceStreamWriter2 As System.IO.StreamWriter

TraceStreamWriter2 = New StreamWriter("E:\Trace.txt")

TraceStreamWriter2.WriteLine(Trace_N)

TraceStreamWriter2.Close()

'Close the file after the trace number is written in it

End If

End Sub

End Class

The SMS_Sender class:

Imports System.IO.Ports

Public Class SMS_sender

Dim code, A_ID, E_t, Rsn As String ' this values to contain the
values passed from the dataReader
Dim com As String 'this to contain the com port passed by the
user
Dim b1, b2, b3, b4, b5, b6, b7, b8, b9, b10, b11, b12, b13, b14,
b15, b16, b17, b18, b19, b20, b21, b22, b23, b24, b25, b26, b27, b28,
b29 As String ' these strings to hold the phone numbers passed from
the numbers _F class
Dim SMS_Sender As New SerialPort

Sub sno()
SMS_Sender.Open()
SMS_Sender.Write("AT")
SMS_Sender.WriteLine("AT+CMGF=1" & n) 'set command message
format to text mode(1)
Select Case code
Case "1881"
SMS_Sender.WriteLine("AT+CMGS= + b1 ")
Case "1882"
SMS_Sender.WriteLine("AT+CMGS= + b2 ")
Case "1883"
SMS_Sender.WriteLine("AT+CMGS= + b3 ")
Case "1884"
SMS_Sender.WriteLine("AT+CMGS= + b4 ")
Case "1885"
SMS_Sender.WriteLine("AT+CMGS= + b5 ")
Case "1886"
SMS_Sender.WriteLine("AT+CMGS= + b6 ")
Case "1887"
SMS_Sender.WriteLine("AT+CMGS= + b7 ")

55
 Case "1888"
SMS_Sender.WriteLine("AT+CMGS= + b8 ")
Case "1889"
SMS_Sender.WriteLine("AT+CMGS= + b9 ")
Case "1890"
SMS_Sender.WriteLine("AT+CMGS= + b10 ")
Case "1891"
SMS_Sender.WriteLine("AT+CMGS= + b11 ")
Case "1892"
SMS_Sender.WriteLine("AT+CMGS= + b12 ")
Case "1893"
SMS_Sender.WriteLine("AT+CMGS= + b13 ")
Case "1894"
SMS_Sender.WriteLine("AT+CMGS= + b14 ")
Case "1895"
SMS_Sender.WriteLine("AT+CMGS= + b15 ")
Case "1896"
SMS_Sender.WriteLine("AT+CMGS= + b16 ")
Case "1897"
SMS_Sender.WriteLine("AT+CMGS= + b17 ")
Case "1898"
SMS_Sender.WriteLine("AT+CMGS= + b18 ")
Case "1899"
SMS_Sender.WriteLine("AT+CMGS= + b19 ")
Case "1900"
SMS_Sender.WriteLine("AT+CMGS= + b20 ")
Case "1901"
SMS_Sender.WriteLine("AT+CMGS= + b21 ")
Case "1902"
SMS_Sender.WriteLine("AT+CMGS= + b22 ")
Case "1903"
SMS_Sender.WriteLine("AT+CMGS= + b23 ")
Case "1904"
SMS_Sender.WriteLine("AT+CMGS= + b24 ")
Case "1905"
SMS_Sender.WriteLine("AT+CMGS= + b25 ")
Case "1906"
SMS_Sender.WriteLine("AT+CMGS= + b27 ")
Case "1907"
SMS_Sender.WriteLine("AT+CMGS= + b28 ")
Case "1908"
SMS_Sender.WriteLine("AT+CMGS= + b29 ")
End Select
SMS_Sender.WriteLine("An Error occured in +A_ID and the error
type is +E_t and its reason is +Rsn")
SMS_Sender.Close()
End Sub

End Class

56
 Appendex B: The Softwares help document

Before starting the software:

You need to insure that you installed ODBC driver that is compatible with the Oracle
database that you are working with and it is configured as the following figure shows:

Then press the Test Connection button and write down the user name and password of
the Oracle server if the verification successes then proceed with executing the
software if not make reconfigure your network connection and make sure that the
firewall is disabled.

Starting the software:

The main forum that pops out after the splash screen consists of the following:

57
 1. File menu strip:
It consists of two items Execute and Exit. When you click on Execute the
monitoring process will start and the errors will be sent to the repairing teams.
Exit will close the program.

2. Edit menu strip:

It contains the data the settings that could be altered by the supervisor of the
system to make sure that the system satisfies the wanted goals. The settings
that could be altered are: the phone numbers of the repairing teams, timer
interval, and COM port for the GSM modem.

3. View menu strip:

It shows the statistics about the number of errors which were sent.
4. Help menu strip:
It shows this file.

System requirement:
1. Windows XP Professional, Windows server 2003, and any later versions of
Windows.
2. .Net framework 3.5.
3. GSM modem connected to one of the COM ports of the computer.

58
Appendex C: The Softwares Forums (Interface)

The Edit strip menu:

When the Edit menu strip is pressed the three options appear: Phone Numbers,
Modem, Timer. Each one when it is pressed it shows a new screen. The Timer shows
the Time interval forum. The Modem shows the com forum. The Phone Numbers

59
 shows the Enter The Phone numbers of the banks forum. Each of the previous
forums is mentioned later in this section.

The Time Interval forum:

It enables the operator to change the interval of the timer by entering the value
in the text box in ms.

60
The Enter The Phone numbers for the banks forum:

It contains text boxes for phone numbers to be entered in and two buttons. The
first button is the Apply button it saves the entered values. The second button
Ok saves the entered values and hides this forum.

61
The File strip menu:

It contains two options Execute and Exit. Execute starts the monitoring
process. Exit will hide this forum and close the program.

The help strip menu will show the Help Document which was mentioned
earlier.

62