EE4214 REAL TIME EMBEDDED SYSTEMS
Group 9 – Clinic Queue Management System
PROJECT REPORT
DATED : 13 November 2009
Cheung Zi Eu Augustine - U070394R
Huynh Le Trung - U066027B
Mateja Dokleja - NT090887R
Ritika Taragi - U066042L
Sahil Gupta - U066618E
Tiew Ee Yeong - U070447U
CONTENTS
1. PROJECT INTRODUCTION...... 4
1.1 Overview ...... 4
1.2 Detailed Description ...... 5
1.2.1 Data collection mechanism...... 5
1.2.1.1 Graphical User Interface...... 5
1.2.1.2 mySQL database...... 7
1.2.1.3 Input using Bluetooth technology...... 7
1.2.2 Data Transfer through Socket Mechanism using TCP/IP...... 7
1.2.3 Room Allocation Mechanism...... 8
1.2.4 Process Scheduling/ Task handling...... 9
1.2.5 Speaker...... 10
1.2.6 LED’s……………………...... 10
1.2.7 Push Button and Interrupts …………………………………………………………...... 10
1.2.8 Clinic System Display ……………………………………………………………………10
1.2.9 Patient Threshold ………………………………………………………………………..11
1.3 System Manual (user level) ………………………………………………………...... 11
1.4 System Flowchart (High level overview) ...... 12
1.5 Use Case Diagram...... 12
2. Software Design Features ...... 13
2.1 I/O facilities……………………………………...... 13
2.2 Process Scheduling...... 13
2.3 & Inter-process communication...... 13
2.4 Deadlock Management...... 14
2.5 Mutual Exclusion...... 14
3. Software Design Diagram...... 15
3.1 Data Flow Diagram...... 15
3.1.1 Level 0...... 15
3.1.2 Level 1...... 15
4. Testing...... 16
5. Learning Outcomes...... 17
APPENDIX
Project Code...... 21
1 PROJECT INTRODUCTION
1.1 OVERVIEW
Hospitals and clinics provide essential and mandatory health care services to the people. With the growing volume of patients seeking medical attention everyday, it is imperative to have in place a smooth functioning Service Management System to ensure highest standards of serviceability. An inefficient system could lead to overcrowding of clinics, a strain on facilities, and inconvenience to patients, making health care more inaccessible and inequitable for the population.
For our project, we propose to develop a fair Clinic Queue Management System to allocate patients to a well managed hospital Queue Management System (QMS).
1.2 DETAILED DESCRIPTION
The aim of the project is to build a Real Time Queue Management System. The system manages the following activities:
- Data collection from Incoming patients using a friendly Graphical User Interface (GUI)
- Data transfer from GUI (workstation) to Queue Management module (uCsimm board)
- Room allocation based on a planned algorithm
- Room occupancy status display through the board LED’s
- Speaker to indicate incoming patient.
In this section, we will describe the Queue Management System, in detailed steps.
1.2.1. Data collection mechanism
Data collection mechanism is divided into 2 main parts: Graphic User Interface(GUI) for interaction with user and mySQL database for retrieving user’s data and medical history.
1.2.1.1. Graphic User Interface (GUI)
GUI is user friendly interface that allows patient to log in using his unique user identification number. When that happens, first GUI connect to mySQL database and searches for patient’s ID. If ID is found, patient’s information and medical history are retrieved from database presented in box ‘Patient data’. After that, random values generator mechanism is used to simulate results of patient’s initial examination. For key factors ‘0’ or ‘1’ is randomly generated and that information is presented in ‘Initial examination results’ box.
Data retrieved from the database and randomly generated data is chosen in the way to fit chosen prediction model. Prediction model which was used was developed originally for pneumonia by the team of researchers supported through a grant from the Federal Agency for Health Care Policy and Research and has been validated as being accurate and applicable. Model goes though all the key factors and for each of them, according to it’s status, certain value is added up to patient’s sum. After that, patient is put into one of 5 risk categories according to his/her sum. As our system supports only normal and emergency patients, patients of upper two categories, of medium and high risk, are considered emergency patients while everybody else is considered normal patients.
For patients to be sent to the board and to the queue, application has to be connected to the board. That is done by clicking on the ‘Connect with hospital’ button. When button is pressed, socket is created on fixed IP address 168.192.1.1. and port 4242 and GUI acts like a server and listens on the port of the attempt of connecting by the client. When the connection is established, patients can be sent into the queue by sending letter ‘e’ or ‘n’ over the Ethernet using TCP/IP protocol, according to patient’s calculated status. Both sending and establishing the connection are done in by using asynchronous functions which do their job and then when other side (board as a client) responds callback function is evoked to process that response. That way the program is not blocked while waiting for action of other side and it’s possible to execute other tasks. On the very bottom of the screen, at status strip information about connection are displayed.
Additionally, GUI has a log box where information about events relevant to the user are displayed.
1.2.1.2. mySQL database
MySQL database is used to store information about patient’s details and past medical records. GUI connects to the database when ID is provided and gets that information. Database consists only of one table, ‘Patients’, and is protected by password. In the table patient’s id is used as a primary key of the database so no duplicate records of the same id are possible.
1.2.1.3. Input using Bluetooth technology
Another mechanism is used for generation of test cases as this scenario cannot generate users fast enough for system to be stressed. For that reasons and for more flexibility of the system another mechanism of input is realized. Idea is simple: instead of manually typing their user id’s in GUI, users can do that by using Bluetooth capabilities of their cellphones. File including patient’s id is transferred over Bluetooth connection to certain folder at the computer where GUI is running. GUI has a mechanism of listening for an event of creating the new file in selected directory of the computer and it detects transfer of file with patient’s id. When it is detected, file reader implemented the GUI opens the file, reads patient’s id and from that point on processing goes on as for any normal user who has typed in his/her details in GUI. Initial examination and patient data for new user are shown in the boxes and data about new user is shown in log box, too.
1.2.2 Data Transfer through Socket Mechanism using TCP/IP – The uCsimm/uClinux combination provides necessary hardware and software for Ethernet connectivity. We use the Ethernet capabilities through the socket mechanism that supports the client/server interaction over an internet i.e. over a local lan. The server executes on the linux workstation and the client on the uCSimm board. When the QMS software is booted, a program is used to establish client-server connection, and information on incoming patients (‘n’, ‘e’) is sent over the network throughout the program.
On the uCsimm side, the information sent over the link is stored in the socket buffer for reading. A RTAI FIFO is created in kernel space to read the incoming data for processing.
RTAI provides a variety of mechanism for inter-process communication. Although the Unix system provides similar IPC mechanism to the user-space processes, RTAI needs to provide its own implementation for them in order to make it possible for the real-time tasks to use the IPC mechanism, as they can not use the standard Linux system calls. The different IPC mechanism are included as Kernel modules, which can be loaded in addition to the basic RTAI and scheduler-modules only when they are needed by the tasks.
We use the communication mechanism of RTAI – FIFO. FIFO is a synchronous and unblocking one-way communication channel between a Linux process and a real time task having a size limit. No data can be overwritten in a FIFO, but a FIFO can become full in which new data cannot be written until the old data is consumed.
When patient data is received in the FIFO, a FIFO handler detects any new incoming data and passes it to the main program for queue/room allocation.
1.2.3 Room Allocation Mechanism - Two queues are created, one to hold the incoming patients that are not emergency cases (‘n’) and one to hold emergency cases (‘e’). The incoming data (‘n’, ‘e’) is assigned to the respective queues and the size of each queue at any point of time represents the number of emergency and normal patients in waiting for being attended by the doctor.
The system has 4 clinic rooms that can be allocated to patients. To determine fair priority of room allocation to normal and emergency patients, we use the following algorithm.
p = size_e / (size_n + size_e),
where:
p is used (as below) to determine the priority of emergency patients over normal,
size_e = size of queue holding emergency patients, i.e. no of emergency patients in system
size_n = size of queue holding normal patients, i.e. no of normal patients in the system
If (p = 0), no_of_room_emergency = 0;
(0 < p <=0.25), no_of_room_emergency = 1;
(0.25 <= p <=0.50), no_of_room_emergency = 2;
(0.50 <= p <=0.75), no_of_room_emergency = 3;
(0.75 <= p <=1.00), no_of_room_emergency = 4;
where no_of_room_emergency is the number of rooms that can be allocated at a single point of time to emergency patients.
This algorithm determined the number of rooms to be allocated on priority basis to emergency patients over normal patients, based on the two queue sizes. Hence, when no_of_room_emergency=2, at most two emergency patients can be assigned rooms, as and when the rooms become available.
For example; a) size_e=0, all rooms will be allocated for normal patients.
b) Size_e=3, size_n=12, 1 room will be assigned (as and when any room is free) for emergency patients so that all at most 1 emergency patient will be assigned a room, which becomes available the first. The second emergency patient will only be assigned the first available room after the first emergency patient has been attended to.
1.2.4 Process Scheduling/ Task handling – The Main program has 3 main tasks:
Task 1 - Fifo handling (to retrieve patient detail incoming over the network link)
Task 2 – Reading Data from Buffer and allocating room, display LED
Task 3 – Speaker invocation
Task 1 has the highest priority. It is an event driven task. When data is available in the FIFO, the FIFO handler will start task 1. Task 1 then updates the queue information accordingly.
Task 2 and task 3 are periodic tasks. The Time period has been pre-determined based on analysis. Task 2 checks the current queue information and room status and allocates the rooms to the patients. It also controls the LEDs to inform each room’s occupancy. Because interrupts can change the queue information and room status at any point of time, we need task 2 to check the queue and room status again once in a while and a periodic task implementation would be the most suitable choice for task 2 over here.
Task 3 has the lowest priority, and hence whenever any other task is activated, it is pre-empted.
1.2.5 Speaker – The Speaker is the lowest priority task in the system. It is scheduled to run throughout, and is pre-empted by higher priority tasks. Hence a speaker in the off mode indicates that another task is currently active. A user space program is coded to read from a audio file and then write the read data into a real time FIFO. Then a kernel module is there to invoke the FIFO handler and subsequently, the PWM output of the microcontroller is loader with audio samples to produce sounds.
1.2.6 LEDs – The uCsimm board LEDs on Port D is used to display a room occupancy status. If a room is occupied, the LED assigned will be lighted, and when vacant, the LED assigned will be off.
1.2.7 Push Buttons and Interrupts - A push button/dip switch is used to indicate when a room becomes vacant. This is achieved by using hardware interrupts provided by the MC68EZ328 micro-controller. When there are edge sensitive triggers to the Port D inputs, an interrupt service routine is called to clear the room and update the patient queue status. This is analogous to the reality where the doctor in each room has a button available to indicate when he is ready for the next patient. The interrupts handlers are registered in Linux and reflected in /proc/interrupts. Since there are 3 doctor rooms, 3 pins are used to generate interrupt to indicate that the patient is leaving the particular room. The LED display will change to vacant accordingly.
1.2.8 Clinic status display – Since a kernel module is employed to schedule patients and update room availability, data needs to be passed to the user application for displaying an overall clinic status. Therefore, shared memory is employed because of its convenience and ease in reference. It can be described as an array of storage with each element having the details needed to display status. The user application is allowed to read from the array and output to console necessary information that describes the whole clinic status.
1.2.9 Patient threshold – There will be a limit to how many patients 3 doctors in a clinic can handle. We are setting a limit using a general semaphore, such that when a new patient arrives, a semaphore is being taken and if he leaves a semaphore is being posted. The motivation to use a general semaphore is that adding and subtracting patients from queue are two different tasks running and semaphores may be used to prevent any concurrency issues.
1.3 SYSTEM MANUAL
The system (at the user level) is made up of 2 components, the server (uCsimm) and the workstation. The workstation will continuously play a sound if it has no other tasks (indicating an idle system).
When a patient enters the clinic he will have his details entered into the system GUI at the workstation. The user will also include whether he requires emergency assistance. Based on his entry and urgency level, he will be assigned a queue number and automatically directed to an appropriate room when one becomes available.