Java程序辅导

University of Southern Queensland
Faculty of Engineering and Surveying
Real-Time Data Transmission and Control of
a Neocot Over the Internet
A Dissertation submitted by
Matthew Kinast
in fulfillment of the requirements of
Course ENG4112 - Research Project
Towards the degree of
Bachelor of Engineering
October 28, 2009
Abstract
The Mansell Neocot is a portable humicrib developed at Mansell Neona-
tal Transport Equipment (MNTE). When operating normally the Neocot
outputs diagnostic data every two seconds. This diagnostic data can be
captured by a Bluetooth module plugged into the side of the Neocot. This
Bluetooth module can transmit the diagnostic data to a local, connected
computer. Previously this computer logged the data and emailed the log file
to the MNTE Office for diagnostic purposes.
This project details the establishment of a connection over the Internet
between a computer connected to the Neocot via Bluetooth and a computer
at the MNTE Office. This connection allows the diagnostic data output from
a remote Neocot to be streamed in real-time directly back to the MNTE
Office.
Two software applications were developed to allow for the real-time data
transmission between the Neocot and a remote computer. ’MNTE Server’
is the application developed to receive incoming data at the MNTE Office.
’Neocot Diagnostics is an extended application of the original of the same
name that forwards data received from a local Neocot, over the Internet, to
the MNTE Office. The development and testing of the software and resulting
connection are documented in detail.
The goals of this project were acheived, resulting in real-time data trans-
mission from a remote Neocot to a local computer.
1
University of Southern Queensland 
 
Faculty of Engineering and Surveying 
 
 
 
ENG4111 Research Project Part 1 &  
ENG4112 Research Project Part 2 
 
 
 
Limitations of Use 
 
 
 
The Council of the University of Southern Queensland, its Faculty of Engineering and 
Surveying, and the staff of the University of Southern Queensland, do not accept any 
responsibility for the truth, accuracy or completeness of material contained within or 
associated with this dissertation. 
 
Persons using all or any part of this material do so at their own risk, and not at the risk of the 
Council of the University of Southern Queensland, its Faculty of Engineering and Surveying 
or the staff of the University of Southern Queensland.   
 
This dissertation reports an educational exercise and has no purpose or validity beyond this 
exercise. The sole purpose of the course "Project and Dissertation" is to contribute to the 
overall education within the student’s chosen degree programme.  This document, the 
associated hardware, software, drawings, and other material set out in the associated 
appendices should not be used for any other purpose:  if they are so used, it is entirely at the 
risk of the user. 
 
 
 
 
 
Professor Frank Bullen 
Dean 
Faculty of Engineering and Surveying 
 
Certificate of Dissertation
I certify that the ideas, designs and experimental work, results, analyses and conclusions 
set out in this dissertation are entirely my own effort, except where otherwise indicated 
and acknowledged.
I further certify that the work is original and has not been previously submitted for 
assessment in any other course or institution, except where specifically stated.
MATTHEW KINAST
0050045284
                                                  
Signature
                                                  
Date
Contents
1 Introduction 8
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Aims and Objectives . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 Dissertation Outline . . . . . . . . . . . . . . . . . . . . . . . 13
2 Background and Literature Review 15
2.1 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.2 Current Application . . . . . . . . . . . . . . . . . . . 16
2.2 Extreme Programming . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.2 Current Application . . . . . . . . . . . . . . . . . . . 18
2.3 Secure Sockets Layer (SSL) . . . . . . . . . . . . . . . . . . . 19
2.3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 20
2.3.3 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Virtual Private Network (VPN) . . . . . . . . . . . . . . . . . 22
2.4.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.2 Authentication and Security . . . . . . . . . . . . . . . 23
2.5 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.2 Proxy Server . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.3 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Methodology 26
3.1 System Design and Data Transmission . . . . . . . . . . . . . 26
3.1.1 System Design . . . . . . . . . . . . . . . . . . . . . . 26
3.1.2 Data Transmission . . . . . . . . . . . . . . . . . . . . 30
2
3.2 Software development . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 Hardware investigation . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . 33
4 Using Sockets and SSL 35
4.1 Sockets Without SSL . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1 Socket Connection Over LAN . . . . . . . . . . . . . . 37
4.1.2 Socket Connection Over Internet . . . . . . . . . . . . 39
4.2 Sockets With SSL . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1 SSL Socket Connection Over LAN . . . . . . . . . . . 42
4.2.2 SSL Socket Connection Over Internet . . . . . . . . . . 45
4.3 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . 45
5 Software Design 46
5.1 Neocot Diagnostics (Hospital Client Application) . . . . . . . 48
5.1.1 TCP Socket Connection and Authentication . . . . . . 51
5.1.2 Secure Data Transmission With SSL . . . . . . . . . . 51
5.2 MNTE Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.1 TCP Socket Creation . . . . . . . . . . . . . . . . . . . 54
5.2.2 Allow Client to Authenticate . . . . . . . . . . . . . . . 54
5.2.3 Receive Real-Time Data With SSL . . . . . . . . . . . 54
5.2.4 Display Data . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.5 Log Data . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . 56
6 Final Troubleshooting and Testing 57
6.1 Hardware Problems Encountered . . . . . . . . . . . . . . . . 58
6.2 Software Problems Encountered . . . . . . . . . . . . . . . . . 59
6.2.1 Hardware Dependent Problems . . . . . . . . . . . . . 59
6.2.2 Hardware Independent Problems . . . . . . . . . . . . 61
6.3 End-to-End Testing . . . . . . . . . . . . . . . . . . . . . . . . 63
6.3.1 Establishing Connections . . . . . . . . . . . . . . . . . 64
6.3.2 Sending Data . . . . . . . . . . . . . . . . . . . . . . . 69
6.3.3 Closing Connections . . . . . . . . . . . . . . . . . . . 73
6.3.4 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . 78
7 Two-way Data Transmission Hardware Investigation 79
7.1 Remote Computer to Local Computer . . . . . . . . . . . . . 81
7.2 Local Computer to Neocot . . . . . . . . . . . . . . . . . . . . 81
7.3 Software Assumptions . . . . . . . . . . . . . . . . . . . . . . 82
3
7.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . 82
8 Risk Assessment 84
8.1 Existing Safety Issues . . . . . . . . . . . . . . . . . . . . . . . 84
8.2 New Safety Issues . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.2.1 Staff Safety . . . . . . . . . . . . . . . . . . . . . . . . 85
8.2.2 Neonate Safety . . . . . . . . . . . . . . . . . . . . . . 85
8.2.3 Data Interception . . . . . . . . . . . . . . . . . . . . . 85
8.2.4 Data Vulnerability . . . . . . . . . . . . . . . . . . . . 86
8.3 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . 87
9 Conclusions and Further Work 88
9.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
9.1.1 Planned Work Completed . . . . . . . . . . . . . . . . 88
9.1.2 Planned Work Not Completed . . . . . . . . . . . . . . 89
9.2 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
9.3 Achievement of Project Objectives . . . . . . . . . . . . . . . 90
9.3.1 Objective 1 . . . . . . . . . . . . . . . . . . . . . . . . 91
9.3.2 Objective 2 . . . . . . . . . . . . . . . . . . . . . . . . 91
9.3.3 Objective 3 . . . . . . . . . . . . . . . . . . . . . . . . 92
9.3.4 Objective 4 . . . . . . . . . . . . . . . . . . . . . . . . 93
9.3.5 Objective 5 . . . . . . . . . . . . . . . . . . . . . . . . 93
9.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . 94
A Project Specification 99
B SSL Host Code 100
C SSL Client Code 106
D MNTE Server Code 111
E Neocot Diagnostics Code 144
F Neocot Diagnostics Log Output 173
G SSL Certificate Creation 178
4
List of Figures
1.1 Neonatal Retreival System . . . . . . . . . . . . . . . . . . . . 9
1.2 Neocot Diagnostics Port . . . . . . . . . . . . . . . . . . . . . 9
1.3 System Hardware Configuration and Data Flow . . . . . . . . 10
1.4 Objectives in Graphical Form . . . . . . . . . . . . . . . . . . 12
2.1 Neoblue Bluetooth Module . . . . . . . . . . . . . . . . . . . . 17
2.2 Extreme Programming Practices. Source: [Beck and Andres,
2005] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 SSL Architecture. Source: [Oppliger, 2003] . . . . . . . . . . . 20
3.1 Systems Design Option 1 . . . . . . . . . . . . . . . . . . . . . 27
3.2 Systems Design Option 2 . . . . . . . . . . . . . . . . . . . . . 27
3.3 Systems Design Option 3 . . . . . . . . . . . . . . . . . . . . . 27
3.4 SSL Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 VPN Illustration . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Chapter 4 Graphical Objective . . . . . . . . . . . . . . . . . . 36
4.2 Sockets Over LAN Architecture . . . . . . . . . . . . . . . . . 38
4.3 Screenshot - LAN Socket Transmission . . . . . . . . . . . . . 39
4.4 Sockets Over Internet Architecture . . . . . . . . . . . . . . . 40
4.5 Screenshot - Internet Socket Transmission . . . . . . . . . . . 41
4.6 Screenshot - LAN SSL Socket Transmission . . . . . . . . . . 44
5.1 Chapter 5 Graphical Objective . . . . . . . . . . . . . . . . . . 47
5.2 Original Neocot Diagnostics Flowchart . . . . . . . . . . . . . 49
5.3 New Neocot Diagnostic Flowchart . . . . . . . . . . . . . . . . 50
5.4 MNTE Server Flowchart . . . . . . . . . . . . . . . . . . . . . 53
6.1 Ideal End-to-End Test Connection . . . . . . . . . . . . . . . . 58
6.2 End-to-End Test Connection With SSL . . . . . . . . . . . . . 61
6.3 End-to-End Test Connection Without SSL . . . . . . . . . . . 64
6.4 MNTE Server - Start . . . . . . . . . . . . . . . . . . . . . . . 65
6.5 Neocot Diagnostics - Start . . . . . . . . . . . . . . . . . . . . 65
5
6.6 MNTE Server - Listening . . . . . . . . . . . . . . . . . . . . . 66
6.7 Neocot Diagnostics - No Connection Established 1 . . . . . . . 67
6.8 Neocot Diagnostics - No Connection Established 2 . . . . . . . 67
6.9 Neocot Diagnostics - Connect Bluetooth . . . . . . . . . . . . 68
6.10 MNTE Server - Connected . . . . . . . . . . . . . . . . . . . . 68
6.11 Neocot Diagnostics - Bluetooth Connected . . . . . . . . . . . 69
6.12 MNTE Server - Displaying Bluetooth Data . . . . . . . . . . . 70
6.13 Neocot Diagnostics - Transmitting Header Data . . . . . . . . 71
6.14 MNTE Server - Receiving Header Data . . . . . . . . . . . . . 71
6.15 Neocot Diagnostics - Transmitting Body Data . . . . . . . . . 72
6.16 MNTE Server - Receiving Body Data . . . . . . . . . . . . . . 72
6.17 Neocot at 24.3 Degrees . . . . . . . . . . . . . . . . . . . . . . 73
6.18 Neocot Diagnostics - Transmitting Error Data . . . . . . . . . 74
6.19 MNTE Server - Receiving Error Data . . . . . . . . . . . . . . 74
6.20 Neocot With Error 0.9 . . . . . . . . . . . . . . . . . . . . . . 75
6.21 Neocot Diagnostics - End Procedure . . . . . . . . . . . . . . 75
6.22 Neocot Diagnostics - Closed Connection 1 . . . . . . . . . . . 76
6.23 Neocot Diagnostics - Closed Connection 2 . . . . . . . . . . . 77
6.24 MNTE Server - Closed Connection . . . . . . . . . . . . . . . 77
7.1 Chapter 7 Graphical Objective . . . . . . . . . . . . . . . . . . 80
6
List of Tables
2.1 Port Numbers Assigned for Application Protocols That Run
on Top of SSL. Source: [Oppliger, 2003] . . . . . . . . . . . . . 21
3.1 Systems Design Option 1 Critical Analysis . . . . . . . . . . . 28
3.2 Systems Design Option 2 Critical Analysis . . . . . . . . . . . 28
3.3 Systems Design Option 3 Critical Analysis . . . . . . . . . . . 28
3.4 SSL and VPN Critical Analysis . . . . . . . . . . . . . . . . . 31
7
Chapter 1
Introduction
This introduction chapter gives a brief introduction to this dissertation and
what it aims to acheive. It gives a background of the Neonatal Retrieval Sys-
tem that this project is based on as well as previous project work completed
on the same system. The aims and objectives of the project are detailed as
well as an outline of what each chapter in this report is pertains to.
1.1 Background
Professor John Grant-Thomson is the manager of Mansell Neonatal Trans-
port Equipment, a number of years ago he developed the ’Neonatal Retrieval
System’. Figure 1.1 illustrates the entire system. It is made up of the Neocot,
which is a portable humidicrib for critically ill neonates. The device keeps the
neonate alive while being able to transport it in multiple forms of transport:
ambulance, aeroplane or helicopter. The next part is the Neosled, which
houses the Neocot and all required peripherals. The final part is the Mansell
Power Lifter which is a patented automated lifting system for the Neosled.
It allows it to be transferred into ambulances and planes and helicopters
without requiring any force from the user [Grant-Thomson, 1997].
The Neocot has two internal microprocessors which are the cornerstone
of the Neocot system. There is also a diagnostics port installed on one of the
internal circuit boards. The microprocessors send diagnostic information of
the Neocot’s current performance to this diagnostic port every two seconds.
Through the connection of a serial cable this data can be transmitted to a
computer terminal. There it can be read and interpreted. This data provides
information about the current Neocot state and any error reports. Figure
1.2 depicts the diagnotic port with a connected serial cable [Grant-Thomson,
1998].
8
Figure 1.1: Neonatal Retreival System
Figure 1.2: Neocot Diagnostics Port
9
Figure 1.3: System Hardware Configuration and Data Flow
After previous project work was completed to wirelessly transmit diagnos-
tic information, the Neocot now boasts an external socket connected to the
internal diagnostic port. A Bluetooth module can plug into this socket, read
the diagnostic information output from the Neocot and wirelessly transmit it
to a local, connected computer. The aim of the previous project was to allow
error diagnostics to take place while the Neocot remains in the hospital. The
problem may then be able to be fixed without having to return the Neocot
to the Mansell Neonatal Office, reducing the down time of a Neocot when
errors occur. [Steffensen, 2008]
The system uses Bluetooth to wirelessly transmit the data and the soft-
ware modules used were developed using the Extreme Programming method.
Both aspects will be furthur discussed in the next two sections as this prject
builds on the previous work. [Steffensen, 2008]
It should also be noted that transmission of diagnostic data will never
take place while the Neocot is in use. The bluetooth module and accompa-
nying software are diagnostic tools only. Sufficient warnings are placed in
the software application as well as the accompanying software. A life would
be put at risk if the diagnostic tools were to be used while an infant was in
the Neocot, therefore this situation will never occur.
1.2 Aims and Objectives
The aim of this project is to design a system to allow the diagnostic data of a
Neocot anywhere in the world to be transmitted in real-time over Bluetooth
and over the Internet to a computer in the Toowoomba Office of Mansell
Neonatal Transport Equipment (MNTE). The transmission of data from the
Neocot to a local computer has already been developed and works using the
Bluetooth protocol. This project focuses on the real-time transmission of this
data from the local computer to a computer at the MNTE Office. Figure 1.3
illustrates the flow of the diagnostic data.
The objectives for this project are listed in the Project Specification in
Appendix A. They are briefly summarised below.
10
Initially a one-way, real-time connection will be able to be established
between a server computer at the Mansell Neonatal Transport Equipment
(MNTE) Office and any hospital PC with a Neocot connected to it via
Bluetooth. This Bluetooth connection is already established from previous
project work on the topic. (The work done and background information on
the topics involved is discussed further in the next chapter.)
The connection from the hospital PC client to the Mansell Neonatal
Server will then be established focusing on authentication, security and relia-
bility. Specifically developed software modules will be installed on a Mansell
Neonatal server and the hospital client. This will allow for the creation of a
one-way, real-time, connection and the transmission of data across it. The
protocol used to transmit the data is determined by conducting a critical
analysis on several common techniques. More details are discussed in the
next chapter. The hardware configuration of the server at the MNTE Office
also is determined by a critical analysis conducted and discussed in the next
chapter of this report.
The data is captured on the Mansell Neonatal server and displayed in a
meaningful way. The capturing and displaying will be done by specifically
developed software. The data will be displayed and recorded for use by staff
at the Neonatal Transport Equipment Office.
Once this system is developed and software modules complete, the entire
system will be tested. This will allow for a debugging process and refinement
of the software. If time permits detailed documentation and user manuals will
be developed to allow for the professional use of this system with deployed
Neocot’s.
An investigation to determine the required hardware to allow for two-way
data transmission will be conducted. This two-way connection will allow
the Mansell Neonatal PC to send signals back to the Neocot through the
hospital PC. The purpose of these signals would be to control the Neocot’s
basic functions.
Figure 1.4 depicts the graphical version of the objectives of this project.
The Neocot Diagnostics application is the application to be developed for
the hospital PC allowing for the client connection and transmission of data.
The MNTE Server apllcation is the software to be developed for the MNTE
Office PC allowing for the host connection and the receiving and displaying
of data. The red line indicates the socket connection that is to be established
between the two applications over the Internet. The blue line indicates the
two-way data connection that is set as an optional goal and requires the
11
Figure 1.4: Objectives in Graphical Form
12
completion of the two-way data transmission hardware investigation to be
implemented.
Each of these different aspects of the project will be discussed in the
following chapters of this report. The dissertation outline in the next section
gives a breif outline of each of these chapters.
1.3 Dissertation Outline
An outline of each chapter of this dissertation is shown below.
Chapter 2: Literature Review In this chapter the background, cur-
rent application and future application of the Bluetooth protocol is discussed.
The definition of Extreme Programming is looked at as well as its current ap-
plication and future application. Secure Sockets Layer protocol and Virtual
Private Network’s are examined and discussion focuses on their authenti-
cation, reliability and security. A brief overview of Firewalls is also given.
Proxy and Gateway servers are discussed as well as the security issues per-
taining to firewalls.
Chapter 3: Methodology This chapter discusses the methodology be-
hind choosing a system design and data transmission technique. Critical
analyses of System Design options and Data Transmission Techniques are
undertaken and illustrated. The methodologies behind software development
and hardware investigation are also discussed.
Chapter 4: Using Sockets and SSL In this chapter establishing a
connection between insecure sockets over a LAN and the Internet is inves-
tigated and demonstrated. Also establishing a connection between secure
sockets using SSL over a LAN and the Internet in discussed. The creation of
an SSL certificate is discussed and demonstrated as well.
Chapter 5: Software Design This chapter illustrates the design and
flowcharts of the ’Neocot Diagnostics’ and ’MNTE Server’ applications. The
software of each application is then broken down into modules and each mod-
ule undergoes individual testing.
Chapter 6: Final Troubleshooting and Testing In this chapter prob-
lems encountered during the project pertaining to hardware and software are
discussed. Also an end-to-end test between the ’MNTE Server’ application
and the ’Neocot Diagnostics’ is documented and illustrated.
13
Chapter 7: Hardware Investigation In this chapter hardware re-
quired at the MNTE Office and the hospital PC to allow for two-way data
transmission is investigated. Assumptions made about the software in the
hardware investigation are also stated.
Chapter 8: Risk Assessment This chapter gives an overview of exist-
ing safety issues that existed before current project work. New safety and
ethical issues aroused by this project are also investigated and discussed.
Chapter 9: Conclusions and Further Work The final chapter dus-
cusses the level of achievement of each of the original project goals stated on
the Project Specification, Appendix A of this report. Planned project work
that was completed is listed as well as remaining project work that not reach
completion. Further work that can be done on the topic is listed also.
14
Chapter 2
Background and Literature
Review
This chapter discusses underlying principals, techniques and protocols used
by the project. The basics of the Neonatal Retreival System and the Neocot’s
role within this system have already been explained in the previous chapter.
Existing systems to transmit data from the Neocot wirelessly and in real-time
are in place after previous project work on this topic. Bluetooth transmission
exists between the Neocot and a connected hospital PC and the basics of this
transmission method are discussed.
Extreme Programming method is also discussed as it was used to develop
existing software and will be used to develop the software concerning this
project.
An explanation and insight into the workings of Secure Sockets Layer
(SSL) protocol as well as Virtual Private Networks (VPN) is given. Firewalls
are also looked at briefly.
2.1 Bluetooth
This section will explain the basics of the Bluetooth wireless transmission
protocol and how it works. It then explains its current use in the Neocot
system and how it is implemented. The future plans and direction for its use
within the system are then discussed.
2.1.1 Definition
The development of Bluetooth technology began in 1996 by Ericson. The
aim was to develop a protocol that could connect common devices, capa-
15
ble of replacing the wires that are used to connect devices, with wireless
transmission. In 1998 Ericsson joined forces with Nokia, IBM, Toshiba, and
Intel to form a special interest group (SIG). This group continued work on
Bluetooth technology. [Dursch et al., 2004].
Although Bluetooth was originally designed to simply replace wires be-
tween two devices, it can actually form a network of devices. Up to eight
devices can be linked together at one time, one controlling the network la-
beled the ”master” and up to seven more ”slaves”. It is also possible to
extend this network which is called a ’piconet’ and dedicate one slave to
connect to another slave on a different piconet, connecting the two piconets
[Morrow, 2002].
Being wireless, Bluetooth is more susceptible to outside attacks than
wired connections. Any Bluetooth device can intercept data being trans-
mitted if it is in range. This range is typically within a 10 metres radius of
the transmitting device. Because of this susceptibility, security measures are
in place to protect transmitted data. For two devices to transmit data they
first have to pair with each other using a PIN that is only known to the two
parties. To pair, the devices have to specify the same PIN. Authentication
process then uses a shared secret key or a link key to verify that each device
is exchanging data with the correct destination [Gehrmann, 2004].
2.1.2 Current Application
Bluetooth communications between a Neocot and a local connected com-
puter are currently possible using a Bluetooth module for the Neocot. This
Bluetooth module plugs into the Neocot which is internally wired to the in-
ternal diagnostics port discussed earlier in this report. Figure 2.1 shows the
Bluetooth module in use and highlights the port it plugs into on the side of
the Neocot.
Previously, before work on this project began, when the software dis-
tributed with the Bluetooth module was installed and run on a local hospital
computer within range of a Bluetooth enabled Neocot a connection between
the two was established. The software set up the connection and started re-
ceiving the information the Neocot was transmitting on its diagnostics port
in real-time and saved it to a text file. After a period of time the user of
the software on the hospital PC was given an option to email the log file to
MNTE Office. The file was used to diagnose the Neocot at the office.
This project allowed for the extension of the software module allowing
for real-time data transmission. The new software distributed with the Blue-
tooth module also establishes a connection between the local hospital com-
puter it is installed on and a Bluetooth enabled Neocot in range. The real-
16
Figure 2.1: Neoblue Bluetooth Module
time data transmission now extends from the Neocot straight to the MNTE
Office PC, via the hospital PC. The hospital PC also logs the information
that it is forwading onto the MNTE Office. The PC at the MNTE Office
also saves the data into a text file for furture reference.
2.2 Extreme Programming
This section will explain the basics of Extreme Programming Methodology
and the principals behind it. It then explains this methodology’s application
within the current software and how it was implemented.
2.2.1 Definition
Extreme Programming (XP) is a methodology to program source code eas-
ily and efficiently. It is regarded as a common programming methodology
and popular among programmers. The methodology encompasses everything
that concerns the development of source code from the initial planning stages
to the final stage of testing and deployment. Development of code under the
XP methodology is based on five values [Wells, current May 2009].
The most important value is communication. Good communication be-
tween programming team members provides for faster problem solving and
17
boosts efficiency. Simplicity is the next value. Keeping the programming sim-
ple will reduce the amount of resources required as well as make the program
a lot easier to follow and integrate with other modules. The third value XP
is based on is feedback. Feedback is essential in keeping the programming up
to date. Previous decisions may appear wrong in retrospect and appropriate
feedback will bring solutions to these problems. The next value is Courage.
Problems with the code need to be solved as soon as possible. Courage is
required to quickly identify problems and devise a solution to solve them.
The last value is Respect. Respect must be shown within the programming
team no matter how large or small. All members must show respect to each
other and in turn they will be respected. This allows for enhanced teamwork
and speedier solutions [Jeffries, 2004].
XP also has principals for team members to abide by, they are as follows:
Allow Rapid Feedback, Assume Simplicity, Make Incremental Changes, Em-
brace Change, Deliver High-Quality Work, Teach Learning, Make a Small
Initial Investment, Play to Win, Conduct Concrete Experiments, Promote
Open, Honest Communication, Work with People’s Instincts, Not Against
Them, Accept Responsibility, Adapt As Necessary, Travel Light and Mea-
sure Honestly [Pearman and Goodwill, 2006].
XP defines practices that if abided by provide the programming team with
greater efficiency and quality. The practices are divided up into separate
areas each with its own branches. The main two groups are primary and
corollary. To use the corollary practices, the primary practices must first be
in use. Figure 2.2 illustrates the composition of these practices.
There is always a set of optimal practices to follow for certain program-
ming, though not always the same for each project and sometimes they don’t
remain the same throughout a single project. Review of practices must be
conducted throughout programming stages to make sure that optimal prac-
tices are selected [Stephens and Rosenberg, 2003].
2.2.2 Current Application
The current software developed for use with the Bluetooth module was devel-
oped under the XP methodology. This methodology proved successful and
provided a simple approach to programming multiple modules, all requiring
testing. Problems were encountered but solutions were quickly found due
to the following of the rules set out by XP methodology. Solutions defined
by XP methodology such as the two-pronged approach were utilized; this
involved simultaneously implementing two solutions to see which one was
most appropriate solution [Beck and Andres, 2005].
Another reason to implement XP methodology was for easy integration
18
Figure 2.2: Extreme Programming Practices. Source: [Beck and Andres,
2005]
with previous code. Previous code required to be extended and was developed
into the current code. By using the same programming methodology the same
underlying principals are evident in all code used and allowed for simple and
easy integration of modules.
2.3 Secure Sockets Layer (SSL)
This section looks at the basics principals of Secure Sockets Layer protocol to
send information securely over an unsecure network such as the Internet. It
explains how it works and discusses its features focusing on Authentication,
Security and Reliability.
2.3.1 Definition
SSL is a security protocol implemented at the transport layer of Wed-based
applications. It provides a secure way to transmit data packets over the in-
ternet. These data packets can be HTTP (web browser traffic), POP3 (email
traffic), FTP (file transfer traffic) and many more. Figure 2.3 illustrates the
architecture of the SSL protocol [Thomas, 2000].
It can be seen from Figure 2.3 that SSL is implemented as a sub-layer
19
Figure 2.3: SSL Architecture. Source: [Oppliger, 2003]
between the transport layer and the application layer of data packets. This
is the reason SSL can be used with multiple applications. It should also be
noted that an S is appended to most application names if they are used in
conjunction with the SSL protocol. [Oppliger, 2003].
2.3.2 Authentication
An SSL is made up of 5 sub protocols. Firstly there is the underlying Record
protocol. This sub protocol takes the information from the sub protocols
above it and fragments it, compresses it and then encrypts it. There are four
more sub protocols above the Record protocol as can be seen from Figure
2.3, these sub protocols are SSL Handshake Protocol, SSL Change Cipher-
spec Protocol, SSL Alert Protocol and the SSL Application Data Protocol
[Oppliger, 2003].
The SSL Handshake Protocol is the main step in providing authentication
in an SSL connection. This protocol allows the client and server parties to
agree on the specifications of the connection, this includes deciding which
SSL protocol version will be used, what cipherspec will be used and also how
the data will be compressed. It also generates the master secret which allows
for the creation of keys to be used by both parties to encrypt and decrypt the
data. These keys can also be used by the server and client to authenticate
each other. Certificates can also be sent from the server to the client to prove
its reliability and authenticate itself. [Wyler, 2007].
The Change Cipherspec Protocol allows the current Cipherspec, which is
used to encrypt the data, to be changed. The SSL Alert Protocol consists of
an alert level and an alert description and sends this alert through the Record
Protocol. Finally the SSL Application Data Protocol transfers application
data straight to the Record Protocol [Persiano and Visconti, 2003].
20
Keyword Port Description
nsiiops 261 IIOP name service over TLS/SSL
https 443 HTTP over TLS/SSL
smtps 465 SMTP over TLS/SSL (former ssmtp)
nntps 563 NNTP over TLS/SSL (former snntp)
ldaps 636 LDAP over TLS/SSL (former sldap)
ftps-data 989 FTP (data) over TLS/SSL
ftps 990 FTP (control) over TLS/SSL
telnets 992 TELNET over TLS/SSL
imaps 993 IMAP4 over TLS/SSL
ircs 994 IRC over TLS/SSL
pop3s 995 POP3 over TLS/SSL (former spop3)
Table 2.1: Port Numbers Assigned for Application Protocols That Run on
Top of SSL. Source: [Oppliger, 2003]
2.3.3 Reliability
For SSL to work, both the client and the server involved in the communi-
cation must be aware that the other is using SSL protocol. The simplest
way to implement this necessity is to use the port numbers dedicated to each
application protocol. These numbers are assigned by the Internet Assigned
Numbers Authority (IANA) and are reserved for use with the corresponding
application. A table of port numbers assigned for application protocols that
run on top of SSL is shown in Table 2.1 [Oppliger, 2003].
When both client and server parties are using the same port to transmit
data then a reliable connection is established. Although SSL connections,
especially HTTPS, can be slow initially due to encryption and decryption
stages once the connection is established the pause appears insignificant be-
cause the data is then transmitted securely and reliably. The fact that most
banks implement SSL in their online banking software highlights the security
and reliability of an SSL connection [Lee et al., 2007].
2.3.4 Security
As with all security protocols for data transmission across the internet there
are security issues that exist with SSL. A minor concern is the threat of traffic
analysis. The IP addresses of both client and server parties are not encrypted
in the data packet, neither is the TCP port numbers in use. Because of this
an unknown party may intercept this data and determine its origin and
21
destination and in some cases some of the actual data [Wagner and Schneier,
1996].
Another major concern is that by flooding the SSL server with ciphertexts
an unknown source can ultimately decode the entire session by acquiring the
master secret and then using it to determine the keys used to encrypt the
data. Although this is possible the flooding of the SSL server requires from
300,000 to 2,000,000 ciphertexts to be sent. Also there are ways, not discussed
here, to protect the SSL server against this attack [Schneier].
2.4 Virtual Private Network (VPN)
This section looks at the basics principals of establishing a Virtual Private
Network over an unsecure network such as the Internet and using protocols
to send data over the connection. It explains how it works and discusses its
features focusing on Authentication and Security.
2.4.1 Definition
A Virtual Private Network (VPN) is a secure and private network imple-
mented by an individual or company that uses existing network infrastruc-
ture. The existing infrastructure that a VPN communicates over can be any
existing network but is most commonly the Internet. It sets up a secure and
encrypted tunnel between two endpoints and information can be sent over
the existing and possibly unsecure network [Rosen, 2008].
VPN’s allow excellent portability for individuals and companies. Branch
offices and individual workers can easily access Main office resources if a VPN
is set up between their computer or LAN and the Main office’s LAN. A VPN
can also allow an individual to access their home computer from another
machine, say a laptop if a VPN is implemented between the two computers.
[Morgan, 1999].
VPN’s are also a very cost effective alternative to leased lines. By using
existing infrastructure, such as the Internet, no additional communication
lines need to be implemented. A leased line dedicated to communications
between offices can be quite expensive. By using existing networks there is
no need for paying for a dedicated line and savings inscrease greatly. [Cohen
and Kaempfer, 2000].
There are many different ways a VPN can be physically implemented;
there are multiple termination methods and also different topology imple-
mentations. The VPN can be terminated at different places in the network.
Termination at the edge router allows for all the information coming in and
22
out of the private LAN to be processed by the firewall, increasing security on
the connection but decreasing throughput. The second termination method
is termination at the corporate firewall which allows easy access from branch
clients to the main server and only requires a single authentication process.
Termination can also occur at a dedicated VPN appliance. This is most
suitable for LAN to LAN connections [Henmi et al., 2006].
Different topology for the VPN can also be implemented to suit the needs
of the user. The topologies most commonly used are: Fully meshed, Partially
meshed, Star, Hub and Spoke and finally Remote Access [Henmi et al., 2006].
2.4.2 Authentication and Security
Security and Authentication of a VPN depends on what protocol is used to
implement the network. The protocols that can be used with a VPN include:
Secure Sockets Layer (SSL), Public Key Infrastructure (PKI), Internet Pro-
tocol Security (IPSec), Layer 2 Forwarding (L2F), Point-to-Point Tunneling
Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP) and Generic Routing
Encapsulation (GRE). [Gupta, 2003].
These protocols all provide a level of security and authentication. In most
cases keys and master secrets are generated. These keys can then be used to
verify identity of the client and server as well as encrypt and decrypt data.
Some protocols also use certificates sent from the server to allow the client
to verify and authenticate their identity. [Edwards et al., 2006].
With the authentication and encryption used in conjunction, these pro-
tocols provide excellent security for the established VPN. Client and Server
authenticate each other to make sure data is sent and received in the right
locations and the data is encrypted with private and public keys before it
is sent so no sensitive data is easily intercepted and viewed by unknown
sources. This makes it very hard but not impossible to illegitimately access
the transmitted data. [Herscovitz, 1999].
As in most cases VPN’s can still be accessed from an outside source. It is
still possible to access and modify data being sent especially if they are using
the internet as their base infrastructure. The security of the VPN depends
on the firewall used in conjunction with it. If the firewall in implemented
correctly than the security of the VPN will increase. [Liu and Chen, 2008].
Firewalls are discussed more in the next section.
23
2.5 Firewalls
This section looks at the basics principals of firewalls. It discusses different
types of firewalls, their differences and how they work.
2.5.1 Definition
A firewall is a piece of hardware or a software program that is in place to
separate and protect a private network or LAN from the internet. It is
positioned between the internet and the LAN and decides what data can
go in and out based on the rules programmed into it. It stops data that
should not be coming in from the internet to the LAN such as hacker attacks
and also has control over what data can be sent from the LAN out into the
internet. The firewall can also give different access privileges to different
LAN groups and single machines [Dempster and Eaton-Lee, 2006].
The two main types of firewalls are Proxy and Gateway, Proxy being the
most commonly used. Gateway can be broken down further into two main
categories, Packet Filters and Stateful Inspection Firewalls [Edwards et al.,
2006].
2.5.2 Proxy Server
A proxy server disassembles every packet that comes in, inspects it and
then reassembles it. Although this requires more time than a Gateway it is
much more effective and stops a lot more harmful material from entering the
LAN. Proxy’s also require to be specific for each application that they are
protecting, this allows for excellent customisation but creates dependency on
the developer of this software if an updated version is released that the proxy
does not support [Goncalves, 2000].
A proxy server serves as a middle man between any client on the internet
and a machine within the LAN it is protecting. It will only display its own
IP address, so all machines within the proxy are seen to have the same IP
address, the address of the proxy. It will then establish a connection to the
server that the client is wishing to access, or access the information the client
is requesting and pass this information back to the client [Sriram, 2002].
2.5.3 Gateway
Gateway firewalls focus on packet inspection and are broken into two main
sections, Packet Filtering and Stateful Packet Inspection. Packet Filtering
is a very basic form of firewall. Filters are set up in the firewall and allow
24
packets in based on the rules of the filter the packet is trying to get through.
Although these firewalls are not as effective as proxy’s they are still very
useful and widely used on individual computers. Stateful Packet Inspection,
also known as Stateful Firewall, stores the states of the network connections
in the firewall. It has a set of rules for each network connection and lets
in packets that these rules allow and rejects the packets they do not allow
[Vacca and Ellis, 2005].
2.5.4 Security
It is possible to get past firewalls and it has been done many times. There
are many ways that firewalls can be breached illegally, some of these are:
Use of backdoors in application software or operating system software, email
flooding or spam email, remote access and viruses. Firewalls can be imple-
mented excellently but still not stop everything. Users have to be aware that
by being connected to the internet they are always at risk of attack from an
unknown, outside source [Strebe and Perkins, 2002].
2.6 Chapter Summary
This Chapter summarised the main issues that are used and will be encoun-
tered within this project. The Bluetooth protocol was discussed and its role
in this project was discussed. Extreme Programming was also examined
and its values, principles and practices were discussed. Secure Sockets Layer
protocol and Virtual Private Network were investigated and reported upon.
Firewalls, both Proxy and Gateway Servers were also discussed.
25
Chapter 3
Methodology
This chapter looks at the methodology used throughout the project. Be-
fore development on the project software could begin, system design and
data transmission techniques had to be decided upon. The critical analysis
methodology is used and illustrated in the selection of system design and
data transmission technique. Software design methodology and hardware
investigation methodology are also briefly discussed.
3.1 System Design and Data Transmission
To determine which system design to implement and which data transmission
technique to use, a critical analysis methodology was used. In both cases
there were multiple options to choose from each with different advantages
and disadvantages. A critical analysis compared each option side by side
and determined which one was the most suitable for this project.
3.1.1 System Design
The critical analysis of system design rated the same important aspects for
each option out of a possible 10 marks and compared them to each other.
These aspects are: Ease of use for hospital staff, Ease of use for MNTE staff,
Portability and Required MNTE resources. Each system design option was
rated against the same criteria and produced an overall score allowing for
a fair comparison. Before the analysis was undertaken it was deemed the
highest performing system design overall would be the most suitable option
for this project. This option would be chosen unless an unseen factor was
introduced such as any limitations at Mansell Neonatal Transport Equip-
ment. Figure 3.1, 3.2 and 3.3 illustrate the system design options that were
26
Figure 3.1: Systems Design Option 1
Figure 3.2: Systems Design Option 2
Figure 3.3: Systems Design Option 3
available. Tables 3.1, 3.2 and 3.3 contains the critical analysis data for each
of the three system design option.
Figure 3.1 depicts System Design Option 1. This design option has the
Neocot transmitting diagnostic data across the Bluetooth connection to a
local hospital computer. Here the data is logged and transmitted over the
Internet to the MNTE Server computer. One computer receives the data
and also displays it to the user in a meaningful manner.
Figure 3.2 depicts System Design Option 2. This design option has the
Neocot transmitting diagnostic data across the Bluetooth connection to a
local hospital computer. Here the data is logged and transmitted over the
Internet to the MNTE Server computer. The MNTE Server computer only
27
Systems Design Option 1
Ease of use for hospital staff 10
Ease of use for MNTE staff 10
Portability 5
Required MNTE resources 8
Total: 33
Table 3.1: Systems Design Option 1 Critical Analysis
Systems Design Option 2
Ease of use for hospital staff 10
Ease of use for MNTE staff 7
Portability 7
Required MNTE resources 6
Total: 30
Table 3.2: Systems Design Option 2 Critical Analysis
Systems Design Option 3
Ease of use for hospital staff 10
Ease of use for MNTE staff 5
Portability 10
Required MNTE resources 5
Total: 30
Table 3.3: Systems Design Option 3 Critical Analysis
28
receives the data it is being sent. It allows other local MNTE computers to
connect to it and serve as display clients. These local machines can connect
to it and request the data be sent to them where they will display it to the
user in a meaningful manner
Figure 3.3 depicts System Design Option 3. This design option has the
Neocot transmitting diagnostic data across the Bluetooth connection to a
local hospital computer. Here the data is logged and transmitted over the
Internet to the MNTE Server computer. The MNTE Server computer only
receives the data it is being sent. It allows not only other local MNTE
computers to connect to it and serve as display clients but also remote PC’s
as well. A remote PC can connect to the MNTE Server over the Internet
and request diagnostic data be sent to it. This machine can then display the
data to the user in a meaningful manner as well as still allowing for local
display clients.
As tables 3.1, 3.2 and 3.3 show Ease of use for Hospital staff is always
very good for each option. This option is rated on the scale of 1 to 10, 1
being very bad ease of use for hospital staff and 10 being very good ease
of use for hospital staff. The software that was originally developed logged
the cot for an hour and then required the user to input details and it then
automatically generated an email which was sent to the MNTE office. This
process will change, the emailing step will be removed along with a number
of other changes changes to allow data streaming. The changes the user sees
however, will be minimal, therefore it will still be just as simple and easy for
the hospital staff to run their side of the connection.
Ease of use for MNTE staff is again rated on the scale of 1 to 10, 1
being very bad ease of use for MNTE staff and 10 being very good ease
of use for MNTE staff. With the introduction of more hardware at the
MNTE end of the connection, the ease of use of the system will decrease. If
only one machine was being used as a server and display client this would
be the simplest setup and be relatively easy to operate for MNTE staff.
With the introduction of multiple display clients, local or remote as well
as the dedicated server, the connection will become more complex therefore
reducing the ease of use for the MNTE staff.
Portability is rated on a scale of 1 to 10, 1 being not portable at all
and 10 being very portable. The portability of option 1 and 2 are fairly
limited. Option 1 only uses the one machine. This machine could be set
up anywhere in the MNTE office but once set up will most likely remain
fixed although still able to be moved. Option 2 allows for a dedicated, fixed
server anywhere in the MNTE office which could stream the data to any
connected computer in the MNTE office. This allows viewing of the data
anywhere in the MNTE office without having to move machines. Option 3
29
allows the greatest portability, essentially allowing an MNTE staff member
to be anywhere with an internet connection. They would connect to the
MNTE dedicated server in our office and the data could be streamed to
them, wherever they are.
Required MNTE resources is also rated on a scale of 1 to 10, 1 requiring
a lot MNTE resources while 10 does not require any MNTE resources at all.
Option 1 only required one machine in use at the MNTE office. Option 2
required one machine to be a dedicated server. It also required additional
machines to be available to connect to the dedicated server and display the
data. Option 3 requires everything option 2 does as well as available remote
machines, most likely laptop computers. These would also be able to connect
to the dedicated server and display the streamed data.
This critical analysis showed that option 1 is the most suitable system
design option for this project. Option 1 was therefore used as the system
design.
3.1.2 Data Transmission
The critical analysis of data transmission implementation was very similar
to the system design analysis. There were only 2 options to choose from.
The options being: SSL and VPN. Both are discussed in detail earlier in
this report in Chapter 2. Just like the system design critical analysis each
system design option was rated against the same criteria and produced an
overall score allowing for a fair comparison. Again, it was deemed the high-
est performing system design overall would be the most suitable option for
this project. This option would be chosen unless an unseen factor was in-
troduced such as any limitations at Mansell Neonatal Transport Equipment.
This critical analysis obviously uses different criteria, these are: Security,
Authentication, Reliability and Ease of implementation. Each criterion is
rated out of a possible 10 marks. The two methods are illustrated in Figures
3.4 and 3.5. Table 3.4 contains the critical analysis data for both of the data
transmission options.
The security criterion is given a grade between 1 and 10, 1 being non-
secure and 10 being very secure. The security capability of a VPN can be
a lot higher than that of an SSL connection. VPN can employ a various
range of security techniques that are quite secure, explained in more length
in Chapter 2 of this dissertation. Also explained in the same chapter is the
SSL security, although quite strong it does have a few weaknesses. Traffic
analysis and flooding of the SSL server with ciphertexts are possible ways to
breach SSL’s security measures.
The authentication criterion is also marked from 1 to 10, 1 having no au-
30
Figure 3.4: SSL Illustration
Figure 3.5: VPN Illustration
SSL VPN
Security 6 9
Authentication 8 9
Reliability 9 7
Ease of Implementation 9 6
Use behind Firewall 9 3
Total: 41 34
Table 3.4: SSL and VPN Critical Analysis
31
thentication and 10 have excellent authentication techniques. VPN and SSL’s
authentication procedures are again explained more in depth in Chapter 2
of this dissertation. VPN is able to employ various forms of authentication
including the use of master keys or certificates or both. SSL mainly uses cer-
tificates as its form of authentication. It has a handshake protocol allowing
for the server and the client to interact and authenticate each other. This is
done through verification of a certificate against the host or client it is meant
to be connecting to.
Reliability is given a mark from 1 to 10, 1 being unreliable and 10 being
very reliable. Reliability is always an issue when dealing with wireless net-
works and insecure transport networks such as the Internet. In both cases
there is the possibility of data packets being mixed up in transmission and
not delivered in the corrected order as well as possible fragmentation. The
main difference in the reliability of VPN and SSL is that a VPN cannot con-
firm to a user that information has been received on the other end of the
connection they are using.
Ease of implementation is also graded from 1 to 10, 1 being very hard to
implement and 10 being very easy to implement. Ease of implementation is
also very important along with security, authentication and reliability. The
network technique needs to be easily employed and requiring only a little,
if any, extra work and configuration on the hospital end of the connection.
SSL meets these requirements very well, as explained in chapter 2 of this
dissertation while a VPN connection requires configuration of software at
the hospital end of the connection.
Use behind Firewall is again graded from 1 to 10, 1 being not being able
to use behind a firewall to 10 being extremely simple to use behind a firewall.
Both MNTE and hospitals have firewalls and the chosen method needs to
be able to work behind firewalls with relative ease. SSL scores very highly
in this criteria because it is very simple for it to transmit through a firewall.
The majority of firewalls allow Internet traffic and secure internet traffic.
Sending data using SSL will simply make it look like secure Internet traffic
allowing it to transmit through the firewall. A VPN connection however,
requires configuration of software to allow for transmission of a firewall and
is not relatively easy, hence the low score.
As can be seen from the results of the critical analysis SSL scored a higher
overall score and therefore is the data transmission technique implemented
throughout this project.
32
3.2 Software development
The methodology chosen for software programming will be Extreme Pro-
gramming. This is to align with Lane Steffensen’s previous work. The Ex-
treme Programming method was used to develop software for that project.
As code from that project is being used and edited in this project, the same
method used to create that code will be used to edit it. Theoretically this
will allow for easy editing of code and simple integration with any new code
developed for this project. Visual C# will be the programming language
used to develop the software for this project, the reason again being that
previously developed software that will be used and edited for this project
was written in Visual C#.
3.3 Hardware investigation
Hardware implementation for two-way data transmission is only an optional
requirement of this project. The implementation is dependent on the initial
investigation. Investigate will be conducted to determine if and what hard-
ware is required in the Neocot system to allow for two-way data transmission.
The method chosen for this investigation is Schematic Research. There
are schematics detailing the entire Neocot system. From adequate research
of these schematics it can be determined whether additional hardware is
required to allow for two-way data transmission. If additional hardware is
required than how this hardware can be implemented can also be determined
from research of the schematics. If there is adequate time and if the initial
investigation proves two-way data transmission is possible then the required
hardware will be implemented.
3.4 Chapter Summary
This Chapter discussed critical analysis methodolgy used to determine which
system design option and which data transmission technique to use in this
project. It contains two critical analyses performed for this project. The first
critical analysis was performed on three different system design options to
decide which option was most suited to this project. System Design Option
1 scored a total of 33 out of 40 as opposed to the 30 out of 40 the other two
options scored making it the most suitable option for use in this project.
The second critical analysis was to determine which data transmission
technique to use. The two options to decide between were Secure Sockets
Layer (SSL) and a Virtual Private Network (VPN). VPN only score 34 out
33
of 50 while SSL score 41 out of 50 making it the option implemented in this
project.
The methodology behind the software development and the hardware
investigation to be performed as part of this project was also discussed.
34
Chapter 4
Using Sockets and SSL
This chapter looks at the use of sockets and Secure Sockets Layer (SSL)
throughout the project. It details the steps taken to implement the trans-
mission of data over a LAN using insecure sockets, without SSL. It also
details the same for the transmission of data over the Internet using insecure
sockets without SSL.
The chapter then addresses the implementation of the transmission of
data over a LAN and the Internet using secure sockets with SSL. The SSL
connections utilize a certificate for authentication. The creation of the cer-
tificate used in this report is covered in Appendix G of this report.
A graphical overview of the objectives of this project was given in Chapter
1, Figure 1.4 of this report. The objectives for this Chapter have been taken
from this this Figure and are shown alone in Figure 4.1. Figure 4.1 depicts
the red line socket connection present in Figure 1.4. It concentrates on the
creation of the listening socket, the creation of the client socket and the ability
to connect these two sockets to establish a connection over the Internet.
In the case of implementing SSL with a TCP socket, port 443 was used.
The Internet Assigned Numbers Authority states that this port is used for:
http protocol over TLS/SSL. Although it is not http traffic being transmitted,
by using port 443 it an easier task to transmit data through installed hospital
firewalls. [Internet Assigned Numbers Authority, current September 2009]
4.1 Sockets Without SSL
In Chapter 3 of this report a critical analysis is performed to determine the
most suitable data transmission technique for use with this project. The
results show that SSL is most suitable and this is the technique that is
implemented in the source code. SSL works as an extra security layer on top
35
Figure 4.1: Chapter 4 Graphical Objective
36
of an existing socket connection.
A TCP/IP socket allows transmission of data using the TCP/IP protocol
and requires an IP address and a port number for creation. In the case of a
TCP/IP host socket the IP address is that of the machine the socket is run-
ning on and the port is anything the user defines. A client socket’s IP address
is that of the machine it wishes to connect to and the port number must be
the same as the port number defined by the host socket it is connecting to.
The host socket must be listening for incoming connections before the
client socket can connect therefore the the host socket requires to be opened
before the client can connect. This host socket listens on the defined port for
an incoming connection from a client socket. The client socket can connect
to the host socket if it knows the IP address and port number the host socket
is listening on. Once connected, data transmission between the two sockets
can occur. In the case of using SSL with a socket connection, an extra step
of authentication must occur. This procedure is covered later in the chapter.
The following subsections look at the processes gone through in this
project to create a working, insecure, socket connection over the Internet.
4.1.1 Socket Connection Over LAN
Initially a socket connection over a LAN without the SSL was created. This
was done to test that the socket code actually worked and was programmed
correctly to establish a connection between a host and a client socket and
allow data transmission. The sockets were programmed so as to connect to
another machine running on the same network. Figure 4.2 illustrates the
architecture of this connection.
It should be noted that Microsoft’s Developer’s Network (MSDN) was
accessed and utilized in the creation of the code for the insecure and secure
socket creation and testing /citepmicrosoft.
The code for a client socket to send a message is listed below:
szData = "Test message to send";
byData = System.Text.Encoding.ASCII.GetBytes(szData);
clientSocket.Send(byData);
The code for a host socket to receive data is listed below:
CSocketPacket theSockId = (CSocketPacket)asyn.AsyncState;
int iRx = 0; //initialise read bytes counter
iRx = theSockId.thisSocket.EndReceive(asyn); //no of recieved bytes
char[] chars = new char[iRx]; //create initial character array
37
Figure 4.2: Sockets Over LAN Architecture
38
Figure 4.3: Screenshot - LAN Socket Transmission
System.Text.Decoder d = System.Text.Encoding.UTF8.GetDecoder(); //decode text
int charLen = d.GetChars(theSockId.dataBuffer, 0, iRx, chars, 0);
System.String szData = new System.String(chars); //put data into string
The testing of a socket connection without SSL over a LAN was successful.
The applications were able to share information across the connection. Figure
4.3 illustrates this successful connection as a screenshot.
Upon connection to a host socket, the first thing the client socket inside
Neocot Diagnostics application sends is the string inside the text box, in this
case ”MNTE-123-456”. The MNTE Server application receives data over
the socket connection and displays what it receives inside its large text box.
It can be seen that the connection is successfully established because the
”MNTE-123-456” string is showing up inside the MNTE Server application.
4.1.2 Socket Connection Over Internet
To allow for a socket connection, without SSL, over the Internet the client
must know where to connect to. It requires the listening socket’s port number
39
Figure 4.4: Sockets Over Internet Architecture
and instead of an IP address, requires a domain name. The Internet assigns a
dynamic IP address everytime a machine connects to it. A domain name can
be used to reference this IP dynamic IP address no matter how many times
it changes. This allows a client to connect to a host without knowing its
dynamic IP address, as long as it knows its domain name. The domain name
service (DNS) for this project was created from the website www.dyndns.com.
[Dynamic Network Services Inc., current September 2009].
The architecture for a socket connection, without SSL, is displayed in
Figure 4.4
The red line in Figure 4.4 shows where the connection needs to go to
achieve successful transmission. The way to achieve this is to enable and
specify port forwarding in the internal router. The host is only listening on
its network IP address, 192.168.0.101. With port forwarding enabled the
router can forward any outgoing connections on specific ports from this local
network IP onto the modem IP, 123.211.134.183. With this configuration, a
computer behind a router will still host a listening socket that can be found
by a client using its domain name.
The testing of a socket connection without SSL over the Internet was
successful. The applications were able to share information across the con-
nection. Figure 4.5 illustrates this successful connection as a screenshot.
40
Figure 4.5: Screenshot - Internet Socket Transmission
41
The test used is exactly the same as the LAN data transmission test
in the previous section. The Neocot Diagnostics client application asks for
a Neocot serial number, in the case of Figure 4.5, it is ”MNTE-999-000”.
The MNTE Server application has established a connection with Neocot
Diagnostics, received this string of data from it and is diaplying it.
4.2 Sockets With SSL
As previously stated, and as can be seen from the previous two subsections,
sockets are an easy way to implement data transmission over a LAN or the
Internet. The socket connections illustrated above though, do not incor-
porate any security for the data that they are transmitting. This can be
dangerous when transmission is occurring over an unsafe connection such as
the Internet. For reasons stated earlier in Chapter 2 of this report, a layer
of security must be implemented on the socket connection in this project.
This layer of security is achieved with SSL. SSL allows the connecting
client socket to authenticate the server before any data is allowed to be trans-
mitted. As with insecure sockets, the host socket is run first and listens for
incoming connections. A client socket with the host socket’s details connects
to the host socket and straight away asks for the server’s certificate details.
A certificate is an electronic certificate stored on the host machine that con-
firms that host’s identity. It also has to be signed by a trusted certificate
authority to allow for commercial use.
If a client receives a certificate from the host that states it is someone
different than who the client thought it was connecting to than there is
a problem and the client disconnects. The certificate could be stolen or
being used unlawfully. If the certificate is not signed by a trusted certificate
authority the client also disconnects. Certificates are able to be made by
almost anyone, but only reputable certificates are signed by trusted certificate
authorities.
Appendix G of this report details the process used to create the self-signed
certificate used by this project.
The following subsections look at the processes gone through in this
project to create a working SSL socket connection over the Internet.
4.2.1 SSL Socket Connection Over LAN
The code to allow socket’s using SSL to connect differs from insecure socket
code. The sslStream class was used. This class allows for the creation of a
host TCP socket and a client TCP socket and also an underlying data stream
42
between these sockets. Authentication is also required before transmission
of data can occur.
Initially a socket connection over a LAN with SSL was created. This
was done to test that the socket code actually worked and was programmed
correctly to establish a connection between a host and a client socket and
allow data transmission. The sockets were programmed so as to connect to
another machine running on the same network. Figure 4.2 illustrates the
architecture of this connection.
The code for a client socket to send a message is listed below.
byte[] message = Encoding.UTF8.GetBytes("(Using SSL) Log Filename:\r\n"
+ textBox6.Text);//Send message to the server.
sslStream.Write(message);
sslStream.Flush();
The code for a host socket to receive this data is listed below:
// Read the client’s test message.
bytes = sslStream.Read(buffer, 0, buffer.Length);
// Use Decoder class to convert from bytes to UTF8
// in case a character spans two buffers.
Decoder decoder = Encoding.UTF8.GetDecoder();
char[] chars = new char[decoder.GetCharCount(buffer, 0, bytes)];
decoder.GetChars(buffer, 0, bytes, chars, 0);
messageData.Append(chars);
The testing of a socket connection with SSL over a LAN was successful.
The applications were able to authenticate each other using a self-signed
certificate. Information was then able to be shared across the connection.
Figure 4.6 illustrates this successful connection as a screenshot.
In Figure 4.6 is can be seen that the input into the Neocot Diagnos-
tics client application is ”MNTE-SSL-TEST”. After authentication occurs
this message can be sent to the MNTE Server application. Authentication
and transmission has been successful as the ”MNTE-SSL-TEST” is being
displayed in the MNTE Server application.
43
Figure 4.6: Screenshot - LAN SSL Socket Transmission
44
4.2.2 SSL Socket Connection Over Internet
The same principles to allow transmission of data through insecure sockets
over the Internet apply to secure sockets. To allow for transmission between
sockets using SSL over the Internet a domain name must be used by the
client socket to identify the host socket. The domain name used to allow
for secure socket connection over the Internet is identical to the one used to
allow for insecure socket connection over the Internet discussed earlier in this
chapter.
Also, port forwarding must be enabled on the router that the host con-
nects to the Internet through. This allows the host to listen on the IP address
of the domain instead of its network IP address. The architecture of this con-
nection is identical to the architecture of the insecure socket connection over
the Internet shown in Figure 4.4.
The testing of a socket connection with SSL over the Internet was success-
ful. The applications were able to authenticate each other using a self-signed
certificate. Information was then able to be shared across the connection.
4.3 Chapter Summary
This chapter detailed the process taken to achieve successful data transmis-
sion between a client and a host socket. Data transmission over a LAN using
sockets without SSL was successful. Data transmission over the Internet us-
ing sockets without SSL was also successful. Both of these procedures were
documented and illustrated. Code snippets displaying the procedures used
for transmitting and receiving data were included as well.
The sslStream class was used in the code to create sockets with Secure
Sockets Layer (SSL) implemented. These sockets were tested over a LAN
and the Internet with data transmission being successful in both cases af-
ter successful authentication. These procedures were both documented and
illustrated in this chapter. Again code snippets displaying the procedures
used for transmitting and receiving data were also included.
45
Chapter 5
Software Design
This chapter details the breakdown of the two software applications devel-
oped for this project and the testing of seperate code sections. The first
application is the hospital client application and the second is the MNTE
server application.
It should be noted that these tests are only set to be run on a single
machine, internal at MNTE. This testing allows for software module testing
without requiring configuration of external hardware such as routers. These
tests will test the software modules only and prove whether they are accept-
able. The final end-to-end testing will require a hospital connection simu-
lation, where the modules are installed on separate computers and external
hardware will be configured to allow a connection.
A graphical overview of the objectives of this project was given in Chap-
ter 1, Figure 1.4 of this report. The objectives for this Chapter have been
taken from this this Figure and are shown alone in Figure 5.1. Figure 5.1
depicts the a host computer running the ’MNTE Server’ application and a
client computer running the ’Neocot Diagnostics’ application present in Fig-
ure 1.4. This chapter concentrates on the creation of these two applications
and breakdown and testing of them.
Each application is detailed in following sections, with each code section
and its tests detailed in subsections.
It should also be noted that Microsoft’s Software Development Network
(MSDN) was a source for parts of the code in each of the applications. [Mi-
crosoft, current September 2009].
46
Figure 5.1: Chapter 5 Graphical Objective
47
5.1 Neocot Diagnostics (Hospital Client Ap-
plication)
For the hospital client application an existing software application has been
extended. The previous version of the Neocot Diagnostics application was
designed to capture incoming Bluetooth information from a Neocot, log the
information and then email this log to the MNTE office. A flowchart of the
original program is illustrated in Figure 5.2.
The program begins with the user set-up stage. The user has to connect
the Bluetooth dongle to the computer, connect the Neocot Bluetooth Diag-
nostics Module (NBDM) to the Neocot and power on the Neocot. Initially
the program creates a server socket, it then calls the Bluetooth client on its
first run. This involves running the Bluetooth Application.
The Bluetooth application checks the WinSock interface. It then creates
a connection to the host, checks the Bluetooth radio and searches for radio
devices. Because the NBDM is connected to the powered on Neocot it finds
this device. After authentication a connection from the computer to the
Neocot is established. The program then loops inside itself, receiving and
sending diagnostics data. This application then closes when the Control
application closes.
After the Bluetooth Client is called in the first run of the Control appli-
cation it begins to recursively receive diagnostics data from the Bluetooth
application. It then writes this data to file and also sorts it into Header
Data, Error Data and Body Data, performing different actions for each type
of data being received. After the procedure is stopped by the user the log
file is then emailed to the MNTE Office.
This application has been extended and the flowchart used for the ex-
tended application used in this project is shown in Figure 5.3.
The emailing step at the end of the application has been replaced with
real-time data transmission. The information is still logged, sorted and dis-
played in this application. Further, a socket has been set up to connect to
the MNTE server application over the Internet.
The Neocot Diagnostics code is and summarized in code sections below:
1. Create TCP socket, connect to and authenticate MNTE server socket
2. Transmit data securely over the internet using SSL
These code sections are detailed and tested in the following subsections.
48
Figure 5.2: Original Neocot Diagnostics Flowchart
49
Figure 5.3: New Neocot Diagnostic Flowchart
50
5.1.1 TCP Socket Connection and Authentication
This code section creates a TCP client socket and attempts to connect to a
server socket and authenticate it using the certificate the server provides.
In the case of the end-to-end test the IP address used will be that of Neil
Mansell Transport’s domain name, mansell.com.au. The domain name can
be resolved to an IP address by the TCP creation function. This resolved IP
address will be that of the Neil Mansell Transport router. This router will
then be programmed to forward the connection request to the appropriate
MNTE computer.
For the internal test the IP address used was that of the computer the ap-
plication was running on, which depending on the computer, was 192.168.0.100.
This only tested the software connection on a Local Area Network basis but
that is all that was required to test if the software module was acceptable.
The Internet-traversing test using the end-to-end parameters outlined above
will be performed in the end-to-end test further on in this report.
Authentication is then achieved by using built in functions in the sslStream
class. These functions are covered in more detail in Chapter 4 of this report.
In the case of the end-to-end test, the certificate to be used will be one
created by mansell.com.au and signed by a trusted certificate authority. In
the case of the internal test, a self-signed certificate was used. This allowed
for software testing without having obtained a trusted certificate yet.
Test: Create a new TCP socket and attempt to connect over port 443 to
a test TCP listening socket which is set up on the same computer listening
on port 443 and authenticate using a self signed certificate.
Pass: The TCP socket was created successfully and connected to the
test, listening, TCP socket. It also authenticated the server successfully by
checking the self-signed certificate against the server name and signature.
5.1.2 Secure Data Transmission With SSL
This code section uses the connection setup in the previous module and at-
tempts to send data over the established connection. An sslStream class
function in the client application writes bytes to be transmitted from the
socket and another sslStream class function in the server application reads
in bytes received by the socket.
Test: Send a test message generated by the client application over the
socket connection and have the test listening application read the message
and display it.
51
Pass: The test listening application displayed the test message sent by
the client application.
5.2 MNTE Server
The MNTE server application was not based on any existing software but
developed entirely independently. Some functions used in the Neocot Diag-
nostic application were reused by the MNTE Server application.
This application is designed to accept incoming connections from the Neo-
cot Diagnostic application, covered in the previous section, which is installed
on hospital computers that are locally connected to a Neocot. This appli-
cation then receives information sent over TCP sockets, implementing SSL
security in real-time. This information is then displayed to the user at the
MNTE office in a useful and meaningful manner. The information is also
logged in a file and saved on the MNTE server.
A flowchart of the MNTE Server application is shown in Figure 5.4.
The program begins by creating a host socket and listening for incoming
connections. Once a client attempts to make a connection, the server au-
thenticates itself and once authenticated the connection between server and
client is established. The client then sends recursive diagnostic data over the
socket connection and the server application receives it. It then writes this
data to a text file, displays the received data in a text box and also sorts the
information it is receiving.
It sorts the information into Header Data, Error Data and Body Data,
depending on what the data is the application updates the Virtual Terminal
Board accordingly. Once the socket connection is closed the application ends.
The code sections are summarised below:
1. Create a TCP, listening socket and wait for an incoming connection.
2. Upon a connection request from client, send certificate information for
authentication.
3. Receive information from client in real-time
4. Display received information to user in meaningful manner
5. Log information and save into text file
These code sections are detailed and tested in the following subsections.
52
Figure 5.4: MNTE Server Flowchart
53
5.2.1 TCP Socket Creation
This code section creates a TCP listening socket and allows for incoming
connections from client sockets that specify the machine’s IP address and
port number the socket is listening on.
The use of sockets and port 443 is explained in the previous section of
this report. The IP address that this socket uses is simply the IP address of
the machine the application is running on. In every test case it will depend
on the machine being used, it will most likely be 192.168.0.100.
Test: Create a new TCP, listening socket and listen for incoming con-
nections.
Pass: The TCP, listening socket was created successfully and waited
until specified because no incoming connections were made.
5.2.2 Allow Client to Authenticate
This code section uses an existing socket established from the module covered
in the previous subsection. It also implements sslStream class functions.
On the request of an incoming connection of a client to the listening
socket on the server, the information of the server’s certificate is sent to the
client. The client then authenticates this certificate against the server name
and checks if the certificate is signed by a trusted certificate authority. Once
authenticated, the client and server will be able to transmit data.
In the case of the end-to-end test, the certificate to be used will be one
created by mansell.com.au and signed by a trusted certificate authority. In
the case of the internal test, a self-signed certificate was used.
Test: Connect a test TCP client socket to an existing TCP listening
socket and allow the test client to authenticate the server.
Pass: The server’s certificate details are sent successfully and the test
client authenticates the server.
5.2.3 Receive Real-Time Data With SSL
This code section uses the connection setup in the previous module and
receives data that is being sent by the client over the established connec-
tion. An sslStream class function in the client application writes bytes to
be transmitted from the socket and another sslStream class function in the
server application reads in bytes received by the socket.
54
Test: Send a test message generated by a test client application over the
socket connection and have the listening application read the message and
display it.
Pass: The listening application displayed the test message sent by the
test client application.
5.2.4 Display Data
This code section interprets and displays data that is received from a client
in a meaningful way to the user.
The data from a Neocot is sent as a line of text and contains data that,
when interpreted, can show what is being displayed on the Neocot terminal
board. This is the board on the top of a Neocot which displays vital infor-
mation such as temperature and any alarms. This subject is covered in the
next chapter.
The line of data a Neocot sends can have three different formats: Header
data: This is data sent when the Neocot is first turned on and sends in-
formation such as previous errors and Neocot software build. Body data:
This is data sent when the Neocot is in normal operation and is data that
is used by the terminal board to display temperate and alarm lights. Error
data: This is data sent when the Neocot has an error. Normal operation of
the Neocot stops, the error data is sent and then the connection is closed,
stopping logging on both ends.
Test: Send one test line of data from each of the three categories listed
above, equivalent to a line of data an actual Neocot would transmit, from the
test client socket across an established SSL connection to the server socket.
Pass: In all three cases, the line of data is successfully interpreted as to
what category it belongs. Header information is read correctly and displayed
where applicable. Body data is to the user on a virtual terminal board the
same as it would be on a Neocot’s terminal board if that Neocot had trans-
mitted the line of data. Error data is transmitted and interpreted successfully
and is also displayed on the virtual terminal board the same as it would be
on a Neocot’s terminal board if that Neocot had generated the same error.
The connection is then closed.
5.2.5 Log Data
This code section logs the data that the server receives from the client by
writing every line it receives into a text file and saving the text file onto the
server machine. This module uses the stream writer class functions.
55
A text file is created using the Neocot serial number input by the user
at the beginning of the Neocot Diagnostic application. This serial number
is then sent across the socket connection and used, along with the date and
time, to create the file’s filename. The file is saved to a folder ’Logs2’ that is
in the same directory as the MNTE Server program.
Test: Send test data equivalent to the previous test, from the test client
socket across an established SSL connection to the server socket.
Pass: The information sent across the connection from the test client to
the server is replicated in the .txt file saved in the ’Logs2’ folder on the server
machine.
5.3 Chapter Summary
This Chapter documented the developmental process of the software involved
in this project. The applications developed were ’Neocot Diagnostics’ and
’MNTE Server’.
Neocot Diagnostics was broken down into code sections that perform
certain actions. These group of actions were each tested. The test and
results for each code section was discussed. Neocot Diagnostics is a client
program that is run on a computer in a hospital housing a Neocot. The
software allowing with Bluetooth hardware allows a connection between a
local Neocot and a local computer and facilitates the data transfer from the
Neocot to the local PC. Here the data is logged and also transmitted across
the Internet to a computer at the MNTE Office running the ’MNTE Server’
application.
The MNTE Server application was also broken down into code sections
that perform certain actions. These group of actions were each tested. The
test results for each code section of this application are also discusses. MNTE
Server is the host program that listens for incoming connections from any
remote Neocot Diagnostics applications. Once a client connects and starts
transmitting data, the MNTE Server application receives this data and dis-
plays it to the user in textual form. On top of the textual format the data is
also interpretted and displayed on a Virtual Terminal Board in the program,
allowing the user to see a recreation of the remote Neocot’s Terminal Board
in real-time.
56
Chapter 6
Final Troubleshooting and
Testing
The software applications detailed in the previous two sections were devel-
oped individually and only tested using test methods. A final end-to-end
test was undertaken to test these two applications compatibility with each
other as well as the transmission of actual streaming, Neocot diagnostic data.
The ideal end-to-end test for the software modules was for the client appli-
cation to be installed on a remote hospital computer. This computer needs
to be nearby a Bluetooth-enabled Neocot allowing for a connection between
the Neocot and the computer. The host application is installed on a host
computer at the MNTE Office and opens a listening socket over the Internet
allowing for the client application to find it, authenticate it and connect. This
creates a secure, real-time connection from a remote Neocot to the MNTE
Office.
This connection will be the actual connection established when the soft-
ware is in commercial use, making it the ideal test. The connection is illus-
trated in Figure 6.1.
No testing of software can occur without problems being encountered.
The following chapter details the problems encountered and the troubleshoot-
ing involved in the final testing stage. Problems encountered with hardware
are discussed in the first section. The second section looks at the problems
encountered with the software and then a final test of the software, after all
problems have been addressed, is illustrated.
57
Figure 6.1: Ideal End-to-End Test Connection
6.1 Hardware Problems Encountered
This section looks at the problems encountered with the hardware involved
when the final test was undertaken. For a successful end-to-end test to occur
using the configuration shown in Figure 6.1, a Bluetooth-enabled Neocot is
required to be in service. A Neocot Bluetooth module, (Neoblue), must also
be accessible and plugged into the Bluetooth enabled Neocot. At this stage
there are multiple Bluetooth enabled Neocot’s in service around the world.
The Neoblue module is yet to be finalized and not yet commercially available.
This matter is beyond the scope of this project and therefore created a ma-
jor problem in the end-to-end testing process. The only Bluetooth enabled
Neocot with access to a Neoblue is at the MNTE Office where all testing
requiring a Bluetooth connection has been conducted.
The remote Neocot that, in the ideal test, resides in a hospital, is required
to be a Bluetooth enabled Neocot in the MNTE Office. This being the
case, the host could no longer reside in the same domain as the client if
transmission over the Internet was to be tested. Therefore the host station
was moved to a 3rd party’s premises.
The change to the host and client hardware configuration explained above
created problems with the corresponding host and client software applica-
tions. These problems are looked at in the next section.
58
6.2 Software Problems Encountered
This section looks at the problems encountered with the software involved
when the final test was undertaken. The problems created by the change
to the ideal host and client hardware configuration are looked at first. The
following section then discusses problems with the software, independent of
hardware.
6.2.1 Hardware Dependent Problems
This section details the problems encountered with the software involved
with end-to-end testing that are related to the required change in hardware
configuration detailed in Section 6.1 of this report.
Due to the fact that the Neoblue is not commercially available yet the
client application is yet to be tested on a hospital computer. Also the Neocot
Diagnostics client application is hardcoded to search for a socket being hosted
at the 3rd party’s premises instead of at the MNTE Office. The code for this
is shown below. In the case of hosting a socket on an MNTE computer, this
code would have to be changed to search for that socket instead.
string machineName = "mattkinast.homeip.net";
string serverCertificateName = "mattkinast.homeip.net";
RunClient(machineName, serverCertificateName);
Where RunClient’s first few lines are:
public void RunClient(string machineName, string serverName)
{
// Create a TCP/IP client socket.
// machineName is the host running the server application.
client = new TcpClient(machineName, 443);
// Create an SSL stream that will close the client’s stream.
sslStream = new SslStream(
client.GetStream(), false,
new RemoteCertificateValidationCallback(ValidateServerCertificate),
null);
// The server name must match the name on the server certificate.
try
{
sslStream.AuthenticateAsClient(serverName);
}
59
This temporarily solved the problem of a MNTE acquiring a certificate to
provide to connecting client’s to authenticate. Because there are, as of yet,
no clients to connect to a server being run at mansell.com.au a certificate
is not yet required. The server is being run on a 3rd party household com-
puter which is providing a self-signed certificate created using the methods
described in Section 4.2.1 of this report. This certificate’s name is mattki-
nast.homeip.net. The IP address linked to this domain is 123.211.134.183 as
detailed in Section 4.1.2 of this report.
The code that opens the host socket in the server application is shown
below. This code could be used on any host machine, unchanged, so long as
there is a certificate file named ’ca.cer’ which allows for authentication. In
the case of the ideal test, this certificate file would be named mansell.com.au
instead of mattkinast.homeip.net and also be signed by a trusted certificate
authority instead of a self-signed certificate.
//Start listening socket
Thread thread = new Thread(new ThreadStart(RunServer));
thread.Start();
Where RunServer’s first few lines are:
public void RunServer()
{
string certificate = "ca.cer";
serverCertificate = X509Certificate.CreateFromCertFile(certificate);
// Establish the local endpoint for the socket.
// The DNS name of the computer
// running the listener is "kinast.homeip.net".
IPHostEntry ipHostInfo = Dns.Resolve(Dns.GetHostName());
IPAddress ipAddress = ipHostInfo.AddressList[0];
For this code to work in the ideal test, the MNTE router would also need
to be correctly configured as described in Section 4.1.2 of this report. It would
need to enable port forwarding from the computer running the MNTE Server
application to the IP address of the Mansell IP address that mansell.com.au
is bound to and can be resolved to.
In summary, due to the unavailability of Neoblue modules to the public
the hardware configuration used in testing is illustrated in Figure 6.2. The
server application, MNTE Server, is now being run at a 3rd party’s premises
and using a self-signed certificate with the name, mattkinast.homeip.net for
60
Figure 6.2: End-to-End Test Connection With SSL
authentication. The router this computer is connected to is configured to
forward connections opened on port 443 through to the modem which has the
IP address that mattkinast.homeip.net is resolved to. The client application,
being run on an MNTE machine, connected via Bluetooth to a Neocot, is
hardcoded to resolve the IP address of the mattkinast.homeip.net domain
name and connect to the host socket on this address at port 443.
6.2.2 Hardware Independent Problems
The difference between a regular TCP socket connection and an SSL TCP
socket connection is explained in depth in chapter 4 of this report. In short
they are very similar, they both consist of a TCP socket while the SSL version
has an added layer of security and also an underlying stream that data is
written to and read from as opposed to being sent straight out of the socket
like the regular TCP socket connection. An SSL test host and test client
application were developed for testing purposes and transmission of a test
message between them was successful over a LAN and the Internet. The code
listing for the host application is in Appendix B and the client application
code listing is in Appendix C.
These applications open a host and client socket and connect to each
other. They go through authentication procedures that SSL provides and
once they authenticate each other, data can be transmitted between the
61
sockets by reading and writing to and from the sslStream. The read and
write functions are shown below.
//Write to stream
sslStream.Write(message);
//Read from stream and store in bytes
bytes = sslStream.Read(buffer, 0, buffer.Length);
These test applications only open the connection long enough to write the
message or read the message from the stream and then close the connection.
This was enough for testing purposes but the Neocot Diagnostics and MNTE
Server applications need to keep their socket connections open indefinitely
as the client application streams data across to the host application for an
unknown amount of time. To allow for this the following lines of code were
removed from each application to allow the socket connection to remain open.
sslStream.Close();
client.Close();
Without these lines of code present, the applications do not function cor-
rectly. The sslStream.Read function times out, because there is nothing on
the stream to read. The sslStream.Write function is actually only writing
to the buffer and not writing the buffer to the stream. The buffer needs to
be filled to 1000 characters before it writes to the stream. The test applica-
tions only appeared to work but really the same thing was happening when
they were run. It was only when the sslStream.Close() and client.Close()
functions were called that the data was actually flushed from the buffer and
written to the stream. Because the programs executed in a matter of mi-
croseconds, there was no chance of the read or write functions timing out
and the applications appeared to be working.
This created a problem for the proper execution of the Neocot Diagnostics
and MNTE Server applications. Data needed to be transferred from the
client to the server in real time no matter what size it was. If the Neocot
Diagnostics application were to wait until over 1000 characters had been
written to the buffer before sending data then it would no longer be real-time
data transmission, this was not an option. Data had to be streamed across
from the Neocot Diagnostics application to the MNTE Server application as
soon as it was received from the Neocot via Bluetooth.
Different functions of an sslStream class object and a TcpClient class
object were inspected and tested in the code as follows.
62
1. Void sslStream.Flush() - Causes any buffered data to be written to the
underlying device. This function was thought to be the answer to the
problem but program execution remained unchanged when present in
the code.
2. client.NoDelay() - Gets or sets a value that disables a delay when send
or receive buffers are not true. When set to true this was thought to be
the answer to the problem again but still, program execution remained
unchanged when present in the code.
3. client.ReceiveTimeout() -
Gets or sets the amount of time a System.Net.Sockets.TcpClient will
wait to receive data once a read operation is initialized. This receive
timeout value was changed in the host code from 5000 milliseconds to
10000 milliseconds to test whether data would be sent from the client
after a longer period of time but again program execution remained
unchanged when the 10000 millisecond value was present in the code.
4. sslStream.WriteTimeout() - Gets or sets the amount of time a write
operation blocks waiting for data. This write timeout value was also
changed from 5000 milliseconds to 10000 milliseconds but in the client
code. Again no change in program execution occurred.
It was established there was a bug with the code and it was decided
to proceed using regular TCP sockets without any layer of security. Major
work was completed on the successful transmission of diagnostic data through
sockets using SSL yet the bug encountered prevented the final product from
being reached. Given more time this issue could be resolved and sockets using
SSL could replce the regular sockets used in the current version of code.
Security must be a feature in any commercial program and before this
program can be distributed commercially it must encorporate SSL on its
socket connections. Once the encountered bug is resolved work can progress
and security will be acheived. The work completed on SSL within this project
can still be used towards acheiving this.
Without implementing SSL the end-to-end testing configuration to now
be used is shown in Figure 6.3
6.3 End-to-End Testing
This section details an end-to-end test of the Neocot Diagnostics client soft-
ware and the MNTE Server software together using the configuration illus-
trated in Figure 6.3. It contains screenshots of the different stages of both
63
Figure 6.3: End-to-End Test Connection Without SSL
applications, from establishing connections to sending Neocot data and clos-
ing the connections again.
6.3.1 Establishing Connections
This section illustrates the connections being established from the server
computer to the client computer as well as the client computer connecting
to the Neocot.
Figure 6.4 shows the MNTE Server application being initialized on the 3rd
party computer while Figure 6.5 shows the Neocot Diagnostics application
being initialized on the Mansell computer.
In Figure 6.4 is can be seen that there is only one button for the user
to press, ’Start Listening’. This initializes an opening of a socket on the
computer and beings listening for any incoming connections from client ap-
plications. Figure 6.6 shows what screen is seen after this ’Start Listening’
button is pressed.
In Figure 6.5 it can be seen that the client application prompts the user for
the serial number of the Neocot that is to be connected to the computer. Once
this is input the ”Continue” button is pressed. The client application then
creates a socket that searches for the socket opened in the host application
and attempts to connect the two sockets. If the application cannot find
a host socket Figures 6.7 and 6.8 display what is seen by the user. They
64
Figure 6.4: MNTE Server - Start
Figure 6.5: Neocot Diagnostics - Start
65
Figure 6.6: MNTE Server - Listening
are prompted to contact the MNTE Office because a connection cannot be
established. After seeing the screens in Figures 6.7 and 6.8 they are returned
to the initial screen shown in Figure 6.5.
If the application is successful in finding a host socket and connecting to
it then a connection is established and the user sees the screen illustrated in
Figure 6.9.
Figure 6.6 shows the MNTE Server application listening for incoming
connections from clients. Once a client successfully connects, it sends the
string ”Log Filename: xxx”, where xxx is the Neocot serial number input by
the user in the text box at the start of the Neocot Diagnostic application.
Figure 6.10 shows the MNTE Server application receiving an incoming con-
nection from the Neocot Diagnostic application in which the user specified
the Neocot serial number as ’internet COT’. The connection between the
two applications is now established and data can be sent between the two
applications.
In Figure 6.9, the user is prompted to connect a Bluetooth dongle to the
client computer, ensure Neocot power is turned off but still supplied and
connect the Bluetooth dongle to the Neocot. Once these steps have been
completed and they press the ’Proceed button’ the application then attempts
to establish a connection between the client computer and the Neocot over
Bluetooth. The connection information is displayed in the client application
as well as being passed over the Internet to the MNTE Server application
66
Figure 6.7: Neocot Diagnostics - No Connection Established 1
Figure 6.8: Neocot Diagnostics - No Connection Established 2
67
Figure 6.9: Neocot Diagnostics - Connect Bluetooth
Figure 6.10: MNTE Server - Connected
68
Figure 6.11: Neocot Diagnostics - Bluetooth Connected
through the established socket connection. Figures 6.11 shows the Neocot
Diagnostics client application establishing the Bluetooth connection and dis-
playing the data. Figure 6.12 shows the MNTE Server application receiving
the same data and also displaying it.
In Figure 6.11 it can be seen that once a Bluetooth connection from
the client computer to the Neocot is established the Neocot Diagnostics ap-
plication prompts the user to power on the Neocot. This will begin the
transmission of Neocot diagnostic information being sent from the Neocot to
the client computer over Bluetooth and then passed on to the MNTE Server
application through a socket connection over the Internet. This transmission
is covered in the next section.
6.3.2 Sending Data
This section details the sending of Neocot diagnostic data between the Neocot
Diagnostics and MNTE Server applications over the Internet.
The screenshots in the previous section illustrated the connection being
established between these two applications as well between the client com-
puter and the Neocot. Once the user turns the Neocot on, after the screen
shown in Figure 6.11, then the Neocot starts transmitting data. Header data
is sent initially, which is received by the client application, shown in Figure
6.13. The same header data is passed onto the MNTE Server application
69
Figure 6.12: MNTE Server - Displaying Bluetooth Data
over the Internet socket connection. The MNTE Server application receiving
this data is shown in Figure 6.14.
After approximately six seconds of header data the Neocot starts trans-
mitting body data. This data is sent out every two seconds and contains
information on how the Neocot is running at that point in time. An example
of one of these transmissions is shown below.
0010, CDHMRAB12S, 23.8,21.8, 24.0,21.7, 1985,21.5,21.3,21.8,
21.8, 3927, 0000, 0000, 0000, 57, 59, 0165 #GcfGhGaGpb
#O#2424#GcfGhGaGpb #GcfGhGaGpb #O#2424
The Neocot Diagnostic application receiving this data from the Neocot
and transmitting it to the MNTE Server application is illustrated in Figure
6.15. The MNTE Server application receiving this data, interpreting it and
updating the Virtual Terminal Board is illustrated in Figure 6.16.
A picture of the Neocot taken at the same time this body data was being
transmitted and received is shown in Figure 6.17. As you can see the Virtual
Terminal Board reflects exactly what is being displayed on the actual Neocot
Terminal Board.
When a Neocot errors, it sends out error data and then stops transmitting
data. An example of an error occurring in a Neocot is shown below. This
error was generated by stopping the internal fan causing the fan torque to
70
Figure 6.13: Neocot Diagnostics - Transmitting Header Data
Figure 6.14: MNTE Server - Receiving Header Data
71
Figure 6.15: Neocot Diagnostics - Transmitting Body Data
Figure 6.16: MNTE Server - Receiving Body Data
72
Figure 6.17: Neocot at 24.3 Degrees
go too high and the Neocot to error. A screenshot of the Neocot Diagnostics
application receiving this error data and displaying it is shown in Figure 6.18.
The error data is passed on to the MNTE Server application which again
displays it, interprets it and updates the Virtual Terminal Board accordingly.
A screenshot of this is shown in Figure 6.19.
A picture of the Neocot taken at the same time this error data was being
transmitted and received is shown in Figure 6.20. As you can see the Virtual
Terminal Board reflects exactly what is being displayed on the actual Neocot
Terminal Board.
When data transmission is complete, or such an error as above occurs
than data transmission is ended and the connection must be closed. This is
covered in the next section.
6.3.3 Closing Connections
It can be seen in screen shots of the Neocot Diagnostic application such as
Figure 6.18 that there is a ’Finish’ button at the bottom of the application
window. This allows the user to finish the logging and data transmission
procedure for whatever reason, be it a Neocot error has occurred, the recom-
mended time of 1 hour has passed or they simply wish to stop the procedure.
Once this ’Finish’ button is pressed the screen shown in Figure 6.21 is seen
by the user.
73
Figure 6.18: Neocot Diagnostics - Transmitting Error Data
Figure 6.19: MNTE Server - Receiving Error Data
74
Figure 6.20: Neocot With Error 0.9
Figure 6.21: Neocot Diagnostics - End Procedure
75
Figure 6.22: Neocot Diagnostics - Closed Connection 1
If the ’No’ button is pressed, it simply goes back to the previous screen
but if the ’Yes’ button is pressed the sockets and connection is closed. The
screen shown in Figure 6.22 is seen at the client end in the Neocot Diagnostics
application and the screen in Figure 6.23 is seen at the host end in the MNTE
Server application.
When the ’OK’ button in the Neocot Diagnostics application screen
shown in Figure 6.22 is pressed, the message box disappears and the screen
is then as it appears in Figure 6.23. The ’Close Application’ button can then
be pressed by the user closing the application.
Figure 6.24 shows the MNTE Server application after the connection
is closed. It informs the user that the procedure has been ended by the
client. The button ’Finish and Return to Start’ then returns the user to the
beginning of the application allowing them to open another socket connection
to listen for more incoming connection. This is the initial screen shown in
Figure 6.5. In the screen shown in Figure 6.24 it also allows the user to
click ’View file’ to view the log file produced by the procedure. This logging
procedure is detailed in the next section.
6.3.4 Logging
This section details the logging procedure used in the Neocot Diagnostics
and MNTE Server applications.
76
Figure 6.23: Neocot Diagnostics - Closed Connection 2
Figure 6.24: MNTE Server - Closed Connection
77
Before being edited for this project, the Neocot Diagnostics application
logged the Neocot diagnostic data it received in a local text file. This was
emailed to the MNTE Office for diagnosis. Although the file is no longer
emailed, it is still logged and kept on the client machine for future reference.
An output of one of these log files is listed in Appendix F of this report.
The logging procedure used in the Neocot Diagnostics application was
also used in the MNTE Server application. It was integrated into the host
application and logs all the information that the host socket receives over
the Internet from the client socket in the Neocot Diagnostics application.
The log filename is created from a combination of the current day’s date and
time as well as the first line of data sent to the MNTE Server application
which is always the Neocot serial number that the user inputs in the Neocot
Diagnostics application before the connection is established. This log file
then records all the data the application receives and saves it on the local
system for future reference for MNTE staff. The contents of one of these
log files is similar to the Neocot Diagnostics log output which is listed in
Appendix F of this report.
6.4 Chapter Summary
This chapter detailed the issues encountered in the last stages of this project.
The major problem that forced changes to be made to the final testing stages
was the fact that the Bluetooth module for the Neocot had not yet been made
commercially available. This prevented an actual real-life situation test to
occur. An ideal transmission test involved transferring data from a Neocot
in a hospital via a computer in that hospital to the MNTE Office computer.
This had to be changed to the transmission of data from a Neocot at the
MNTE Office via a computer at MNTE office to a 3rd party’s premises. This
successfully tested the connection with posotive results, though an ideal test
still needs to take place.
The next major issue encountered and documented upon in this chapter
was the bug found in the sslStream code. Transmission of data from secure
sockets was found not to follow the same pattern as data transmission from
insecure sockets. Transmission between secure sockets over the Internet was
successful at a test level. When this code was integrated into the MNTE
Server and Neocot Diagnostics applications where the connection required to
remain open for an indefinite amount of time, transmission was unsuccessful.
Given these issues, testing circumstances changed. An end-to-end test
under new the new testing circumstances was conducted, documented and
illustrated in this chapter.
78
Chapter 7
Two-way Data Transmission
Hardware Investigation
This section briefly looks at the investigation into the hardware required
to allow for two-way data transmission between a Neocot and a computer
running the MNTE Server application at the MNTE Office. The reason for
two-way data transmission investigation is to allow for remote control of a
Neocot.
A graphical overview of the objectives of this project was given in Chapter
1, Figure 1.4 of this report. The objectives for this Chapter have been taken
from this this Figure and are shown alone in Figure 7.1. Figure 7.1 depicts
the blue line two-way data transmission between the Neocot and the remote
computer. This chapter concentrates on the investigation into the hardware
required to allow for this two-way data transmission. It should be noted that
the hardware allowing for data transmission in the direction of the blue line
shown in Figure 7.1 is not actually implemented, only investigated.
Data transmission from a Neocot to a remote computer has been estab-
lished, as shown in the previous chapter of this report. If data were to be sent
from a remote computer to a Neocot, it would not be the same type of data
that is travelling the other way but rather signals to control the functions of
the Neocot.
The Virtual Terminal Board in the MNTE Server application could be-
come interactive, allowing users to press the Virtual Terminal Board buttons
in the virtual environment. This would send signals across to the Neocot and
have that Neocot perform the function it normally would if the same button
on its actual Terminal board had been pressed by a local user.
79
Figure 7.1: Chapter 7 Graphical Objective
80
7.1 Remote Computer to Local Computer
This section concentrates on the two-way data transmission between the
remote server computer and the local computer that is connected to a Neocot
via Bluetooth.
The only hardware on this end of the connection is the Server computer
and the connection to the Internet. None of this requires changing to allow for
two-way data transmission. Any changes would need to be done in software
which is briefly covered in Section 7.3 of this report.
7.2 Local Computer to Neocot
This section concentrates on the two-way data transmission between a Neocot
and the local computer it is connected to via Bluetooth.
At this stage not all wires from the diagnostic port are connected through
to the Bluetooth module plugged into the Neocot, only the ones that are
required to transmit data. To allow for two-way transmission a receive line
would need to be added in to the connection from the Neocot to the Bluetooth
module. With this line present, any information sent from the local computer
over the Bluetooth would be read in by the Neocot Bluetooth module and
sent along to the Neocot on the receive line. Once this signal is inside the
Neocot it can be processed by the main board microprocessor.
There are 6 different buttons that can be pressed by the user on a Neocot
terminal board that communicate with the Neocot’s microprocessors. These
buttons are: Display Brightness, Power On, Power Off, Temperature Up,
Temperature Down and Alarm Silence. The Display Brightness button is
deemed unnecessary for remote control as it has no bearing on the Neocot’s
actual performance, leaving 5 buttons to be controlled remotely.
The Temperature Up, Temperature Down and Alarm Silence buttons can
all be simulated by the Neocot’s microprocessors and the existing hardware
without the actual button on the Neocot being pressed. Just as information
detailing the Neocot’s temperature and alarms is sent from the terminal
board processor to the main board processor and sent out over the diagnostic
port, it can be sent the other way into the terminal board processor and set
to the user’s desire. This can be done in the Neocot software, briefly covered
in Section 7.3 of this report.
The simulation of the Power On and Power Off buttons was investigated
and found to be more complex than that of the Alarm Silence and Temper-
ature control buttons. It was found that with the addition of an extra wire
from the main board microprocessor to the Neocot’s power circuit the power
81
could be controlled. If a low signal was sent along this line the system could
be held in an off state and as soon as the low signal was removed then power
would return to the Neocot. This essentially provides a Reset function of
the Neocot to the remote user and would allow the Power On and Power Off
buttons to be remotely simulated.
7.3 Software Assumptions
The last two sections have focused on the required hardware to allow for
two-way data transmission between a remote computer and a Neocot. The
hardware investigation is all that is specified in the Project Specification in
Appendix A of this report but the hardware configuration specified makes
assumptions about associated software if it is to work. This section extrap-
olates on those assumptions.
The MNTE Server application would need to incorporate code to allow
for sending of data over the established socket connection. At this stage this
application’s code only allows for data to be received.
The Neocot Diagnostics application would need to incorporate code to
allow it to receive data over the established socket connection. At this stage
the application’s code only allows for data to be transmitted.
The Neocot’s internal software would need to be able to handle the incom-
ing signals received by the Bluetooth module and sent into the diagnostics
port. It would need to be able to interpret these signals and determine what
to do with them. To allow for the simulation of the Alarm Silence and Tem-
perature control buttons it would need to be able to send diagnostic signals
back to the terminal board to change the status of the temperature and the
alarms. It would also need to be able to send a low signal to the power circuit
to allow for the simulation of the Power On and Power Off buttons.
7.4 Chapter Summary
This chapter discussed the required hardware to allow for two-way data trans-
mission between a remote Neocot and a host computer at the MNTE Office.
This two-way connection allows for the existing data stream from the remote
Neocot to the MNTE Office computer and also the MNTE Office computer
to send data back to the remote Neocot. This data would contian signals
that could control the Neocot’s basic function, essentially making it remote
controlable. The actual implementation of this hardware is not performed or
documented in this chapter, simply the theoretical requirements.
82
Hardware would only be required at the hospital end of the connection.
The Neocot Bluetooth module would require modification, as well as the
connection from the Bluetooth plug into the Naocot’s Main circuit board.
Extra wiring inside the Neocot would also be required.
This chapter also discussed the changes that would be required in the
software to allow for two-way data transmission.
83
Chapter 8
Risk Assessment
This chapter looks at the safety issues concerning the project covered in this
dissertation. It also looks at the safety issues concerning previous work. A
risk assesment is also detailed for each indentified risk.
8.1 Existing Safety Issues
Safety Issues pertaining to the Bluetooth transmission of data from the Neo-
cot to the connected hospital PC are detailed in Lane Steffensen’s report.
They are summarized in brief in this section.
• RSI to the user due to use of a mouse and keyboard to control com-
puter software. The likelihood of this was deemed very unlikely. The
exposure of this risk to the user was established to be occasionally and
the consequences are minor or major injury. [Steffensen, 2008]
• Bluetooth transmissions effecting other medical devices. The likeli-
hood of this was deemed to be slight. The exposure of this risk to the
user was established to be occasionally and the consequence is possible
death. Risk control implemented is the recommendation of five me-
tres seperation between the Neocot Bluetooth module and any medical
equipment. [Steffensen, 2008]
• Operation of the Neocot being disurbed by software. The likelihood of
this was deemed to be very unlikely. The exposure of this risk to the
user was established to be occasionally and the consequence is possible
death. Testing of the software in conjunction with the operation of the
Neocot established that no risk control was required to be implemented.
[Steffensen, 2008]
84
8.2 New Safety Issues
New safety issues have been created by this current project work and need to
be addressed along with the existing safety issues. These new safety issues
are summarized in this section.
8.2.1 Staff Safety
The main safety issue concerning staff, both of the hospitals and of Mansell
Neonatal is that of RSI (Repetitive strain injury) from use of the computer
which the software is installed upon. [RSI and Association, current May
2009]
Likelihood - Very Slight
Exposure - Occasionally
Consequences - Minor/major injury
Risk control: Because the very low likelihood of injury occurring from
this issue no risk control is deemed necessary.
8.2.2 Neonate Safety
The Neocot meets very high medical standards to be allowed to operate
and provides an extremely safe environment for a critically ill neonate. The
main identifiable situation where this safety would be compromised from
the consequences of this project is: If two-way data transmission was to be
implemented and a signal was sent from our office to a connected Neocot to
turn it off while it was in use then this could potentially mean the death of
the Neonate inside the Neocot.
Likelihood - Very Slight
Exposure - Very Rarely
Consequences - Possible Death
Risk Control: The following safety precaution will be implemented if two-
way data transmission hardware is implemented. The Neoblue Bluetooth
module will only be used with a Neocot for diagnostic purposes and while
the Neocot is not in use.
8.2.3 Data Interception
A main safety concern with streaming data over Bluetooth and over the in-
ternet is data interception. An unknown source could potentially intercept
the data being sent, change it and then forward it on. Although data inter-
ception is unlikely and one would have to question why such data is being
85
intercepted the situation must still be addressed. The Bluetooth connection
has security measures already in place. Close proximity to the network is re-
quired; also a password is required to gain access to it. Streaming data from
the hospital PC to the Mansell Neonatal PC over the Internet theoretically
allows anyone to access it and modify it.
Likelihood - Slight
Exposure - Rarely
Consequences - Incorrect error diagnosis. Possible death
Risk Control: A suitable data transmission technique must be imple-
mented to allow for this transmission to remain secure. Chapter 2 of this
report details the security, reliability and authentication of two different pro-
tocols that will allow the transmission of data over the internet. Chapter 4 of
this report explains a critical analysis that was undertaken on these options
to choose a suitable data transmission technique.
Safety, authentication and reliability were key features of this analysis and
played a vital role in choosing the most suitable option to transmit the data
over the internet. The chosen option needed to encompass safety measures
that minimize risk of outside sources accessing and modifying the data being
sent. It also needed to ensure that the client and server are authenticating
each other. This ensured that information was being sent to the correct
destination and was being received from the correct origin. The option also
needed to be the most reliable data transmission technique. Jumbled, frag-
mented or lost data needed to be minimized as much as possible.
The SSL option was chosen for use and as stated in Chapter 6 of this
report a connection over sockets has been established without the security
layer provided by SSL being implemented as of yet. The security layer will
need to be implemented before any real-life data is transmitted from the
field, once implemented data transmission will be secure.
8.2.4 Data Vulnerability
This project requires a connection to be established from a PC within a
hospital to a PC in the MNTE office. This connection is then required to
stay open for the transmission of data for a period of time. This creates an
opening into the hospital system that anyone in the MNTE office can access
as well as possibly other outside sources. It has not been established at this
stage whether this poses a significant threat to the data held on the hospital
PC. End-to-end testing from the MNTE Office to a hospital would need to
occur to establish the threat. For reasons stated in Chapter 6 of this report
that end-to-end test has not been conducted.
86
The worst case is that the computer that the MNTE office is connected
to is also connected on the hospital main network. An unknown source could
then theoretically gain access to this opening and access records stored on
hospital computers. This compromises the integrity of their entire record
collection, creating a massive ethical issue. The Institution of Engineers,
Australia 2000 Code of Ethics states:
In general compliance with the provisions of the Code of Ethics,
members should work in conformity with accepted engineering
and environmental standards and in a manner which does not
jeopardise the public welfare, health or safety.
[Ins, 2000]
Likelihood - Slight
Exposure - Rarely
Consequences - The integrity of a hospital’s entire record collection being
compromised. Private data about patients being made public.
Risk Control: After appropriate end-to-end testing has occurred and the
possibility of this occurring has been established all possible steps will be
taken until it is certain no private data is compromised. This entire project
will strictly abide by The Institution of Engineers, Australia 2000 Code of
Ethics. Future investigation into the aforementioned safety and ethical issue
will take the whole Code of Ethics into account, especially the section quoted
above. The final decision made on the matter will in no way breach the Code
of Ethics.
8.3 Chapter Summary
This chapter discussed the risk assessment documentation for this project.
Previous safety issues that existed before work on this project began were
examined and assessed. New safety issues brought about by the actions taken
in this assignment were also assessed and documented.
87
Chapter 9
Conclusions and Further Work
This chapter concludes this report and summarizes the project. It gives the
conclusions of the work done on the project. Project objectives are reviewed
and achievement of them is discussed. Further work that can be completed
on this topic is also discussed.
9.1 Conclusions
This section summarizes and concludes the work completed on this project.
9.1.1 Planned Work Completed
A brief summary of the work that had been planned for this project and
successfully completed is shown below.
• Research into Bluetooth, Extreme Programming, SSL, VPN’s, and
Firewalls.
• Critical Analyses completed to determine data transmission technique
and system design to use.
• Research into the programming of sockets and secure sockets layer in-
cluding certificate creation.
• Programming of an existing client application, ’Neocot Diagnostics’, to
pass data received from a Neocot via Bluetooth over the Internet via a
socket connection.
• Programming of an original server application, ’MNTE Server’, to re-
ceive data over an Internet socket connection and interpret and display
the data in a meaningful manner.
88
• End-to-end testing of a client running ’Neocot Diagnostics’ application
and a server running the ’MNTE Server’ application, with successful
transmission of data between them over the Internet.
• Programming of test client and test server application incorporating
a security layer over a socket connection using functions from the
sslStream class.
• Successful testing of test client and server applications, achieving suc-
cessful and secure transmission of test data over a LAN and the Inter-
net.
• Investigation into required hardware to allow for two-way data trans-
mission.
9.1.2 Planned Work Not Completed
A brief summary of the work that had been planned for this project but was
not successfully completed, due to time or other restraints, is shown below.
• Implement a security layer over the socket connection between ’Neocot
Diagnostics’ and ’MNTE Server’ allowing for secure data transmission.
• End-to-end testing from a client hospital PC to the server MNTE PC.
9.2 Further Work
This section discusses the further work that can be completed on this topic.
• Implement a security layer over the socket connection between ’Neocot
Diagnostics’ and ’MNTE Server’ allowing for secure data transmission.
The source code that was being used to work on this security layer still
exists in the application source code, simply commented out, further
research into the methods used and how to correctly use them could
render this code still useful.
• Complete end-to-end testing from a client hospital PC to the server
MNTE PC.
This can only be achieved when a Neocot with an available Bluetooth
Module to plug into it is in use in a hospital and the accompany-
ing software has been publically distributed. Therefore for commercial
89
distribution the software would have to include the security layer men-
tioned in the previous step. The entire software would also have to be
finalized with accompanying documentation.
• Implement the required hardware to allow for two-way, real-time data
transmission.
This hardware has been investigated and documented in Chapter 7 of
this report. If this hardware is implemented than two-way, real-time
data can occur, essentially allowing control of a remote Neocot. This
would also require the software to allow for such functionality.
• Extend the ’MNTE Server’ application and ’Neocot Diagnostics’ appli-
cation to encompass two-way data transmission.
This would allow the Virtual Terminal Board in the ’MNTE Server’
application to be interactive and allow the user to press the buttons
on the board. It would then send signals to the ’Neocot Diagnostics’
application which would interpret these and send them on to the Neocot
over the Bluetooth connection.
• Extend the Neocot’s internal, on-board programming to encompass
two-way data transmission.
This would take the signals received over the Bluetooth connection,
interpret them and perform the required function.
• Develop detailed documentation for the entire software package.
This would include editing the existing documentation of the ’Neo-
cot Diagnostics’ application and also developing documentation for the
’MNTE Server’ application. If any changes were made to the Neocot’s
programming this would also have to be documented as well as any
hardware changes.
9.3 Achievement of Project Objectives
This section will review the project objectives set at the beginning of the
project in the project specification, listed in Appendix A of this report. It
discusses the level of achievement of these goals and the work done towards
completing them.
90
9.3.1 Objective 1
The first objective set on the project specification is:
Critically evaluate alternative system designs to access a Neo-
cot remotely, allowing for two-way, real-time, data transmission,
focusing on authentication, security and reliability.
Extensive research into data transmission techniques was completed for
this project and can be viewed in Chapter 2 of this report. Two main tech-
niques were researched for a critical analysis, Secure Sockets Layer (SSL) and
Virtual Private Network, (VPN). A critical analysis was successfully under-
taken on these two options with a satisfactory result being produced. The
techniques were rated on certain characteristics, these being: authentication,
security, reliability and ease of implementation. They also both allowed for
two-way, real-time data transmission. SSL was chosen as the most suitable
option for this project and was the option implemented in this project, al-
though not entirely as will be discussed in later objective reviews. This
critical analysis can be viewed in Chapter 3 of this report.
Another critical analysis was also undertaken to determine the system
hardware design to be used for this project. Three options were designed,
all with different good and bad aspects to them. The criteria they were
rated against were: Ease of use for hospital staff, Ease of use for MNTE
staff, Portability and Required MNTE resources. They all also allowed for
two-way, real-time data transmission. The critical analysis undertaken on
these three options singled out one of these options as being the best system
design for this project. Therefore this option was chosen and was the design
implemented in this project. This critical analysis can also be view in Chapter
3 of this report.
It can be said with a level of confidence that the first objective of this
project was successfully completed to the full extent of specification.
9.3.2 Objective 2
The second objective set on the project specification is:
Investigate and determine the hardware that is required locally
to allow two way data transmission.
Investigation in the hardware required locally and remotely was under-
taken at the MNTE Office and documented in Chapter 7 of this report. No
implementation of the hardware was required although it was set as an op-
tional goal. This optional goal was never started, only the investigation was
conducted.
91
This objective was not the main goal of the project and did not have a
bearing on the one-way data transmission that was the focus of this project.
Therefore not as much time was allocated to this objective. However it can
still be said with a level of confidence that the second objective of this project
was successfully completed to the full extent of the specification.
9.3.3 Objective 3
The third objective set on the project specification is:
Program the software that will be used on the Bluetooth-connected
computer in the hospital and test the programming via the Blue-
tooth interface.
This software is called ’Neocot Diagnostics’ and was already existing soft-
ware before this project was undertaken. It was software developed by Lane
Steffensen for his project, completed in 2008. The version of ’Neocot Di-
agnostics’ used for this project is an extended version. The details of the
changes made to this software can be found in Chapter 4 and Chapter 5 of
this report. The listing of this code can also be found in Appendix E of this
report. The programming of this software module was successful and testing
of the application via the Bluetooth interface can be found in Chapter 5 and
Chapter 6 of this report.
The only programming drawback of this software module is that it does
not encompass a security layer on its socket communications. Socket com-
munication over the Internet is successfully established but the security layer
that the SSL class used, sslStream, is not implemented. Further detail of
this can be found in Chapter 6 of this report. The SSL code has been left
inside the ’Neocot Diagnostics’ source code yet commented out. This is to
allow for further work to be completed using the work already completed on
the subject.
The software module has also not yet been tested in a hospital environ-
ment. This is because of circumstances that cannot be altered, no Neocot’s
with Bluetooth modules are in use yet. Therefore testing was done at the
MNTE Office. This is still in accordance with the project objective.
Therefore it can be said with a level of confidence that the third objective
of this project was successfully completed but not to its full extent. At the
beginning of the project it was stated that data transmission must be secure.
The software module has not yet been programmed to incorporate this level of
security; therefore testing of this cannot be completed. This work is discussed
further in the Further Work section later in this chapter.
92
9.3.4 Objective 4
The fourth objective set on the project specification is:
Develop the software module that will be used at the Mansell
Neonatal Transport Equipment Office to access the Neocot re-
motely. Test the communication between this module and the
hospital PC.
This software is called ’MNTE Server’ and was developed entirely for this
project. Some functions were taken from the ’Neocot Diagnostics’ software
but it is mostly original source code. Details of this code can be found in
Chapter 4 and Chapter 5 of this report. The listing of this code can also be
found in Appendix D of this report. The programming of this software mod-
ule was successful but testing of the application’s communication between
itself and the hospital PC did not occur.
The software module has also not yet been tested to communicate to a
hospital PC yet. This is because of circumstances that cannot be altered, no
Neocot’s with Bluetooth modules are in use yet. The testing of this module
was conducted at the MNTE Office, where the only access to a Neocot with
a Bluetooth module plugged into it, is available. The communication was
then tested between this PC and a remote 3rd party PC over the Internet.
This testing was successful and can be viewed in more detail in Chapter 5
and Chapter 6 of this report.
The only programming drawback of this software module is that it does
not encompass a security layer on its socket communications. At the be-
ginning of the project it was stated that data transmission must be secure.
Socket communication over the Internet is successfully established but the
security layer that the SSL class used, sslStream, is not implemented. Fur-
ther detail of this can be found in Chapter 6 of this report. The SSL code has
been left inside the ’MNTE Server’ source code yet commented out. This is
to allow for further work to be completed using the work already completed
on the subject. This work is discussed further in the Further Work section
later in this chapter.
Therefore it can be said with a level of confidence that the fourth objective
of this project was not successfully completed. This is only due to the fact
that testing between the MNTE Office and an actual hospital PC could not
physically occur. Also, if it were to be completed to its full extent, SSL would
have been incorporated in time.
9.3.5 Objective 5
The fifth objective set on the project specification is:
93
Test the system end-to-end over the Internet and the Bluetooth
interface.
As has been discussed in the previous objective reviews, the end-to-end
testing was completed but not as expected when the project began. With
the only Neocot’s with Bluetooth modules available being at the MNTE
Office, the ’Neocot Diagnostics’ application had to be tested there. This
required the ’MNTE Server’ application to be tested at a remote, 3rd party
PC, allowing for the communication to occur over the Internet. This end-to-
end testing between the MNTE Office PC and a remote, 3rd party PC was
very successful and data transmission occurred with the expected results.
Discussion, screenshots and results from the end-to-end test undertaken can
be found in Chapter 6 of this report.
Therefore it can be said with a level of confidence that the fifth objective
of this project was completed successfully though not to its full extent as
first planned. This is only due to the fact that testing between the MNTE
Office and an actual hospital PC could not physically occur.
9.4 Chapter Summary
This chapter concludes the report. Work completed as part of this project
was listed and acheivment of initial objectives was reviewed.
Initial objectives were all were attempted. Some objectives were com-
pleted to a higher degree than others. The critical analyses of data transmis-
sion technique and system design was completed in full as was the two-way
data transmission hardware investigation.
The development of MNTE Server code and Neocot Diagnostics code
was completed to a sufficient level. Successful data transmission from a
remote Neocot over the Internet to a local computer was acheived. The
data transmission was insecure. The bug encountered in the sslStream code
prevented a security layer to be implemented on the data transmission within
the scope of this project.
The unavailability of a Bluetooth enabled, remote Neocot prevented a
test to occur allowing for data transmission to occur from a hospital to the
MNTE Office. Rather, the test conducted, saw the data being transmitted
from the MNTE Office to a 3rd party premises.
In conclusion the project was a success. Additionally it allows scope for
future work to completed on the topic.
94
Bibliography
Kent Beck and Cynthia Andres. Extreme programming explained : embrace
change 2nd Edition. Addison-Wesley, Boston, Massachusetts, 2005.
Reuven Cohen and Gideon Kaempfer. On the cost of virtual private networks.
IEEE/ACM Transactions on Networking (TON), Volume 8(Issue 6):Pages:
775–784, December 2000.
Barrie Dempster and James Eaton-Lee. Configuring IPCop Firewalls. Packt
Publishing, Birmingham, UK, 2006.
Andrew Dursch, David Yen, and Dong-Her Shih. Bluetooth technology: an
exploratory study of the analysis and implementation frameworks. Com-
puter Standards and Interfaces, Volume 26(Issue 4):Pages 263–278, 2004.
Dynamic Network Services Inc. DynDNS.com.
http://www.dyndns.com/, current September 2009.
James Edwards, Richard Bramante, and Al Martin. Nortel guide to VPN
routing for security and VoIP. Wiley Publishing, Indianapolis, Indiana,
2006.
Christian Gehrmann. Bluetooth Security. Artech House, Boston, Mas-
sachusetts, 2004.
Marcus Goncalves. Firewalls: A Complete Guide. McGraw-Hill, New York
City, New York, 2000.
John Grant-Thomson. Cost-effective intenstive-care transportation of the
critically ill. World Congress on Emergency and Disaster Medicine, Vol-
ume 10:Page 1–9, 1997.
John Grant-Thomson. Biomedical engineering design in aeromedical trans-
port. International Air Ambulance Conference, Volume 4:Page 1–10, 1998.
95
Meeta Gupta. Building a Virtual Private Network. Premier Press, Portland,
Oregon, 2003.
David Hausheer. Creating a self-signed X509 server certificate and a PKCS12
client certificate with openssl.
http://hausheer.osola.com/docs/9, current September 2009.
Anne Henmi, Mark Lucas, Abhishek Singh, and Chris Cantrell. Firewall
policies and VPN configurations. Syngress, Rockland, Massachusetts, 2006.
Eli Herscovitz. Secure virtual private networks: the future of data commu-
nications. International Journal of Network Management, Volume 9(Issue
4):Pages: 213–220, July 1999.
The Instituiton of Engineers Australia Code Of Ethics 2000. The Institute
of Engineers Australia, april 2000 edition, 2000.
Internet Assigned Numbers Authority. Internet Assigned Numbers Author-
ity.
http://www.iana.org, current September 2009.
Ron Jeffries. Extreme Programming Adventures in C#. Microsoft Press, New
York City, New York, 2004.
Homin K. Lee, Tal Malkin, and Erich Nahum. Cryptographic strength of
ssl/tls servers: current and recent practices. IMC ’07: Proceedings of the
7th ACM SIGCOMM conference on Internet measurement, pages Pages
83–91, 2007.
Alex Liu and Fei Chen. Collaborative enforcement of firewall policies in
virtual private networks. PODC ’08: Proceedings of the twenty-seventh
ACM symposium on Principles of distributed computing, Session R3:Pages
95–104, 2008.
Microsoft. Microsoft Developer Network.
http://msdn.microsoft.com, current September 2009.
David Morgan. Workings of a virtual private network, part 1: A look into
vpns–what they are and how they work. Linux Journal, Volume 1999(Issue
68es), December 1999. Article No. 2.
Robert Morrow. Bluetooth Operation and Use. McGraw-Hill, New York City,
New York, 2002.
96
Rolf Oppliger. Security technologies for the World Wide Web, second edition.
Artech House, Boston, Massachusetts, 2003.
Greg Pearman and James Goodwill. Pro .NET 2.0 Extreme Programming.
Apress, New York City, New York, 2006.
Pino Persiano and Ivan Visconti. A secure and private system for
subscription-based remote services. ACM Transactions on Information
and System Security, Volume 6(Number 4):Page 472–499, November 2003.
Rami Rosen. Creating vpns with ipsec and ssl/tls. Linux Journal, Volume
2008(Issue 165), January 2008. Article No. 10.
RSI and Overuse Injury Association. What is RSI/OOS?
http://www.rsi.org.au/what-is-rsi.html, current May 2009.
Bruce Schneier. Security Pitfalls in Cryptography.
M.S Sriram. Firewalls. Silicon Press, Summit, New Jersey, 2002.
Lane Steffensen. Wireless bluetooth transmission of neocot diagnostics in-
formation. ENG4112 Ressearch Project, page Page 75, 2008.
Matt Stephens and Doug Rosenberg. Extreme Programming Refactored: The
Case Against XP. Apress, New York City, New York, 2003.
Matthew Strebe and Charles Perkins. Firewalls 24Seven , Second Edition.
Sybex, San Francisco, California, 2002.
Stephen A. Thomas. SSL and TLS essentials : securing the Web. Wiley
Computer Publishing, New York, 2000.
John Vacca and Scott Ellis. Firewalls: Jumpstart for Network and Systems
Administrators. Elsevier Digital Press, Amsterdam, Netherlands, 2005.
David Wagner and Bruce Schneier. Analysis of the ssl 3.0 protocol. The
Second USENIX Workshop on Electronic Commerce Proceedings, pages
Page 29–40, November 1996.
Don Wells. The Rules and Practices of Extreme Programming.
http://www.extremeprogramming.org/rules.html, current May 2009.
www.akadia.com. How to create a self-signed SSL Certificate.
http://www.akadia.com/services/sshtestcertificate.html, currentSeptember2009.
97
www.stunnel.org. www.stunnel.org.
http://www.stunnel.org/download/stunnel/win32/openssl-0.9.7/,
current September 2009.
Neil Wyler. Juniper Networks Secure Access SSL VPN Configuration Guide.
Syngress Publishing, Burlington, Massachusetts, 2007.
98
Appendix A
Project Specification
99
                                                                                                                             
University of Southern Queensland 
 
FACULTY OF ENGINEERING AND SURVEYING 
 
ENG4111/4112 Research Project 
PROJECT SPECIFICATION 
 
 
FOR:  Matthew Kinast 
 
TOPIC: Real time data transmission and control of a Neocot over the Internet 
 
SUPERVISOR: Dr Alexander Kist 
 
SPONSORHSIP: Mansell Neonatal Transport Equipment 
 
PROJECT AIM:  To extend an existing system to be able to send diagnostic data from a 
client, over the Internet, and display it on a server in real time. 
   
PROGRAMME:  (Issue B, 28/04/2009) 
 
1. Critically evaluate alternative system designs to access a Neocot remotely, allowing 
for two-way, real-time, data transmission, focussing on authentication, security and 
reliability. 
 
2. Investigate and determine the hardware that is required locally to allow two way data 
transmission. 
 
3. Program the software that will be used on the Bluetooth-connected computer in the 
hospital and test the programming via the Bluetooth interface. 
 
4. Develop the software module that will be used at the Mansell Neonatal Transport 
Equipment Office to access the Neocot remotely. Test the communication between this 
module and the hospital PC. 
 
5. Test the system end-to-end over the Internet and the Bluetooth interface. 
 
As time permits: 
 
6. Implement hardware required locally to allow two way data transmission. 
 
7. Extend the software module used at the Mansell Neonatal Transport Equipment 
Office to remotely control the Neocot’s basic functions.  
 
 
8. Prepare detailed documentation of the system components and user manuals for 
commercial use with the Neocot system. 
 
 
 
AGREED          (student)               (supervisor) 
 
  Date:        /         / 2009                                   Date:          /         / 2009 
 
Co-examiner: 
Appendix B
SSL Host Code
using System;
using System.Collections;
using System.Net;
using System.Net.Sockets;
using System.Net.Security;
using System.Security.Authentication;
using System.Text;
using System.Security.Cryptography.X509Certificates;
using System.IO;
namespace Examples.System.Net
{
public sealed class SslTcpServer
{
static X509Certificate serverCertificate = null;
// The certificate parameter specifies the name of the file
// containing the machine certificate.
public static void RunServer(string certificate)
{
serverCertificate =
X509Certificate.CreateFromCertFile(certificate);
// Establish the local endpoint for the socket.
// The DNS name of the computer
// running the listener is "kinast.homeip.net".
IPHostEntry ipHostInfo = Dns.Resolve(Dns.GetHostName());
IPAddress ipAddress = ipHostInfo.AddressList[0];
//ipAddress = IPAddress.Parse("192.168.0.103");
100
//IPEndPoint localEndPoint = new IPEndPoint(ipAddress, 1002);
Console.WriteLine(ipAddress);
// Create a TCP/IP (IPv4) socket and listen for
// incoming connections.
TcpListener listener = new TcpListener(ipAddress, 443);
listener.Start();
while (true)
{
Console.WriteLine("Waiting for a client to connect...");
// Application blocks while waiting for an
// incoming connection.
// Type CNTL-C to terminate the server.
TcpClient client = listener.AcceptTcpClient();
ProcessClient(client);
}
}
static void ProcessClient(TcpClient client)
{
// A client has connected. Create the
// SslStream using the client’s network stream.
SslStream sslStream = new SslStream(
client.GetStream(), false);
// Authenticate the server but don’t require the
// client to authenticate.
try
{
sslStream.AuthenticateAsServer(serverCertificate,
false, SslProtocols.Tls, true);
// Display the properties and settings for
//the authenticated stream.
DisplaySecurityLevel(sslStream);
DisplaySecurityServices(sslStream);
DisplayCertificateInformation(sslStream);
DisplayStreamProperties(sslStream);
// Set timeouts for the read and write to 5 seconds.
sslStream.ReadTimeout = 5000;
sslStream.WriteTimeout = 5000;
// Read a message from the client.
Console.WriteLine("Waiting for client message...");
101
string messageData = ReadMessage(sslStream);
Console.WriteLine("Received: {0}", messageData);
// Write a message to the client.
byte[] message =
Encoding.UTF8.GetBytes("Hello from the server.");
Console.WriteLine("Sending hello message.");
sslStream.Write(message);
}
catch (AuthenticationException e)
{
Console.WriteLine("Exception: {0}", e.Message);
if (e.InnerException != null)
{
Console.WriteLine("Inner exception: {0}",
e.InnerException.Message);
}
Console.WriteLine("Authentication failed -
closing the connection.");
sslStream.Close();
client.Close();
return;
}
finally
{
// The client stream will be closed with the sslStream
// because we specified this behavior when creating
// the sslStream.
sslStream.Close();
client.Close();
}
}
static string ReadMessage(SslStream sslStream)
{
// Read the message sent by the client.
// The client signals the end of the message using the
// "" marker.
byte[] buffer = new byte[2048];
StringBuilder messageData = new StringBuilder();
int bytes = -1;
do
102
{// Read the client’s test message.
bytes = sslStream.Read(buffer, 0, buffer.Length);
// Use Decoder class to convert from bytes to UTF8
// in case a character spans two buffers.
Decoder decoder = Encoding.UTF8.GetDecoder();
char[] chars =
new char[decoder.GetCharCount(buffer, 0, bytes)];
decoder.GetChars(buffer, 0, bytes, chars, 0);
messageData.Append(chars);
// Check for EOF or an empty message.
if (messageData.ToString().IndexOf("") != -1)
{
break;
}
} while (bytes != 0);
return messageData.ToString();
}
static void DisplaySecurityLevel(SslStream stream)
{
Console.WriteLine("Cipher: {0} strength {1}",
stream.CipherAlgorithm, stream.CipherStrength);
Console.WriteLine("Hash: {0} strength {1}",
stream.HashAlgorithm, stream.HashStrength);
Console.WriteLine("Key exchange: {0} strength {1}",
stream.KeyExchangeAlgorithm, stream.KeyExchangeStrength);
Console.WriteLine("Protocol: {0}", stream.SslProtocol);
}
static void DisplaySecurityServices(SslStream stream)
{
Console.WriteLine("Is authenticated: {0} as
server? {1}", stream.IsAuthenticated, stream.IsServer);
Console.WriteLine("IsSigned: {0}", stream.IsSigned);
Console.WriteLine("Is Encrypted: {0}", stream.IsEncrypted);
}
static void DisplayStreamProperties(SslStream stream)
{
Console.WriteLine("Can read: {0}, write {1}",
stream.CanRead, stream.CanWrite);
103
Console.WriteLine("Can timeout: {0}", stream.CanTimeout);
}
static void DisplayCertificateInformation(SslStream stream)
{
Console.WriteLine("Certificate revocation
list checked: {0}", stream.CheckCertRevocationStatus);
X509Certificate localCertificate = stream.LocalCertificate;
if (stream.LocalCertificate != null)
{
Console.WriteLine("Local cert was issued
to {0} and is valid from {1} until {2}.",
localCertificate.Subject,
localCertificate.GetEffectiveDateString(),
localCertificate.GetExpirationDateString());
}
else
{
Console.WriteLine("Local certificate is null.");
}
// Display the properties of the client’s certificate.
X509Certificate remoteCertificate =
stream.RemoteCertificate;
if (stream.RemoteCertificate != null)
{
Console.WriteLine("Remote cert was issued
to {0} and is valid from {1} until {2}.",
remoteCertificate.Subject,
remoteCertificate.GetEffectiveDateString(),
remoteCertificate.GetExpirationDateString());
}
else
{
Console.WriteLine("Remote certificate is null.");
}
}
private static void DisplayUsage()
{
Console.WriteLine("To start the server specify:");
Console.WriteLine("serverSync certificateFile.cer");
Environment.Exit(1);
104
}public static int Main(string[] args)
{
string certificate = null;
if (args == null || args.Length < 1)
{
DisplayUsage();
}
certificate = args[0];
SslTcpServer.RunServer(certificate);
return 0;
}
}
}
105
Appendix C
SSL Client Code
using System;
using System.Collections;
using System.Net;
using System.Net.Security;
using System.Net.Sockets;
using System.Security.Authentication;
using System.Text;
using System.Security.Cryptography.X509Certificates;
using System.IO;
namespace Examples.System.Net
{
public class SslTcpClient
{
private static Hashtable certificateErrors =
new Hashtable();
// The following method is invoked by
// the RemoteCertificateValidationDelegate.
public static bool ValidateServerCertificate(
object sender,
X509Certificate certificate,
X509Chain chain,
SslPolicyErrors sslPolicyErrors)
{
if (sslPolicyErrors == SslPolicyErrors.None)
return true;
106
Console.WriteLine("Certificate error:
{0}", sslPolicyErrors);
// Do not allow this client to communicate
// with unauthenticated servers.
return false;
//return true;
}
public static void RunClient(string machineName,
string serverName)
{
// Establish the remote endpoint for the socket.
// The name of the
// remote device is "kinast.homeip.net".
//IPHostEntry ipHostInfo =
Dns.Resolve("mattkinast.homeip.net");
//IPAddress ipAddress = ipHostInfo.AddressList[0];
//ipAddress = IPAddress.Parse("192.168.0.103");
//IPEndPoint remoteEP = new IPEndPoint(ipAddress, 443);
//Console.WriteLine(ipAddress);
// Create a TCP/IP client socket.
// machineName is the host running the
// server application.
TcpClient client = new TcpClient(machineName, 443);
Console.WriteLine("Client connected.");
// Create an SSL stream that will close the
// client’s stream.
SslStream sslStream = new SslStream(
client.GetStream(),
false,
new RemoteCertificateValidationCallback
(ValidateServerCertificate),
null
);
// The server name must match the name
// on the server certificate.
try
{
sslStream.AuthenticateAsClient(serverName);
107
}catch (AuthenticationException e)
{
Console.WriteLine("Exception: {0}", e.Message);
if (e.InnerException != null)
{
Console.WriteLine("Inner exception:
{0}", e.InnerException.Message);
}
Console.WriteLine("Authentication failed
- closing the connection.");
client.Close();
return;
}
// Encode a test message into a byte array.
// Signal the end of the message using the "".
byte[] messsage =
Encoding.UTF8.GetBytes("Hello from the client.");
// Send hello message to the server.
sslStream.Write(messsage);
sslStream.Flush();
// Read message from the server.
string serverMessage = ReadMessage(sslStream);
Console.WriteLine("Server says: {0}", serverMessage);
// Close the client connection.
client.Close();
Console.WriteLine("Client closed.");
}
static string ReadMessage(SslStream sslStream)
{
// Read the message sent by the server.
// The end of the message is signaled using the
// "" marker.
byte[] buffer = new byte[2048];
StringBuilder messageData = new StringBuilder();
int bytes = -1;
do
{
bytes = sslStream.Read(buffer, 0, buffer.Length);
108
// Use Decoder class to convert from
// bytes to UTF8
// in case a character spans two buffers.
Decoder decoder = Encoding.UTF8.GetDecoder();
char[] chars =
new char[decoder.GetCharCount(buffer, 0, bytes)];
decoder.GetChars(buffer, 0, bytes, chars, 0);
messageData.Append(chars);
// Check for EOF.
if (messageData.ToString().IndexOf("") != -1)
{
break;
}
} while (bytes != 0);
return messageData.ToString();
}
private static void DisplayUsage()
{
Console.WriteLine("To start the client specify:");
Console.WriteLine("clientSync machineName [serverName]");
Environment.Exit(1);
}
public static int Main(string[] args)
{
string serverCertificateName = null;
string machineName = null;
if (args == null || args.Length < 1)
{
DisplayUsage();
}
// User can specify the machine name and server name.
// Server name must match the name on
// the server’s certificate.
machineName = args[0];
if (args.Length < 2)
{
serverCertificateName = machineName;
109
}else
{
serverCertificateName = args[1];
}
SslTcpClient.RunClient(machineName,
serverCertificateName);
return 0;
}
}
}
110
Appendix D
MNTE Server Code
//---------------------------------------------------------------
//Name: MNTE Server Application
//Author: Matthew Kinast
//Property of Mansell Neonatal Transport Equipment Pty. Ltd.
//Add classes
using System;
using System.Collections;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.IO.Ports;
using System.IO;
using System.Reflection;
using System.Net.Mail; //email
using System.Text.RegularExpressions;
using System.Threading; //threads
using System.Diagnostics; //open exe
using System.Net; //sockets
using System.Net.Sockets;
//For SSL
using System.Net.Security;
using System.Security.Authentication;
using System.Security.Cryptography.X509Certificates;
111
namespace MNTE_Server
{
public partial class Form1 : Form
{
// This delegate enables asynchronous calls for setting
// the text property on a TextBox control.
delegate void SetTextCallback(string text);
// Form 1
public Form1()
{
InitializeComponent();
}
//Socket packet class
public class CSocketPacket
{
public System.Net.Sockets.Socket thisSocket;
public byte[] dataBuffer = new byte[200];
}
//Global variable for this thread/Class
//worker callback
public AsyncCallback pfnWorkerCallBack;
public Socket serverSocket;
public Socket serverWorker;
bool errorMode = false;
decimal calCont = 0M;
decimal calDisp = 0M;
//SSL certificate file
static X509Certificate serverCertificate = null;
//log file variables
//Name of the log file
string logFilename;
//Stream writer for data entry
StreamWriter logFile;
112
/********************************************************************
* Function: SSL FUNCTIONS
* Description: TO BE DONE
*
********************************************************************/
/*
public void RunServer()
{
string certificate = "ca.cer";
serverCertificate =
X509Certificate.CreateFromCertFile(certificate);
// Establish the local endpoint for the socket.
// The DNS name of the computer
// running the listener is "kinast.homeip.net".
IPHostEntry ipHostInfo = Dns.Resolve(Dns.GetHostName());
IPAddress ipAddress = ipHostInfo.AddressList[0];
//ipAddress = IPAddress.Parse("192.168.0.103");
//IPEndPoint localEndPoint =
new IPEndPoint(ipAddress, 1002);
if (this.statusDisplay.InvokeRequired)
{
// It’s on a different thread, so use Invoke.
SetTextCallback e = new SetTextCallback(SetText);
this.Invoke
(e, new object[] {Convert.ToString(ipAddress) });
}
else
{
// It’s on the same thread, no need for Invoke
this.statusDisplay.Text =
Convert.ToString(ipAddress);
}
//Console.WriteLine(ipAddress);
// Create a TCP/IP (IPv4) socket and listen
//for incoming connections.
TcpListener listener = new TcpListener(ipAddress, 443);
listener.Start();
//while (true)
//{
113
//Console.WriteLine("Waiting for
a client to connect...");
if (this.statusDisplay.InvokeRequired)
{
// It’s on a different thread, so use Invoke.
SetTextCallback e =
new SetTextCallback(SetText);
this.Invoke
(e, new object[] { ("\r\nWaiting for
a client to connect...\r\n") });
}
else
{
// It’s on the same thread, no need for Invoke
this.statusDisplay.Text =
("\r\nWaiting for a client to connect...\r\n");
}
// Application blocks while
// waiting for an incoming connection.
// Type CNTL-C to terminate the server.
TcpClient client = listener.AcceptTcpClient();
ProcessClient(client);
//}
}
public void ProcessClient(TcpClient client)
{
// A client has connected. Create the
// SslStream using the client’s network stream.
SslStream sslStream = new SslStream(
client.GetStream(), false);
// Authenticate the server but don’t
// require the client to authenticate.
try
{
sslStream.AuthenticateAsServer
(serverCertificate,
false, SslProtocols.Tls, true);
114
// Display the properties and settings
//for the authenticated stream.
DisplaySecurityLevel(sslStream);
DisplaySecurityServices(sslStream);
DisplayCertificateInformation(sslStream);
DisplayStreamProperties(sslStream);
// Set timeouts for the read and write to 5 seconds.
sslStream.ReadTimeout = 5000;
sslStream.WriteTimeout = 5000;
// Read a message from the client.
//Console.WriteLine("Waiting for client message...");
if (this.statusDisplay.InvokeRequired)
{
// It’s on a different thread, so use Invoke.
SetTextCallback e = new SetTextCallback(SetText);
this.Invoke
(e, new object[] { ("Client connected\r\n
Waiting for client message...\r\n") });
}
else
{
// It’s on the same thread, no need for Invoke
this.statusDisplay.Text = ("Client connected\r\n
Waiting for client message...\r\n");
}
//statusDisplay.Text +=
("Waiting for client message...\r\n");
string messageData = ReadMessage(sslStream);
if (this.statusDisplay.InvokeRequired)
{
// It’s on a different thread, so use Invoke.
SetTextCallback e = new SetTextCallback(SetText);
this.Invoke
(e, new object[] { ("Received: " + messageData) });
}
else
{
// It’s on the same thread, no need for Invoke
this.statusDisplay.Text =
115
("Received: " + messageData);
}
//statusDisplay.Text += ("Received: " + messageData);
//Console.WriteLine("Received: {0}", messageData);
// Write a message to the client.
//byte[] message =
Encoding.UTF8.GetBytes("Hello from the server.");
//Console.WriteLine("Sending hello message.");
//sslStream.Write(message);
}
catch (AuthenticationException e)
{
statusDisplay.Text += ("Exception: " + e.Message);
//Console.WriteLine("Exception: {0}", e.Message);
if (e.InnerException != null)
{
statusDisplay.Text+=
("Inner exception: "+ e.InnerException.Message);
}
statusDisplay.Text +=
("Authentication failed - closing the connection.");
sslStream.Close();
client.Close();
return;
}
finally
{
// The client stream will be closed with the sslStream
// because we specified this behavior when creating
// the sslStream.
sslStream.Close();
client.Close();
}
}
public string ReadMessage(SslStream sslStream)
{
// Read the message sent by the client.
// The client signals the end of the message using the
// "" marker.
116
byte[] buffer = new byte[2048];
StringBuilder messageData = new StringBuilder();
int bytes = -1;
do
{
// Read the client’s test message.
bytes = sslStream.Read(buffer, 0, buffer.Length);
// Use Decoder class to convert from bytes to UTF8
// in case a character spans two buffers.
Decoder decoder = Encoding.UTF8.GetDecoder();
char[] chars =
new char[decoder.GetCharCount(buffer, 0, bytes)];
decoder.GetChars(buffer, 0, bytes, chars, 0);
messageData.Append(chars);
// Check for EOF or an empty message.
if (messageData.ToString().IndexOf("") != -1)
{
break;
}
} while (bytes != 0);
return messageData.ToString();
}
public void DisplaySecurityLevel(SslStream stream)
{
//Console.WriteLine("Cipher: {0} strength {1}",
stream.CipherAlgorithm, stream.CipherStrength);
//Console.WriteLine("Hash: {0} strength {1}",
stream.HashAlgorithm, stream.HashStrength);
//Console.WriteLine("Key exchange: {0} strength {1}",
stream.KeyExchangeAlgorithm, stream.KeyExchangeStrength);
//Console.WriteLine("Protocol: {0}", stream.SslProtocol);
}
public void DisplaySecurityServices(SslStream stream)
{
//Console.WriteLine("Is authenticated: {0}
as server? {1}", stream.IsAuthenticated, stream.IsServer);
//Console.WriteLine("IsSigned: {0}", stream.IsSigned);
//Console.WriteLine("Is Encrypted: {0}", stream.IsEncrypted);
}
117
public void DisplayStreamProperties(SslStream stream)
{
//Console.WriteLine("Can read: {0}, write {1}",
stream.CanRead, stream.CanWrite);
//Console.WriteLine("Can timeout: {0}", stream.CanTimeout);
}
public void DisplayCertificateInformation(SslStream stream)
{
//Console.WriteLine("Certificate revocation list
checked: {0}", stream.CheckCertRevocationStatus);
X509Certificate localCertificate =
stream.LocalCertificate;
if (stream.LocalCertificate != null)
{
//Console.WriteLine("Local cert was issued to {0}
// and is valid from {1} until {2}.",
//localCertificate.Subject,
//localCertificate.GetEffectiveDateString(),
//localCertificate.GetExpirationDateString());
}
else
{
//Console.WriteLine("Local certificate is null.");
}
// Display the properties of the client’s certificate.
X509Certificate remoteCertificate = stream.RemoteCertificate;
if (stream.RemoteCertificate != null)
{
//Console.WriteLine("Remote cert was issued to
{0} and is valid from {1} until {2}.",
//remoteCertificate.Subject,
//remoteCertificate.GetEffectiveDateString(),
//remoteCertificate.GetExpirationDateString());
}
else
{
//Console.WriteLine("Remote certificate is null.");
}
}
public void DisplayUsage()
118
{//Console.WriteLine("To start the server specify:");
//Console.WriteLine("serverSync certificateFile.cer");
Environment.Exit(1);
}
*/
/********************************************************************
* Function: StartListening
* Description: Creates a listening TCP socket
*
********************************************************************/
public void StartListening()
{
try
{
//Create listening socket
serverSocket = new Socket(AddressFamily.InterNetwork,
SocketType.Stream, ProtocolType.Tcp);
// Establish the local endpoint for the socket.
// The DNS name of the computer
// running the listener is "kinast.homeip.net".
IPHostEntry ipHostInfo = Dns.Resolve(Dns.GetHostName());
IPAddress ipAddress = ipHostInfo.AddressList[0];
IPEndPoint localEndPoint = new IPEndPoint(ipAddress, 443);
statusDisplay.Text += ipAddress;
//local IP endpoint
//IPEndPoint localEndPoint =
new IPEndPoint(IPAddress.Parse("192.168.0.103"), 443);
//bind socket to local IP address
serverSocket.Bind(localEndPoint);
//start listening for connections
serverSocket.Listen(4);
//create callback for client connections
serverSocket.BeginAccept
(new AsyncCallback(OnClientConnect), null);
statusDisplay.Text +=
119
("\r\nListening for incoming data....\r\n");
}
catch (SocketException ex)
{
statusDisplay.Text += (ex.Message);
}
}
/********************************************************************
* Function: OnClientConnect
* Description: Calls wait for data function when a client connection is
* established.
*
********************************************************************/
public void OnClientConnect(IAsyncResult asyn)
{
try
{
//socket type defined above
serverWorker = serverSocket.EndAccept(asyn);
//call main routine and wait for data
waitForData(serverWorker);
}
catch (ObjectDisposedException)
{
System.Diagnostics.Debugger.Log(0, "1", "\n
On Client Connection: Socket has been closed\n");
}
catch (SocketException ex)
{
statusDisplay.Text += (ex.Message);
}
}
/********************************************************************
* Function: waitForData
* Description: Waits for data to be received
*
********************************************************************/
public void waitForData(System.Net.Sockets.Socket serverWorker)
{
120
try
{
//the callback event for the worker socket
if (pfnWorkerCallBack == null)
{
pfnWorkerCallBack =
new AsyncCallback(OnDataReceived); //reset event
}
//Create packet to recieve data in
CSocketPacket theSocPkt = new CSocketPacket();
theSocPkt.thisSocket = serverWorker;
//Recieve data into the packet
serverWorker.BeginReceive(theSocPkt.dataBuffer, 0,
theSocPkt.dataBuffer.Length, SocketFlags.None,
pfnWorkerCallBack, theSocPkt);
}
catch (SocketException ex)
{
statusDisplay.Text += (ex.Message);
}
}
/********************************************************************
* Function: OnDataReceived
* Description: Writes data to system string, displays this string and writes
* it to a log file. The string is the identified and sent to the relevant
* function for processing
*
********************************************************************/
public void OnDataReceived(IAsyncResult asyn)
{
//Regular expression line to recognize error data
//Line starts with " E" and then followed by a number
Regex errorLine = new Regex(" E[0-9]");
//string[] bufLines = null;
try
{
CSocketPacket theSockId = (CSocketPacket)asyn.AsyncState;
//initialise read bytes counter
int iRx = 0;
121
//no of recieved bytes
iRx = theSockId.thisSocket.EndReceive(asyn);
//create initial character array
char[] chars = new char[iRx];
//decode text
System.Text.Decoder d = System.Text.Encoding.UTF8.GetDecoder();
int charLen =
d.GetChars(theSockId.dataBuffer, 0, iRx, chars, 0);
//put data into string
System.String lineOfData = new System.String(chars);
//process the data recieved
//if(szData.Contains("Connection Established"))
//{
// statusDisplay.Text+= szData;
//}
//debug.Text += szData;
//processBufferData(szData);
//Display raw, received data in text box
//statusDisplay.Text += (lineOfData);
// statusDisplay.Text += ("\r\n");
// Check if this method is running on a different thread
// than the thread that created the control.
if (this.statusDisplay.InvokeRequired)
{
// It’s on a different thread, so use Invoke.
SetTextCallback e = new SetTextCallback(SetText);
this.Invoke
(e, new object[] { lineOfData + "\r\n"});
}
else
{
// It’s on the same thread, no need for Invoke
this.statusDisplay.Text = lineOfData + "\r\n";
}
//Serial number used for log file name
if (lineOfData.Contains("Log Filename:"))
{
createLog(lineOfData.Substring(14));
122
}else
{
//Write raw, received data to log file
logFile.WriteLine(lineOfData + "\r\n");
//--------------------------
//Identify Data
//--------------------------
//End of file
if (lineOfData.Contains("EOF"))
{
//Flush out buffer to log file
logFile.Flush();
//stop writing to the logfile and close it
logFile.Close();
//Close server socket
//serverSocket.Disconnect(true);
serverSocket.Close();
//Disable visibility of begin
//connection button and texts
beginPanel.Visible = false;
//Enable visibility of end
//connection button and texts
finishedCover.Visible = false;
//Change tab to the finished tab
tabControl1.SelectedTab = tabPage1;
}
//Check for error information
if (lineOfData.StartsWith(" error count") ||
(errorMode.Equals(true))))
{
//enable error mode
errorMode = true;
//jump to the routine that handles errors
errorDetected(lineOfData);
123
}//If Error log cleared
if (lineOfData.Contains("E10"))
{
//Display correct light and text for
//Error Log Cleared Error
LightColour("R", osData, osLight);
LightColour("O", heaterData, heaterLight);
LightColour("O", fanData, fanLight);
LightColour("O", capsuleOverheatData,
capsuleOverheatLight);
LightColour("O", setTempModeData, setTempModeLight);
LightColour("O", capsulePowerData, capsulePowerLight);
LightColour("O", heaterPowerData, heaterPower1);
LightColour("O", heaterPowerData, heaterPower2);
LightColour("O", heaterPowerData, heaterPower3);
LightColour("O", heaterPowerData, heaterPower4);
errorData.Text = " E10 Error Log Cleared";
tempData.Text = "E1.0";
errorMode = false;
}
//Read header and body information
else
{
//Check for header information
if ((lineOfData.StartsWith(" ")))
{
readHeader(lineOfData);
}
//Check for body information
//data must be at least 102 long, and less than 200.
else if (lineOfData.Length >= 102
&& lineOfData.Length <= 200)
{
//Jumps to the routine that cuts
//up the buffer information
splitAndDisplay(lineOfData);
}
}
}
124
Thread.Sleep(0);
//Recall the wait for data function
waitForData(serverWorker);
}
catch (ObjectDisposedException)
{
System.Diagnostics.Debugger.Log(0, "1", "\n On
Client Connection: Socket has been closed\n");
}
catch (SocketException ex)
{
MessageBox.Show(ex.Message + "\r\nThe logged data
is saved as: \r\n" + logFilename + "\r\n
The application will now restart");
Application.Restart();
}
}
/********************************************************************
* Function: SetText
* Description: This method is passed in to the SetTextCallBack delegate
* to set the Text property of statusDisplay.
*
********************************************************************/
private void SetText(string text)
{
this.statusDisplay.Text += text;
}
/********************************************************************
* Function: readHeader
* Description: Reads header data and displays some information to the user
* as well as resetting variables if Neocot is reset
*
********************************************************************/
public void readHeader(string lineOfData)
{
this.BeginInvoke((ThreadStart)delegate()
{
//Reset variables on cot restart
if (lineOfData.Substring(0, 3) == " ST")
125
{resetVirtualCot();
}
//make sure the line of data is long enough to read
if (lineOfData.Length > 21)
{
//search for important data
try
{
switch (lineOfData.Substring(0, 20))
{
case " no. of past errors ":
//gets the no of past errors
pastErrorsData.Text =
lineOfData.Substring(lineOfData.Length - 2, 2);
break;
case " Calibration data ch":
//get the calibration ok, bad string
checksumData.Text =
lineOfData.Substring(lineOfData.Length - 3, 3);
break;
case " Calibration data, C":
//gets the calibration data
calCont =
Convert.ToDecimal(lineOfData.Substring(29, 6));
calDisp =
Convert.ToDecimal(lineOfData.Substring(47, 6));
break;
case " Neocot Main Softwar":
//gets the software build
softwareBuildData.Text =
lineOfData.Substring(lineOfData.Length - 5, 5);
break;
}
}
catch (System.FormatException)
{
//dissable the system
MessageBox.Show("Header Data Corrupt,
Please Restart Application", "Neocot Diagnostices");
}
126
catch (System.Exception ex)
{
MessageBox.Show("Testing ERROR " +
ex.Message, "Neocot Diagnostics E02");
}
}
});
}
/********************************************************************
* Function: splitAndDisplay
* Description: Splits buffer data and displays certain values to the user
* as text and as lights and data on the viurtual Neocot
*
********************************************************************/
private void splitAndDisplay(string lineOfData)
{
// array of strings of diag data
string[] splitBuf = null;
//Other function variables
decimal frontControl = 0M, rearControl = 0M;
decimal frontDisplay = 0M, rearDisplay = 0M;
int heaterPower = 0;
string fanTorque = null;
string lightData = null;
string alarmData;
string alarmDataUpper;
//int offset = 0;
//For sending to lightColour() function
string colour;
int setTempDone = 0;
int tempDispDone = 0;
int alarmLightsDone = 0;
string time = "0";
// split the log data on each comma
splitBuf = lineOfData.Split(’,’);
127
//The split array must have 18 elements
if (splitBuf.Length.Equals(18))
{
//In normal mode
try
{
time = splitBuf[0];
frontControl = Convert.ToDecimal(splitBuf[2]);
rearControl = Convert.ToDecimal(splitBuf[3]);
frontDisplay = Convert.ToDecimal(splitBuf[4]);
rearDisplay = Convert.ToDecimal(splitBuf[5]);
heaterPower = Convert.ToInt16(splitBuf[6]);
fanTorque = splitBuf[11];
lightData = splitBuf[17];
}
catch (System.InvalidCastException ex)
{
MessageBox.Show(ex.Message,
"Temperature Conversion Error");
}
//Process splitbuf[17], the main to
//terminal board data to display lights
//If line of data has captured all
//relevant data to display then sort and display
if (lightData.Length > 40)
{
// split the log data on each hash
splitBuf = lightData.Split(’#’);
//Read through data enough times
//to obtain all necessary data
for (int i = 1; (setTempDone==0 ||
tempDispDone==0 || alarmLightsDone==0); i++)
{
//Display correct set temp
//mode light colour
if (splitBuf[i].Length == 1)
{
LightColour(splitBuf[i],
setTempModeData, setTempModeLight);
128
//flag as being done
setTempDone=1;
}
//Display temp
if (splitBuf[i].Length == 4)
{
tempData.Text =
splitBuf[i].Substring(0, 2) +
"." + splitBuf[i].Substring(2, 1);
//flag as being done
tempDispDone=1;
}
//Alarm light information
//if (splitBuf[i].Length == 11)
else
{
//Store splitbuf[i] string
//alarmData = GetBytes(splitBuf[i]);
alarmData = splitBuf[i];
//Store splitbuf[i] string in upper case
alarmDataUpper = alarmData.ToUpper();
//Process all char’s in the alarmData array
for (int j = 0; j < alarmData.Length; j++)
{
//If char is upper case
if (alarmData[j].
CompareTo(alarmDataUpper[j]) == 0)
{
//Store byte for transfer to function
colour = Convert.ToString(alarmData[j]);
//Find all lower case char’s
//after it but before next
//upper case byte
for (int k =
j + 1; k < alarmData.Length; k++)
{
//If byte is upper case
if (alarmData[k].
CompareTo(alarmDataUpper[k]) == 0)
{
129
//Exit loop
k = alarmData.Length + 1;
}
//If char is lower case
else if (alarmData[k].
CompareTo(alarmDataUpper[k]) != 0)
{
//Switch for lighting correct alarm lights
switch (alarmData[k])
{
case ’a’:
//Sets the Capsule overheat
//alarm light and text
LightColour(colour, capsuleOverheatData,
capsuleOverheatLight);
break;
case ’p’:
//Sets the capsule power light and text
LightColour(colour, capsulePowerData,
capsulePowerLight);
break;
case ’c’:
//Sets theOperating system
//alarm light and text
LightColour(colour, osData, osLight);
break;
case ’h’:
//Sets the Heater alarm
//light and text
LightColour(colour, heaterData, heaterLight);
break;
case ’s’:
//Sets the Set temp mode
//light and text
LightColour(colour, setTempModeData,
setTempModeLight);
break;
case ’f’:
//Sets the Fan alarm
//light and text
LightColour(colour, fanData, fanLight);
130
break;
}
}
}
}
}
}
//flag as being done
alarmLightsDone = 1;
}
}
//Display textual information
//Display the temperature on the cot
//tempData.Text = lightData.Substring((3 + offset),
2) + "." + lightData.Substring((5 + offset), 1);
//Calculate and display heater power
heaterPowerData.Text =
((heaterLevel(heaterPower) * 25) + ("%"));
//Display fan torque
fanTorqueData.Text = fanTorque;
//Display log time
logTimeData.Text = time;
}
else
{
//In initial or set temp mode
splitBuf = lineOfData.Split(’#’);
//If line of data is big enough to
//process correctly
if (splitBuf.Length > 11)
{
for (int i = (splitBuf.Length - 6); i >
(splitBuf.Length - 11); i--)
{
//Display correct set temp mode light colour
if (splitBuf[i].Length == 1)
{
LightColour(splitBuf[i],
setTempModeData, setTempModeLight);
}
131
//Display set temp
if (splitBuf[i].Length == 4)
{
setTempData.Text =
splitBuf[i].Substring(0, 2) + "." +
splitBuf[i].Substring(2, 1);
tempData.Text = setTempData.Text;
}
}
}
}
}
/********************************************************************
* Function: errorDetected
* Description: Informs the user of the current error and displays relevant
* error information on the virtual Neocot
*
********************************************************************/
private void errorDetected(string lineOfData)
{
string[] splitBuf = null;
string alarmData;
string alarmDataUpper;
string colour;
this.BeginInvoke((ThreadStart)delegate()
{
//Read Error text details
if (lineOfData.StartsWith(" E"))
{
errorData.Text = lineOfData;
}
//Read Error light details
if (lineOfData.StartsWith("#"))
{
try
{
//Split data
splitBuf = lineOfData.Split(’#’);
//Error code displayed on 7 seg display
132
//debug.Text += splitBuf[0] + " & " +
splitBuf[1] + " & " + splitBuf[2] + "\r\n";
tempData.Text = (splitBuf[1].Substring(0, 2) +
"." + splitBuf[1].Substring(2, 1));
//If error log is full display
//888 on virtual cot display
if (pastErrorsData.Text == "20")
{
tempData.Text = "888";
}
//Lights
//Alarm light information
for (int i = 2; i < 4; i++)
{
//Store splitbuf[i] string
alarmData = splitBuf[i];
//Store splitbuf[i] string in upper case
alarmDataUpper = alarmData.ToUpper();
//Process all char’s in the alarmData array
for (int j = 0; j < alarmData.Length; j++)
{
//If char is upper case
if (alarmData[j].
CompareTo(alarmDataUpper[j]) == 0)
{
//Buzzer is sounding
if (alarmData[j] == ’B’)
{
buzzerData.Text = "Buzzer On";
}
//Store byte for transfer to function
colour =
Convert.ToString(alarmData[j]);
//If error log is full,
//turn all lights off
if (pastErrorsData.Text == "20")
{
133
colour = "O";
}
//Find all lower case char’s after
//it but before next upper case byte
for (int k = j + 1;
k < alarmData.Length;
k++)
{
//If char is upper case or a space
if ((alarmData[k].
CompareTo(alarmDataUpper[k]) == 0)
|| (alarmData[k] == ’ ’))
{
//Exit loop
k = alarmData.Length + 1;
}
//If char is lower case
else if (alarmData[k].
CompareTo(alarmDataUpper[k]) != 0)
{
//Switch for lighting
//correct alarm lights
switch (alarmData[k])
{
case ’a’:
//Sets the Capsule
//overheat alarm light
//and text
LightColour(colour,
capsuleOverheatData,
capsuleOverheatLight);
break;
case ’p’:
//Sets the capsule
//power light and text
//as well as the heater
//power light
LightColour(colour,
capsulePowerData,
capsulePowerLight);
LightColour(colour,
134
heaterPowerData,
heaterPower1);
LightColour(colour,
heaterPowerData,
heaterPower2);
LightColour(colour,
heaterPowerData,
heaterPower3);
LightColour(colour,
heaterPowerData,
heaterPower4);
break;
case ’c’:
//Sets the Operating
//system alarm light
//and text
LightColour(colour,
osData, osLight);
break;
case ’h’:
//Sets the Heater
//alarm light and text
LightColour(colour,
heaterData, heaterLight);
break;
case ’s’:
//Sets the Set temp
//mode light and text
LightColour(colour,
setTempModeData,
setTempModeLight);
break;
case ’f’:
//Sets the Fan
//alarm light and text
LightColour(colour,
fanData, fanLight);
break;
}
}
}
135
}}
}
//If error log is full, set Operating
// System light to red
if (pastErrorsData.Text == "20")
{
LightColour("R", osData, osLight);
}
//Exit error mode
errorMode = false;
}
catch (System.Exception ex)
{
MessageBox.Show(ex.Message);
}
}
});
}
/********************************************************************
* Function: heaterLevel
* Description: checks the heater levels and sets the lights
*
********************************************************************/
private int heaterLevel(int heaterPower)
{
int[] hl = new int[5] { 0, 0, 662, 1323, 1984 };
for (int i = 4; i > 0; i--)
{
//Fulle heater power, all 4 bars
if(i == 4)
{
heaterPower1.BackColor = Color.FromArgb(0, 255, 0);
heaterPower2.BackColor = Color.FromArgb(0, 255, 0);
heaterPower3.BackColor = Color.FromArgb(0, 255, 0);
heaterPower4.BackColor = Color.FromArgb(0, 255, 0);
}
//Three bars of heater power
if (i == 3)
136
{heaterPower1.BackColor = Color.FromArgb(0, 255, 0);
heaterPower2.BackColor = Color.FromArgb(0, 255, 0);
heaterPower3.BackColor = Color.FromArgb(0, 255, 0);
heaterPower4.BackColor = Color.FromArgb(0, 0, 0);
}
//Two bars of heater power
if (i == 2)
{
heaterPower1.BackColor = Color.FromArgb(0, 255, 0);
heaterPower2.BackColor = Color.FromArgb(0, 255, 0);
heaterPower3.BackColor = Color.FromArgb(0, 0, 0);
heaterPower4.BackColor = Color.FromArgb(0, 0, 0);
}
//One bar of heater power
if (i == 1)
{
heaterPower1.BackColor = Color.FromArgb(0, 255, 0);
heaterPower2.BackColor = Color.FromArgb(0, 0, 0);
heaterPower3.BackColor = Color.FromArgb(0, 0, 0);
heaterPower4.BackColor = Color.FromArgb(0, 0, 0);
}
//Return heater level to dsplay text
if (heaterPower > hl[i]) return (i);
}
//No heater power, all lights off
heaterPower1.BackColor = Color.FromArgb(0, 0, 0);
heaterPower2.BackColor = Color.FromArgb(0, 0, 0);
heaterPower3.BackColor = Color.FromArgb(0, 0, 0);
heaterPower4.BackColor = Color.FromArgb(0, 0, 0);
return(0);
}
/********************************************************************
* Function: Light Colour
* Description: Changes the light colour of input label based
* on the input string
*
********************************************************************/
private void LightColour(string colour,
Label textbox, PictureBox picbox)
137
{if (colour == "O")
{
textbox.Text = "Off";
picbox.BackColor = Color.FromArgb(0, 0, 0);
}
else if (colour == "G")
{
textbox.Text = "Green";
picbox.BackColor = Color.FromArgb(0, 255, 0);
}
else if (colour == "R")
{
textbox.Text = "Red";
picbox.BackColor = Color.FromArgb(255, 0, 0);
}
}
/********************************************************************
* Function: GetBytes
* Description: Convert string into bytes
*
********************************************************************/
public static byte[] GetBytes(string text)
{
return ASCIIEncoding.UTF8.GetBytes(text);
}
/********************************************************************
* Function: createLog
* Description: Creates the proper log filename as well as creating the
* actual log file.
********************************************************************/
public void createLog(string serialnumber)
{
//create stream writer with current date
logFilename = "Neocot " + DateTime.Now + ".txt";
logFilename = logFilename.Replace(’:’, ’-’);
logFilename = logFilename.Replace(’/’, ’-’);
logFilename = serialnumber + " - " + logFilename;
//currentLog.Text = logFilename;
138
//finishedLog.Text = logFilename;
//Create log file
try
{
logFile = new StreamWriter(Application.StartupPath
+ "\\Logs2\\" + logFilename);
logFile.WriteLine("Neocot Diagnostics "
+ " - " + logFilename);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message,
"Neocot Diagnostics E07");
}
//Log filename visible
//currentLog.Visible = true;
}
/********************************************************************
* Function: resetVirtualCot
* Description: Resets all the variables of the virtual Neocot
********************************************************************/
public void resetVirtualCot()
{
//Resert initial header variables
pastErrorsData.Text = "0";
checksumData.Text = "0";
softwareBuildData.Text = "0";
//Reset temp display and set values
tempData.Text = "0.00";
setTempData.Text = "0";
//Reset error data line and fan torque
errorData.Text = "None";
fanTorqueData.Text = "0";
//Rest heater power level lights and text
heaterPowerData.Text = "0";
heaterPower1.BackColor = Color.FromArgb(0, 0, 0);
heaterPower2.BackColor = Color.FromArgb(0, 0, 0);
heaterPower3.BackColor = Color.FromArgb(0, 0, 0);
heaterPower4.BackColor = Color.FromArgb(0, 0, 0);
139
//Reset alarm lights and text
osData.Text = "Off";
osLight.BackColor = Color.FromArgb(0, 0, 0);
heaterData.Text = "Off";
heaterLight.BackColor = Color.FromArgb(0, 0, 0);
fanData.Text = "Off";
fanLight.BackColor = Color.FromArgb(0, 0, 0);
capsuleOverheatData.Text = "Off";
capsuleOverheatLight.BackColor =
Color.FromArgb(0, 0, 0);
setTempModeData.Text = "Off";
setTempModeLight.BackColor =
Color.FromArgb(0, 0, 0);
capsulePowerData.Text = "Off";
capsulePowerLight.BackColor =
Color.FromArgb(0, 0, 0);
//Reset Buzzer
buzzerData.Text = "Buzzer Off";
//Reset log time and data
logTimeData.Text = "0";
//currentLog.Text = "xxx";
}
/********************************************************************
* Function: startServer_Click
* Description: Controls what happens when
* ’Start Listening’ button is clicked
*
********************************************************************/
private void startServer_Click(object sender, EventArgs e)
{
//Clear the status display
//text box on the textual information tab
statusDisplay.Text = "";
//Disable the button
begin.Enabled = false;
begin.Text = "Listening...";
//Change to virtual Neocot tab
tabControl1.SelectedTab = tabPage3;
140
//Start listening socket
StartListening();
//Thread thread =
new Thread(new ThreadStart(RunServer));
//thread.Start();
//RunServer(certificate);
}
/********************************************************************
* Function: currentLog_Click
* Description: Opens log file while it is still logging
*
********************************************************************/
private void currentLog_Click(object sender, EventArgs e)
{
//Flush the buffer to have the latest information
logFile.Flush();
//Attempt to open the log file
try
{
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.FileName =
(Application.StartupPath + "\\logs2\\" + logFilename);
//startInfo.CreateNoWindow = true;
//startInfo.WindowStyle = ProcessWindowStyle.Hidden;
Process.Start(startInfo);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message,
"Neoct Diagnostics Errors NUMBER");
}
}
/********************************************************************
* Function: finishedLog_Click
* Description: Opens log file after logging procedure has finished
*
141
********************************************************************/
private void finishedLog_Click_1(object sender, EventArgs e)
{
//Flush the buffer to have the latest information
//logFile.Flush();
//Attempt to open the log file
try
{
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.FileName =
(Application.StartupPath + "\\logs2\\" + logFilename);
//startInfo.CreateNoWindow = true;
//startInfo.WindowStyle = ProcessWindowStyle.Hidden;
Process.Start(startInfo);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message,
"Neoct Diagnostics Errors NUMBER");
}
}
/********************************************************************
* Function: finish_Click
* Description: Allows for new connection to be established
*
********************************************************************/
private void finish_Click_1(object sender, EventArgs e)
{
//Re-enable the connection button and texta
begin.Enabled = true;
begin.Text = "Start Listening";
beginPanel.Visible = true;
//reset variables
resetVirtualCot();
//Disable the visibility of the
//end connection button and texts
finishedCover.Visible = true;
}
}
142
}143
Appendix E
Neocot Diagnostics Code
//---------------------------------------------------------------
//Name: Bluetooth Appllication
//Author: Lane Steffensen
//Compleation Date: October 2008
//Property of Mansell Neonatal Transport Equipment Pty. Ltd.
//Add classes
using System;
using System.Collections;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.IO.Ports;
using System.IO;
using System.Reflection;
using System.Net.Mail; //email
using System.Text.RegularExpressions;
using System.Threading; //threads
using System.Diagnostics; //open exe
using System.Net; //sockets
using System.Net.Sockets;
using System.Security.Authentication;
using System.Security.Cryptography.X509Certificates;
using System.Net.Security;
144
//-------------------------------
//Neocot diagnostics Application
//-------------------------------
namespace Neocot_Diagnostics_PC
{
public partial class Form1 : Form
{
//-----------------------------------
// setup some global variables
//-----------------------------------
// This delegate enables asynchronous calls for setting
// the text property on a TextBox control.
delegate void SetTextCallback(string text);
int currentTab; //current tab displayed
bool allowSwitch = false; //is tab switch allowed?
//header variables
decimal calDisp; //calibration display
decimal calCont; //calobration constatn
string checkSum; //check sum
//Emailing variables
//string body; // body of the email
//mode of operation variables
bool headerRead = false; //determines if
//header has been read yet
bool errorMode = false; //Set when error detected
//log file variables
string logFilename; //Name of the log file
StreamWriter logFile; //Stream writer
//for data entry
//SSL stream variables
TcpClient client;
SslStream sslStream;
145
//------------------
// Form1 Namespace (Neocot Diagnostics)
public Form1()
{
InitializeComponent();
}
/********************************************************************
* Function: SSL FUNCTIONS
* Description: TO BE DONE
*
********************************************************************/
private Hashtable certificateErrors = new Hashtable();
// The following method is invoked by the
//RemoteCertificateValidationDelegate.
public bool ValidateServerCertificate(
object sender,
X509Certificate certificate,
X509Chain chain,
SslPolicyErrors sslPolicyErrors)
{
if (sslPolicyErrors == SslPolicyErrors.None)
return true;
//statusDisplay.Text += ("Certificate error: "
+ sslPolicyErrors);
//Console.WriteLine("Certificate error: {0}",
sslPolicyErrors);
// Do not allow this client to communicate
//with unauthenticated servers.
return false;
//return true;
}
public void RunClient(string machineName, string serverName)
{
// Establish the remote endpoint for the socket.
// The name of the
// remote device is "kinast.homeip.net".
//IPHostEntry ipHostInfo =
Dns.Resolve("mattkinast.homeip.net");
146
//IPAddress ipAddress = ipHostInfo.AddressList[0];
//ipAddress = IPAddress.Parse("192.168.0.103");
//IPEndPoint remoteEP = new IPEndPoint(ipAddress, 443);
//Console.WriteLine(ipAddress);
// Create a TCP/IP client socket.
// machineName is the host running the server application.
client = new TcpClient(machineName, 443);
//statusDisplay.Text += ("Client connected.\r\n");
//Console.WriteLine("Client connected.");
// Create an SSL stream that will
//close the client’s stream.
sslStream = new SslStream(
client.GetStream(),
false,
new RemoteCertificateValidationCallback
(ValidateServerCertificate),
null
);
// The server name must match the name
// on the server certificate.
try
{
sslStream.AuthenticateAsClient(serverName);
}
catch (AuthenticationException e)
{
//statusDisplay.Text += ("Exception: " + e.Message);
//Console.WriteLine("Exception: {0}", e.Message);
if (e.InnerException != null)
{
//statusDisplay.Text += ("Inner exception: "
+ e.InnerException.Message);
//Console.WriteLine("Inner exception: {0}",
e.InnerException.Message);
}
//statusDisplay.Text += ("Authentication failed
- closing the connection.");
//Console.WriteLine("Authentication failed -
closing the connection.");
client.Close();
147
return;
}
// Encode a test message into a byte array.
// Signal the end of the message using the "".
//byte[] message =
Encoding.UTF8.GetBytes("Connection Established. \r\n");
// Send hello message to the server.
//sslStream.Write(message);
//statusDisplay.Text += ("Message Sent\r\n");
//sslStream.Flush();
SendData();
// Read message from the server.
//string serverMessage = ReadMessage(sslStream);
//Console.WriteLine("Server says: {0}", serverMessage);
// Close the client connection.
//client.Close();
//statusDisplay.Text += ("Client closed.\r\n");
//Console.WriteLine("Client closed.");
}
/*
static string ReadMessage(SslStream sslStream)
{
// Read the message sent by the server.
// The end of the message is signaled using the
// "" marker.
byte[] buffer = new byte[2048];
StringBuilder messageData = new StringBuilder();
int bytes = -1;
do
{
bytes = sslStream.Read(buffer, 0, buffer.Length);
// Use Decoder class to convert from bytes to UTF8
// in case a character spans two buffers.
148
Decoder decoder = Encoding.UTF8.GetDecoder();
char[] chars =
new char[decoder.GetCharCount(buffer, 0, bytes)];
decoder.GetChars(buffer, 0, bytes, chars, 0);
messageData.Append(chars);
// Check for EOF.
if (messageData.ToString().IndexOf("") != -1)
{
break;
}
} while (bytes != 0);
return messageData.ToString();
}
private void DisplayUsage()
{
Environment.Exit(1);
}
*/
//------------------------------------
//User Alerts, input flow control
//------------------------------------
/* Name: buttonSetup_Click
* Inputs: event
* Outputs: none
* Called By: none
* Calls: none
* Description: creates the comunications socket
* and opens the BluetoothAPI program.
* */
private void buttonSetup_Click(object sender,
EventArgs e)
{
//switch to the next TAB
allowSwitch = true;
tabControl1.SelectedTab = tabPage2;
149
//create the server socket within a new thread
StartListening();
//create stream writer with current date
logFilename = "Neocot " + DateTime.Now + ".txt";
logFilename = logFilename.Replace(’:’, ’-’);
logFilename = logFilename.Replace(’/’, ’-’);
logFilename = textBox6.Text + " - " + logFilename;
label24.Text = "Log File: " + logFilename;
try
{
logFile = new StreamWriter
(Application.StartupPath +
"\\Logs\\" + logFilename);
logFile.WriteLine("Neocot Diagnostics "
+ " - " + logFilename);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message,
"Neocot Diagnostics E07");
}
//call the client Application
try
{
ProcessStartInfo startInfo =
new ProcessStartInfo();
//startInfo.WorkingDirectory =
Application.StartupPath;
startInfo.FileName =
(Application.StartupPath + "\\BluetoothAPI.exe");
//startInfo.CreateNoWindow = true;
startInfo.WindowStyle =
ProcessWindowStyle.Minimized;
Process.Start(startInfo);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message,
"Neoct Diagnostics Errors EBA");
}
150
}/* Name: buttonContinue_Click
* Inputs: event
* Outputs: none
* Called By: none
* Calls: none
* Description: Ends the logging procedure and restarts program.
* */
private void button4_Click(object sender, EventArgs e)
{
//Stop logging procedure
if (MessageBox.Show("This will end the
logging procedure, proceed?", "Neocot Diagnostics",
MessageBoxButtons.YesNo, MessageBoxIcon.Warning)
== DialogResult.Yes)
{
//Send end of transmission character
string szData = "EOF";
byte[] byData = GetBytes(szData);
//byte[] message =
Encoding.UTF8.GetBytes
("Connection Established. \r\n");
// Send EOF message to the server.
//sslStream.Write(byData);
//sslStream.Flush();
clientSocket.Send(byData);
//Application.Exit();
//Thread.Sleep(5000);
//clientSocket.Disconnect(true);
clientSocket.Close();
//client.Close();
allowSwitch = true;
tabControl1.SelectedTab = tabPage4;
151
//Close the client application, friendlier?
Process[] pArray = Process.GetProcesses();
foreach (Process p in pArray)
{
if (p.ProcessName.CompareTo
("BluetoothAPI") == 0)
{
p.Kill();
}
}
//Flush out buffer to log file
logFile.Flush();
//stop writing to the logfile and close it
logFile.Close();
//Move to the next page
/*
//Email or view data file option
if (MessageBox.Show("Would you like to
email diagnostics data to MNTE?",
"Neocot Diagnostics",
MessageBoxButtons.YesNo, MessageBoxIcon.Question)
== DialogResult.Yes)
{
//email the data
allowSwitch = true;
tabControl1.SelectTab(tabPage5);
}
else
{
allowSwitch = true;
tabControl1.SelectTab(tabPage6);
//Attempt to open the log file
try
{
ProcessStartInfo startInfo =
new ProcessStartInfo();
startInfo.FileName =
(Application.StartupPath + "\\logs\\"
+ logFilename);
152
//startInfo.CreateNoWindow = true;
//startInfo.WindowStyle =
rocessWindowStyle.Hidden;
Process.Start(startInfo);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message,
"Neoct Diagnostics Errors NUMBER");
}
} */
}
}
//The about pannel, accessable through the menu bar.
private void panel2_Click(object sender, EventArgs e)
{
//Make the panel go away when you click it
panelAbout.Visible = false;
}
private void menuItem2_Click(object sender, EventArgs e)
{
//display the about button
panelAbout.Visible = true;
}
private void label26_Click(object sender, EventArgs e)
{
//exit the about panel
panelAbout.Visible = false;
}
/* Name: Form1_FormClosing
* Inputs: event (button click)
* Outputs: none
* Called By: none
* Calls: none
153
* Description: Makes sure the program cleans up before closing
* */
private void Form1_FormClosing(object sender,
FormClosingEventArgs e)
{
//Ensure BluetoothAPI porgram is closed
foreach (Process p in Process.GetProcesses())
{
if (p.ProcessName.CompareTo("BluetoothAPI") == 0)
{
p.Kill();
}
}
/*
Close the Text File is still open
if (!logFile.Equals(null))
{
logFile.Close();
}
*/
}
//Exit button
private void menuItem3_Click(object sender, EventArgs e)
{
//Send end of transmission character
string szData = "EOF";
byte[] byData = GetBytes(szData);
//sslStream.Write(byData);
//sslStream.Flush();
clientSocket.Send(byData);
//Exit application
//Thread.Sleep(1000);
//client.Close();
clientSocket.Close();
Application.Exit();
}
//restart Application
private void menuItem4_Click(object sender, EventArgs e)
154
{// Display a message box asking users if they
// want to restart the application.
if (MessageBox.Show("Do you want to Restart?
All data will be lost.", "Neocot Diagnostics",
MessageBoxButtons.YesNo, MessageBoxIcon.Exclamation)
== DialogResult.Yes)
{
Application.Restart();
}
}
//opening log file
private void label24_Click(object sender, EventArgs e)
{
//Flush the buffer to have the latest information
logFile.Flush();
//Attempt to open the log file
try
{
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.FileName =
(Application.StartupPath + "\\logs\\" + logFilename);
//startInfo.CreateNoWindow = true;
//startInfo.WindowStyle = ProcessWindowStyle.Hidden;
Process.Start(startInfo);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message,
"Neoct Diagnostics Errors NUMBER");
}
}
//Controlling the flow of tabs
private void tabControl1_Selecting(object sender,
TabControlCancelEventArgs e)
{
// cancel the transition and check if it is allowed
e.Cancel = true;
155
//allow moving to the next tab
//(doesn’t allow for error messages)
//************************PUT IN
//*********************************//
//if ((e.TabPageIndex - currentTab) == 1)
{
//allows you to go bask from page 2 to
//1 and go forward
if ((allowSwitch == true) ||
(((currentTab - e.TabPageIndex) == 1) &&
(currentTab == 2)))
e.Cancel = false;
}
}
private void tabControl1_Selected(object sender,
TabControlEventArgs e)
{
currentTab = tabControl1.SelectedIndex;
allowSwitch = false;
}
private void button5_Click(object sender, EventArgs e)
{
allowSwitch = true;
}
private void button6_Click(object sender, EventArgs e)
{
//Open connection to MNTE Server
StartClient();
//check the file suffix is correct
if (textBox6.Text.IndexOfAny
(System.IO.Path.GetInvalidFileNameChars()) != -1)
{
MessageBox.Show("File name contains
illegal characters", "Neocot Diagnostics E21");
return;
}
if (clientSocket.Connected)
{
156
allowSwitch = true;
tabControl1.SelectedTab = tabPage1;
}
//Start the MNTE client socket
//StartClient();
//string serverCertificateName = "matt";
//string machineName = "127.0.0.1";
//RunClient(machineName, serverCertificateName);
}
//scroll the read data status
//window to new information
private void labelNewLine_TextChanged
(object sender, EventArgs e)
{
labelNewLine.SelectionStart =
labelNewLine.Text.Length;
labelNewLine.ScrollToCaret();
}
//---------------------
//Socket Thread
//---------------------
//Socket packet class
public class CSocketPacket
{
public System.Net.Sockets.Socket thisSocket;
public byte[] dataBuffer = new byte[10];
}
//Global variable for this thread/Class
public AsyncCallback pfnWorkerCallBack;
public Socket serverSocket;
public Socket clientSocket;
public Socket serverWorker;
/* Name: StartListening
* Inputs: none
157
* Outputs: none
* Called By: button setup_click
* Calls: none
* Description: creates new listener socket serverSocket
* */
public void StartListening()
{
try
{
//create listening socket
serverSocket = new
Socket(AddressFamily.InterNetwork,
SocketType.Stream, ProtocolType.Tcp);
//local IP endpoint
IPEndPoint ipLocal =
new IPEndPoint(IPAddress.Parse("127.0.0.1"), 40123);
//bind socket to local IP address
serverSocket.Bind(ipLocal);
//start listening for connections
serverSocket.Listen(4);
//create callback for client connections
serverSocket.BeginAccept
(new AsyncCallback(OnClientConnect), null);
}
catch (SocketException ex)
{
MessageBox.Show(ex.Message);
}
}
/* Name: OnClientConnect
* Inputs: event
* Outputs: none
* Called By: none
* Calls: waitForData
* Description: runs when the client connects to the server socket.
* */
public void OnClientConnect(IAsyncResult asyn)
{
try
158
{serverWorker = serverSocket.EndAccept(asyn);
waitForData(serverWorker);
}
catch (ObjectDisposedException)
{
System.Diagnostics.Debugger.Log(0, "1", "\n On
Client Connection: Socket has been closed\n");
}
catch (SocketException ex)
{
MessageBox.Show(ex.Message);
}
}
/* Name: waitForData
* Inputs: event
* Outputs: none
* Called By: none
* Calls: none
* Description: Ends the logging procedure and
* continues to the emailing of data.
* */
public void waitForData(System.Net.Sockets.
Socket serverWorker)
{
try
{
if (pfnWorkerCallBack == null)
{
pfnWorkerCallBack = new AsyncCallback(OnDataReceived);
}
//Create packet to recieve data in
CSocketPacket theSocPkt = new CSocketPacket();
theSocPkt.thisSocket = serverWorker;
//Recieve data into the packet
serverWorker.BeginReceive(theSocPkt.dataBuffer, 0,
theSocPkt.dataBuffer.Length, SocketFlags.None,
pfnWorkerCallBack, theSocPkt);
}
catch (SocketException ex)
159
{MessageBox.Show(ex.Message);
}
}
/* Name: OnDataReceived
* Inputs: event
* Outputs: none
* Called By: none
* Calls: processBufferData, waitForData
* Description: accepts imported diagnostics information,
* */
public void OnDataReceived(IAsyncResult asyn)
{
try
{
CSocketPacket theSockId =
(CSocketPacket)asyn.AsyncState;
int iRx = 0; //initialise read bytes counter
//no of recieved bytes
iRx = theSockId.thisSocket.EndReceive(asyn);
//create initial character array
char[] chars = new char[iRx];
//decode text
System.Text.Decoder d =
System.Text.Encoding.UTF8.GetDecoder();
int charLen =
d.GetChars(theSockId.dataBuffer, 0, iRx, chars, 0);
//put data into string
System.String szData = new System.String(chars);
//process the data recieved
processBufferData(szData);
Thread.Sleep(0);
waitForData(serverWorker);
}
catch (ObjectDisposedException)
{
System.Diagnostics.Debugger.Log(0, "1", "\n On
Client Connection: Socket has been closed\n");
160
}catch (SocketException ex)
{
//if (szData == "EOF")
//{
//}
MessageBox.Show(ex.Message + "\r\nIf you
are seeing this after finishing the logging
procedure \r\nplease continue without concern.");
}
}
//---------------------
//Client Socket
//---------------------
public void StartClient()
{
try
{
clientSocket = new Socket(AddressFamily.InterNetwork,
SocketType.Stream, ProtocolType.Tcp);
// Establish the remote endpoint for the socket.
// The name of the
//Remote device is "mattkinast.homeip.net".
IPHostEntry ipHostInfo = Dns.Resolve("mattkinast.homeip.net");
IPAddress ipAddress = ipHostInfo.AddressList[0];
IPEndPoint remoteEP = new IPEndPoint(ipAddress, 443);
statusDisplay.Text += ipAddress;
//Remote IP endpoint
//IPEndPoint remoteEP =
new IPEndPoint(IPAddress.Parse("127.0.0.1"), 443);
//Connect to remote endpoint
clientSocket.Connect(remoteEP);
statusDisplay.Text += ("Establishing connection...\r\n");
}
catch (SocketException ex)
{
MessageBox.Show(ex.Message);
161
//statusDisplay.Text = (ex.Message);
}
SendData();
}
public void SendData()
{
try
{
//Data for log file name (Neocot serial number)
String szData = "Log Filename: " + textBox6.Text;
byte[] byData = GetBytes(szData);
clientSocket.Send(byData);
//sslStream.Write(message,0, message.Length);
statusDisplay.Text += ("Message Sent\r\n");
//sslStream.Flush();
//Data for client machine details to send
//szData = "\r\nConnection Established";
//byData =
System.Text.Encoding.ASCII.GetBytes(szData);
//clientSocket.Send(byData);
//szData = " with Myself";
//byData =
System.Text.Encoding.ASCII.GetBytes(szData);
//clientSocket.Send(byData);
}
catch (SocketException se)
{
//statusDisplay.Text = (se.Message);
MessageBox.Show(se.Message + "\r\nCould
not connect to MNTE Server. Please contact
MNTE and try again.");
}
}
//Convert string into bytes for sending string over socket
public static byte[] GetBytes(string text)
{
return ASCIIEncoding.UTF8.GetBytes(text);
162
}/* Name: processBufferData
* Inputs: the diagnostics data buf
* Outputs: none
* Called By: OnDataRecieve
* Calls: splitAndDisplay, readHeader, errorDetected.
* Description: Checks to see if there is a full
* line of data nad if there is displays it appropriately
* */
private void processBufferData(string newData)
{
//initialise variables
int i = 0; //counter variable
//Information contained within the databuffer
string bufData = "";
// The most recent line of data
string lineOfData = "";
//array of strings each containing individual
//lines of buffer data
string[] bufLines = null;
//byte[] byData = GetBytes(newData);
//clientSocket.Send(byData);
//Setup available data
this.BeginInvoke((ThreadStart)delegate()
{
//Add in new data
labelBuf.Text += newData;
//Bring data in to be processed
bufData = labelBuf.Text;
//label7.Text = bufData.Length.ToString();
});
//-------------------
//Process bufData
//-------------------
163
//seperate the input into lines
bufLines = bufData.Split(new char[] { ’\n’, ’\r’ } ,
StringSplitOptions.None);
//there are new lines of data preasent
if (bufLines.Length >= 2)
{
//write the uncomplete line into the buffer
this.BeginInvoke((ThreadStart)delegate()
{
//Left over data (not a complete line)
labelBuf.Text = bufLines[bufLines.Length - 1];
});
//process the data lines
for (i = 0; i <= bufLines.Length - 2; i++)
{
//New line of data
lineOfData = bufLines[i];
//write the data to the log file and ssl stream
try
{
//statusDisplay.Text += ("Sending Data...\r\n");
byte[] byData = GetBytes(lineOfData);
//sslStream.Write(byData);
clientSocket.Send(byData);
logFile.WriteLine(lineOfData);
}
catch (System.Exception ex)
{
MessageBox.Show("Writing data to file error "
+ ex.Message, "Neocot Diagnostics E01");
}
//--------------------------
//Process the Line of data
//--------------------------
//Bluetooth Application information
if (lineOfData.StartsWith("->"))
{
164
this.BeginInvoke((ThreadStart)delegate()
{
//display for the user
this.labelNewLine.Text =
this.labelNewLine.Text + Environment.NewLine
+ lineOfData;
});
//Setup is complete turn on the cot
if (lineOfData.StartsWith("->
Bluetooth socket connected"))
{
this.BeginInvoke((ThreadStart)delegate()
{
//Display panel
this.panelTurnOnCot.Visible = true;
});
}
//Could not find a NBDM
if (lineOfData.StartsWith("-> Unable"))
{
this.BeginInvoke((ThreadStart)delegate()
{
//Display panel
label7.Text = "Please Restart";
});
}
}
//Has there been an error, enter error mode
if (lineOfData.StartsWith(" error count") ||
(errorMode.Equals(true)))
{
errorMode = true; //enable error mode
//jump to the routine that handles errors
errorDetected(lineOfData);
}
165
else //There is Readable data in the buffer
{
//chech for header data
if ((!headerRead) &&
(lineOfData.StartsWith(" ")))
{
readHeader(lineOfData);
}
//Check for body information
//data must be at least 102 long,
//and less than 200.
else if (lineOfData.Length >= 102
&& lineOfData.Length < 200)
{
//Jumps to the routine that
//cuts up the buffer information
splitAndDisplay(lineOfData);
}
}
}
}
Thread.Sleep(0); //sleep for a
//bit give the thread time to compleat
}
/* Name: tempMix
* Inputs: Front rear and offset sensor values
* Outputs: The correct mixed temperature
* Called By: None
* Calls: None
* Description: Calculate the displayed temperature of the cot
* */
private decimal tempMix(decimal front,
decimal rear, decimal offset)
{
decimal mixed = 0;
try //mix the sensors using the following algorithm
166
{mixed = ((((front / 4) * 7) +
((rear / 4) * 3)) / 10 * 4 + offset);
}
catch (InvalidCastException)
{
//button1.Text = "Decimal error!";
}
catch (System.Exception)
{
//button1.Text =
"Error calculating mix tempuratures";
}
return mixed;
}
/* Name: Read Header
* Inputs: Line of diagnostics data
* Outputs: Header data written to screen
* Called By: processBufferData
* Calls: None
* Description: process all header information
* */
public void readHeader(string lineOfData)
{
this.BeginInvoke((ThreadStart)delegate()
{
//switch to the data display tab
if (tabControl1.SelectedTab == tabPage2)
{
//switch to display tab
allowSwitch = true;
tabControl1.SelectedTab = tabPage3;
labelStatus.Text =
"Reading and Transmitting
Header Data...";
}
if (lineOfData.Length > 21) //make sure
//the line of data is long enough to read
{
167
try //search for important data
{
switch (lineOfData.Substring(0, 20))
{
case " no. of past errors ":
//gets the no of past errors
previousErrors.Text =
lineOfData.Substring
(lineOfData.Length - 2, 2);
break;
case " Calibration data ch":
//get the calibration
//ok, bad string
checkSum =
lineOfData.Substring
(lineOfData.Length - 3, 3);
break;
case " Calibration data, C":
//gets the calibration data
calCont = Convert.ToDecimal
(lineOfData.Substring(29, 6));
calDisp = Convert.ToDecimal
(lineOfData.Substring(47, 6));
break;
case " Neocot Main Software":
//gets the software build
softwareBuild.Text =
lineOfData.Substring
(lineOfData.Length - 5, 5);
break;
case " System functioning ":
//the header is read
//disable furtuhr header
//reading
headerRead =
true; //disable the
//reading of the header
labelStatus.Text =
"Reading and Transmitting
Body Data";
break;
168
}}
catch (System.FormatException)
{
//dissable the system
MessageBox.Show("Header Data Corrupt,
Please Restart Application",
"Neocot Diagnostices");
}
catch (System.Exception ex)
{
MessageBox.Show("Testing ERROR " +
ex.Message, "Neocot Diagnostics E02");
}
}
});
}
/* Name: errorDetected
* Inputs: line of diagnostics data
* Outputs: Error reported on screen
* Called By: processBufferData
* Calls: None
* Description: Informs the user of the current error
* */
private void errorDetected(string lineOfData)
{
this.BeginInvoke((ThreadStart)delegate()
{
//if we are not on tab 4 put it on tab 4
if (tabControl1.SelectedIndex != 4)
{
allowSwitch = true;
tabControl1.SelectedTab = tabPage3;
}
//Display the error on screen
label17.Text = "Cot Error";
buttonContinue.Text = "Please Wait";
buttonContinue.BackColor =
169
Color.FromArgb(255, 192, 192);
// this is the line that exports the error
// make this more of hte line
if (lineOfData.StartsWith(" E"))
{
labelStatus.Text = "Error Detected:" +
Environment.NewLine +
Environment.NewLine + lineOfData;
}
//End the client
buttonContinue.Text = "Finish";
buttonContinue.BackColor =
Color.FromArgb(192, 255, 192);
label17.Text = "Error";
});
}
/* Name: splitAndDisplay
* Inputs: line of diagnostics data
* Outputs: Appropriate header data displayed on screen
* Called By: processBufferData
* Calls: None
* Description: Splits buffer data and displays certain values to the user
* */
private void splitAndDisplay(string lineOfData)
{
string[] splitBuf = null; // array of strings of diag data
try
{ // split the log data on each comma
splitBuf = lineOfData.Split(’,’);
//The split array must have 18 elements
if (splitBuf.Length.Equals(18))
{
this.BeginInvoke((ThreadStart)delegate()
{
//process log time
label10.Text = splitBuf[0];
170
if (Convert.ToInt32(splitBuf[0]) > 3600)
{//when a hour is logged recomend the user continues
labelStatus.Text =
"1 hour of data has been logged, please finish";
buttonContinue.BackColor =
Color.FromArgb(192, 255, 192);
}
else
{
//update the progress bar
progressBar2.Value =
Convert.ToInt32(splitBuf[0]);
}
});
//Process Temperatures and call mixTemp
decimal frontControl = 0M, rearControl = 0M;
decimal frontDisplay = 0M, rearDisplay = 0M;
try
{
frontControl = Convert.ToDecimal(splitBuf[2]);
rearControl = Convert.ToDecimal(splitBuf[3]);
frontDisplay = Convert.ToDecimal(splitBuf[4]);
rearDisplay = Convert.ToDecimal(splitBuf[5]);
}
catch (System.InvalidCastException ex)
{
MessageBox.Show(ex.Message,
"Temperature Conversion Error");
}
}
}
catch (System.Exception ex)
{
MessageBox.Show("Error Splitting Data: " + ex.Message,
"Neocot Diagnostics E0X");
}
}
/********************************************************************
* Function: SetText
171
* Description: This method is passed in to the SetTextCallBack delegate
* to set the Text property of statusDisplay.
*
********************************************************************/
private void SetText(string text)
{
this.statusDisplay.Text += text;
}
private void closeApp_Click(object sender, EventArgs e)
{
//End application procedure
//clientSocket.Close();
//Thread.Sleep(1000);
Application.Exit();
}
private void clientstart_Click_1(object sender, EventArgs e)
{
//Start the MNTE client socket
StartClient();
}
//No More Functions
}
}
172
Appendix F
Neocot Diagnostics Log Output
Neocot Diagnostics - MNTE-000-000 - Neocot 30-09-2009 4-35-02 PM.txt
All DATA:-> Socket Open
-> Winsock Initialised
-> Connected to control Application
-> ## Starting Radio Search ##
-> First device discovered
-> Getting radio information
-> All radios discovered
-> ## Starting Device Search ##
-> -- Attempt 1 of 4 --
-> Bluetooth devices found
-> Getting device information
-> Name: MNTE-NBDM-02
-> ULL Address: 2500186325
-> ## Reauthenticating ##
-> -- Attempt 1 of 4 --
-> Bluetooth devices found
-> Getting device information
-> Name: MNTE-NBDM-02
-> ULL Address: 2500186325
-> ## Connecting to NBMD ##
-> Bluetooth socket connected
---------------
STARTUP
173
no. of past errors recorded = 05
Normal operating mode
Calibration data protected
Calibration data checksum OK
Calibration data, CONTROL = 00.734,
DISPLAY = 00.843 00bc,00d8,5531
Neocot Main Software Build 131 Q
Mansell Neonatal Transport Equipment Pty. Ltd.
Caring for delicate lives.
Starting ... #:::4YsapcfhB
Self-Test - lights on ...
checking bus heater air external
heater air external heater
air external ... done
checking for presence of sensors ...
External Temp sensor A NOT connected
External Temp sensor B NOT connected
External Temp sensor C NOT connected
External Temp sensor D NOT connected
External Temp sensor E NOT connected
External Temp sensor F NOT connected
starting conversions ... 1631 at no 00 1631
at no 01 1631 at no 02 1631 at no 03 1631
at no 04 1631 at no 05 1631 at no 06 1631
at no 07 1631 at no 08 done
checking controlF sensor config ... 1631 at no 04 done
checking controlR sensor config ... 1631 at no 07 done
checking displayF sensor config ... 1631 at no 05 done
checking displayR sensor config ... 1631 at no 08 done
checking thermostatF sensor config ... 1631 at no 06 done
checking thermostatF sensor settings ...
TH = 39.0 ... TL = 39.5 ... done
checking heater 1 sensor config ... 1631 at no 00 done
checking heater 2 sensor config ... 1631 at no 01 done
checking heater 3 sensor config ... 1631 at no 02 done
174
checking heater 4 sensor config ... 1631 at no 03 done
lights off ... #;;;0Osapcfhb
about to start
waiting till sensors get initial results ...
CF DF CR DR H1234 done
about to enable interrupts ...
interrupts enabled
System functioning #G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb
#G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb
#G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb
#G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb
#G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb
#G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb
#G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb
#G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb
#G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb
#G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb
#G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb
#G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb
#G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb
#G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb
#G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb #G#3600#GcfGhGaGpb
#G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb
#G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb
#G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb
#G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb
#G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb
#G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb
#G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb
#G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb
#G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb
#G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb
#G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb
#G#3604#GcfGhGaGpb #G#3604#GcfGhGaGpb #O#2714#GcfGhGaGpb
#O#2714
0006, CDHMRAB12S, 25.6,27.6, 25.7,27.5, 1985,28.2,28.6,28.6,29.0,
3813, 0000, 0000, 0000, 57, 59, 0166 #GcfGhGaGpb #O#2714#GcfGhGaGpb
#GcfGhGaGpb #O#2714
0008, CDHMRAB12S, 25.6,27.6, 25.7,27.5, 1985,28.4,28.8,28.7,29.1,
3813, 0000, 0000, 0000, 57, 59, 0166 #GcfGhGaGpb #O#2714#GcfGhGaGpb
#GcfGhGaGpb #O#2714
175
0010, CDHMRAB12S, 25.6,27.6, 25.7,27.5, 1985,28.5,28.9,29.0,29.2,
3801, 0000, 0000, 0000, 57, 59, 0166 #GcfGhGaGpb #O#2714#GcfGhGaGpb
#GcfGhGaGpb
0012, CDHMRAB12S, 25.6,27.6, 25.7,27.5, 1985,28.7,29.0,29.1,29.3,
3807, 0000, 0000, 0000, 57, 59, 0166 #O#2714#GcfGhGaGpb
O#2714#GcfGhGaGpb #GcfGhGaGpb #O#2714
0014, CDHMRAB12S, 25.6,27.6, 25.7,27.5, 1985,29.0,29.3,29.2,29.5,
3801, 0000, 0000, 0000, 57, 59, 0166 #GcfGhGaGpb #O#2714#GcfGhGaGpb
#GcfGhGaGpb #O#2714
0016, CDHMRAB12S, 25.6,27.6, 25.7,27.5, 1985,29.2,29.5,29.5,29.7,
3801, 0000, 0000, 0000, 57, 59, 0166 #GcfGhGaGpb #O#2714#GcfGhGaGpb
#GcfGhGaGpb #O#2714
0018, CDHMRAB12S, 25.6,27.6, 25.7,27.5, 1985,29.5,29.8,29.7,29.8,
3783, 0000, 0000, 0000, 57, 59, 0166 #GcfGhGaGpb #O#2714#GcfGhGaGpb
#GcfGhGaGpb #O#2724
0020, CDHMRAB12S, 25.6,27.6, 25.8,27.5, 1985,29.7,30.0,30.0,30.1,
3789, 0000, 0000, 0000, 57, 59, 0166 #GcfGhGaGpb #GcfGhGaGpb
#O#2724#GcfGhGaGpb #O#2724
0022, CDHMRAB12S, 25.6,27.6, 25.7,27.5, 1985,29.9,30.1,30.1,30.3,
3783, 0000, 0000, 0000, 57, 59, 0166 #GcfGhGaGpb #GcfGhGaGpb
#O#2714#GcfGhGaGpb #O#2724
0024, CDHMRAB12S, 25.6,27.6, 25.8,27.5, 1985,30.2,30.5,30.3,30.5,
3777, 0000, 0000, 0000, 57, 59, 0166 #GcfGhGaGpb #GcfGhGaGpb
#O#2724#GcfGhGaGpb
0026, CDHMRAB12S, 25.6,27.6, 25.8,27.5, 1985,30.4,30.6,30.7,30.6,
3783, 0000, 0000, 0000, 57, 59, 0166 #O#2724#GcfGhGaGpb #GcfGhGaGpb
#O#2724#GcfGhGaGpb #O#2724
0028, CDHMRAB12S, 25.6,27.6, 25.8,27.5, 1985,30.5,31.0,30.8,30.8,
3789, 0000, 0000, 0000, 57, 59, 0166 #GcfGhGaGpb #GcfGhGaGpb
#O#2724#GcfGhGaGpb #O#2714
0030, CDHMRAB12S, 25.6,27.6, 25.7,27.5, 1985,30.9,31.1,31.1,31.1,
3789, 0000, 0000, 0000, 57, 59, 0166 #GcfGhGaGpb #GcfGhGaGpb
#O#2724#GcfGhGaGpb #O#2724
0032, CDHMRAB12S, 25.6,27.6, 25.8,27.5, 1985,31.1,31.3,31.3,31.3,
3777, 0000, 0000, 0000, 57, 59, 0166 #GcfGhGaGpb #GcfGhGaGpb
#O#2724#GcfGhGaGpb #O#2724
0034, CDHMRAB12S, 25.6,27.6, 25.8,27.5, 1985,31.5,31.6,31.5,31.6,
3777, 0000, 0000, 0000, 57, 59, 0166 #GcfGhGaGpb #GcfGhGaGpb
#O#2724#GcfGhGaGpb
error count was 05, and now is 06
176
E09 Fan Motor stalled or overloaded
#E090#OapchsfB#Rf
*** fatal error - system halted ***
SR = 0163, SP = 02c9, CCR = e8, Return = 99ad
177
Appendix G
SSL Certificate Creation
OpenSSL is an open source SSL/TLS toolkit that is available on the Inter-
net for download. This toolkit allows a user to create their own certificate
authority and certificate signing requests. It also allows them to sign cer-
tificate signing requests. Self-signed certificates allow programs that employ
SSL to be able to be used without paying for a certificate signed by a trusted
certificate authority. SSL is employed in this project and software modules
required testing preferably without payment for a professional certificate.
Using a self signed certificate allowed for this testing. The Open SSL toolkit
was used for the creation of the self-signed certificate used in this project. A
compiled version of the OpenSSL toolkit was downloaded from
http://www.stunnel.org/download/stunnel/win32/openssl-0.9.7/
[www.stunnel.org, current September 2009]
The OpenSSL program provides a console environment for the user to
input commands. Below is the process gone through to create a self-signed
certificate in this command prompt environment, including user input and
resulting output. [www.akadia.com, current September 2009]
The first step in certificate creation is to generate a private key. The step
shown below generates a key file called ca.key
OpenSSL> genrsa 2048 -out ca.key
Loading ’screen’ into random state - done
Generating RSA private key, 2048 bit long modulus
...+++
................................................................................
................................................................................
.................+++
e is 65537 (0x10001)
178
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAu923wgwJoQQQOLAUektzIxaDMzZHjLwE2sWob6m5eTMxiY6m
ltPTgey5Br2sOlXXxBn3zHH/nDASFbBwGndy81bj+HAMFL1wscbbmX9rYuREzkQo
F5D2j41RdDqFh/ZC8Y7yVEz62kOfidf/ePG3O5VmY7jd3RyC4TDMLxhydtWEoXEt
gnYT7yG2IfGBheZljkVkHNNHLEZal6jWXnMyXPuKzTXKJXvhEv3op+kvtI6B2NZ9
nGYuWsYsduxYTJ8JcUpXByz8QyGDDDOSmi0pYLzzuJGuDi3yOQqRppghDLlRV55h
zJSQ0ZhTihDq1LWGInxQx/0F3MAHsyZughHXtQIDAQABAoIBAQCZhNasMNARj1N+
L42cXlmpO7VdPSb8/4xsBofdL/IL8+SwRy0lJda6XmrY8lhyl0Gp05qmrCW4SaQN
q1AAoMoDxmam11FYBXK5JArCBdkISAdeE147289Qgagldck20Ovln+2xK/L2N7qA
l00CVWxpuW2hYimTjb/6K7k/ZxfquKnGHMR1KhWzQByey6bfuQzB9FbKynfdAkLF
agDCvp9j62VpVIM/9vSukQFQwYkRZT+fTZeyVPGSUGWbZOAbpzf6sZYfarDe9bLF
81pIeurhZcwYPBdmOIWso08XL0XTKAtB2MKhpCQnolIKMOwkhBZnuFeHh9hzan9Q
XiEiRQxBAoGBAPkIbf8746nJiWjBcrUrevSOrcjsKwFQfbGdq2lVW+mUFjYt8wlU
grRVydq70BMDrhYqVUfx2LvTWNhOT7EI6+saRwieD8J0C+2KuPz+0wLICv7ESLW6
2e37+lKTpOqICo7moGNlOlASNjX8gsoioAF1xaIWbHPMW0bIHK+fgLGxAoGBAMEf
NkmHDG2cYJmYujxqtfOpzreyum8rwndP//y7duywKN9LiX8SpsCsEDL9EXqinHiQ
9mUDiBlPtvs9V090psXvwStURg+lIZLoNUQ+uMbL28L0MrcpRxnkSqzcm5abQUwc
Fl2JN1IYhCCtPPMtV+ya7//xL76Jgg6dcxomcuNFAoGAEfRWoeE6f8JFAuV3lLJG
0hz7UJIeY6De/xBEDHsX/lYr58oWTKToK4JH5FpIHSbVxUlWDrLUEm6haC71NelT
wQaK+ocS0c02EvE+dxcUNY4gpM+YAmovTiYtnQiCClq2kCj2hVQGCUHW4LuM3m/y
o0hPcGk3dn3UUt0YnFzelXECgYB5JzWNZxWa5hGMCk47fM5s8Eho4c0n1RIIe72i
NZDj55ecjezSNUc7dDYtZqnCf6Ud1gNdV5vYFTQ75T2S8SF253QN1K6nPfcUDGzu
RVLyFA3n/f6a/WBHk/ps+3D4SKnsL2qwf1afQBYT0dp8zCNuobySmiJTrDxVIt2E
uD426QKBgHg4ili1HHSrYymu2Uh7xb5Wcv14hG+ICTT0ajz1orPkMIgrD+ovwyqT
JRVPsdXFZ4onOkNY7qwgpYJTVGrEJnmNxWfKxyIgUpQv5iGvgJSTZBRtCtrg2Km/
zsbNLfjUEh0fq62MQ/ZfzdXLqTuCMa8kaqmjYMPBtHmRMii89Q53
-----END RSA PRIVATE KEY-----
[Hausheer, current September 2009]
The next step is to create a certificate signing request, this process uses
the key created in the previous step. This certificate signing request creation
shown below outputs a certificate signing request file called ca.csr. After
this step is completed, the .csr file is usually sent on to a trusted certificate
authority for signing. In this case we sign it ourselves. It should also be noted
that the Common Name(eg. YOUR name) section is asking for the name of
the domain to be protected by SSL. In this case, mattkinast.homeip.net is
used to allow for testing. In the case of creating a .csr file for MNTE to send
to a trusted certificate signing authority, mansell.com.au would be used.
OpenSSL> req -config openssl.cnf -new -key ca.key -out ca.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
179
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ’.’, the field will be left blank.
-----
Country Name (2 letter code) []:AU
State or Province Name (full name) []:QLD
Locality Name (eg, city) []:Toowoomba
Organization Name (eg, company) []:mansell
Organizational Unit Name (eg, section) []:neonatal
Common Name (eg. YOUR name) []:mattkinast.homeip.net
Email Address []:morphius_32@hotmail.com
Please enter the following ’extra’ attributes
to be sent with your certificate request
A challenge password []:matt
An optional company name []:Mansell
[www.akadia.com, current September 2009]
The next step is to sign the certificate signing request. The process below
signs the ca.csr file created in the previous step and creates a certificate file
called ca.cer.
OpenSSL> x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.cer
Loading ’screen’ into random state - done
Signature ok
subject=/C=AU/ST=QLD/L=Toowoomba/O=mansell/OU=neonatal/
CN=mattkinast.homeip.net/emailAddress=morp
hius_32@hotmail.com
Getting Private key
[Hausheer, current September 2009]
The final step is to export the certificate into a PKCS12 file format, a
personal information exchange file. This file can then be imported into the
host machines certificate store allowing it to be trusted. The step below uses
the ca.cer certificate file created in the previous step and creates a .p12 file
called ca.p12.
OpenSSL> pkcs12 -export -in ca.cer -inkey ca.key -out ca.p12
Loading ’screen’ into random state - done
Enter Export Password:
Verifying - Enter Export Password:
OpenSSL>
180
[Hausheer, current September 2009] [www.akadia.com, current September
2009]
After these steps have all been completed then the .ca certificate file
created can be used by the SSL server. Secure transmission can occur when
a client connects and verifies the certificate.
181