EE4214 – Real Time Embedded Systems

Smart Cab Allocation System (SCAS)

Project Report

Team

Wee Sin Jen U076264W

T. Aarthi Priya U066116R

Raghavendran Vasudevan U066029Y

Mohamed Isa Bin Mohamed Nasser U076183A

Renjithkumar G.K. U075606N

Lam Wai Leong U075597U

Executive Summary

In this report, a comprehensive description and discussion of the Real-Time Embedded Smart Cab Allocation System (SCAS) design is presented. This includes schematic diagrams illustrating different components interacting with each other as well as flow charts for the real-time server modules, networking technique and client side logic. Real Time aspects of the design such as inter-process communication, deadlock management, process synchronization, concurrency etc. socket programming, other networking aspects, client’s GUI and information capturing and processing techniques are explained in detail. An insightful mention of reasons for selection of methods and technologies used for implementation and the problems we encountered while implementing can be found here. Towards the end individual contribution of the team members are highlighted.

Overview

This section describes the functionality of the SCAS. SCAS tracks the taxis belonging to a company and maintains all information in a database. SCAS implements 3 functions facilitating Cab Allocation.

è  Cab Tracker: The system will communicate with the taxis belonging to the company at regular intervals and will learn their status; busy or idle and their current location. If a taxi returns its status as idle at a particular zone (Numbered 1-9), SCAS assumes that the location will not change and will earmark the taxi for requests from that region. Thus, SCAS polls the busy taxis for their status. All idle cabs, upon allocation, are moved to the busy taxi database.

è  Web-taxi transaction: Allows the user to perform taxi booking through a web-based interactive system. The user merely needs to specify his current location, destination and phone number to request for a taxi. The web-server will pass the request to SCAS, which will process the request and allocate a taxi at that location. This information will be sent back to the customer.

è  Service Notification: Upon processing a request from the web server, SCAS will allocate a taxi for the customer and move the taxi from idle to busy state. SCAS will send the details of the customer (Phone number and destination) to the allocated taxi.

è  Cab Registration: A cab can connect to the server and register its availability for service. The server will record the connection and will communicate with it for allocating jobs.

Web Server Interaction Chart


Modeling the System

Client: The modeling of clients is easy since they are restricted to a predetermined input of booking or not booking.

Taxi: Modeling the taxi itself is complex since the taxi can hold multiple states and will approach passengers who are within sight. The traffic of these passengers varies by the time of day and this should be modeled.

Lastly, delays in switching in establishing connection to the taxis for polling must be modeled.

With this in mind, we made two programs:

1.  Taxi Traffic Simulator

2.  Single Taxi Simulator

The taxi simulator is able to test overloading. The passengers appear sporadically. And once within range the taxi will pick up the customer. Revenue will also be recorded. This is useful since for this is a commercial system, and the optimization of revenue is important.

The single taxi simulator will model the switching delays for the program.

Data Flow Diagrams and Flow Chart

Level 0 DFD

Level 1 DFD

RTAI Design

A) Inter Process communication

User Space (user process) and Kernel Space (RTAI tasks)

In order to establish communication between the processes running on the user space and the real-time tasks in the kernel space RT-FIFOs are used as shown in the figure. The producer-consumer algorithm described in the lecture is used to synchronize reading and writing to the FIFOs. However, the implementation is not direct. Since user processes cannot directly manipulate RTAI semaphores, a FIFO handler is written such that whenever the user processes write to the FIFOs, the producer- consumer semaphores are properly adjusted. There are 3 RT-FIFO queues in SCAS, one for the web-taxi request, one for the cab-registering process and the other for the cab tracker task. The messages from the latter queue are used to update the database.

Client-Server Network Connection

B) Scheduling

We chose to use preemptive priority scheduling policy for the RTAI tasks. This is primarily because the web request for a taxi has a higher importance (and thus priority) than the cab tracker and the cab registration tasks.

When a customer requests for a cab using the web based system, it is unfair to keep him waiting for a long time and hence, the response must be as quick as possible. Also, there must be a time before which a cab should be found for him. Thus, this takes highest priority and the deadline must be met by the server. Also, it is important for the system to be aware of all the status of cabs as servicing web-requests can cause depletion of cabs in each location. Hence, the server polls all the “Busy” cabs periodically to find out if anyone has dropped a customer off and become “free”. This task is never-ending long task which will take place in the absence of web requests. Also, if a new cab can service customers, it must let the server know of its availability. But this isn’t as critical as providing real-time service and hence this has the least priority amongst tasks.

There are different FIFO queues for each type of task and all the tasks within a particular queue contain the same priority.

C) Database

We have defined a database which contains the location, status and ID for each cab in the company. This database is accessed and modified by the cab tracker function which communicates with the cabs and finds out their status at regular intervals. In addition to this, there are two arrays which have been defined for the purpose of cab allocation. One is a matrix which contains the IDs of all the cabs ordered location-wise. That is, the array at freeCabs[n] will contain the IDs of all the free cabs in zone n. In addition to this, there is an integer array which stores the size of array for each zone. For example, if there are 4 cabs in zone 32, freeCabsSize[32] = 4. Thus, if a request comes from a customer in zone 32, the server returns the element at freeCabs[32][freeCabsSize[32] – 1] and decrements the value in freeCabsSize. This helps us ensure that the retrieval is always O(1) which is not only fast but also consistent and hence effective in embedded systems.

D) Clients

The system contains two client programs, one client to handle web requests and the other one to simulate a taxi.

Web-request Client

The web request client is a C program which interacts with a XAMPP server and retrieves information regarding a cab request. The XAMPP web server was done using PHP and HTML scripts and this provides the interactivity with the customer and facilitates the process of requesting a cab.

The web-based booking system is a simple web page where a customer can enter his location, the destination location, his phone number and name. Upon clicking submit, the details are written into a text file “Textfile.txt”. The web-request client reads this file continuously, and when it has been updated, it sends the request in the form of a string over to the server. This string contains the special characters “WC” to indicate that the request is from the web client so that there is no conflict with the cab tracker messages.

When the server returns the allotted cab ID, the web-request client writes the data into a different text file, “ResponseFile.txt”. This file is accessed by another PHP script, “PHPResponse.php” which displays the allocated cab ID to the customer.

Taxi Client

The other client program that SCAS contains emulates a taxi. When the program connects for the first time, it registers with the server. This program can handle two different types of communication with the server. One is the cab tracker request, where, the client receives a command “C0” after obtaining a connection from the server. This means that the taxi client should send its status back to the server. A message is displayed using a GUI depending on the status of the cab. If it is idle, a slogan is displayed and if is busy, the customer details are displayed. A finish button is present in the GUI during busy time which the cab driver should click on dropping a customer off. This will change the status of the taxi from busy back to idle. The client reads from the file “client.txt” and sends the cabId, location (zone number) and status (0 or 1 based on free or busy) using the structure defined in control.h. This data will be used by the server to update its database.

The other type of communication with the server occurs when a particular taxi has been assigned for a web request. In this case, the server connects to the taxi client and sends a packet with the characters “C1” followed by the phone number, time and destination of the customer using the structure defined in control.h. The taxi client updates the “client.txt” file.

All the packets between server and client are sent as strings. Based on the special character “C0” or “C1”, the taxi client will decide how to decode the rest of the message.

Individual Assessment

Wee Sin Jen (U076264W)
Project Contribution
For our SCAS project, i was involved in:
1.  Configuration of the uCSimm board and downloading procedure.
2.  The overall system network connection design
3.  The socket programming for the client part for SCAS cab and SCAS web client.
4.  The socket programming for the SCAS server.
I have been in charge to work on the uCSimm board configuration and program downloading in this project. I also work with Aarthi for SCAS Cab program. We discuss the algorithm for the SCAS Cab program and I work on the socket programming part.
Besides working with Aarthi, I work with Renjith on socket programming as well on his SCAS Web Client program.
Knowledge Gained
After undergo my participation in this project, i have an idea on how the operating system actually works and the important of the real time algorithm in the system. I realized that the task handling and how the system handle the tasks by scheduling and its effects to the operating system.
On the other hand, I work out the overall network communication for this system and I think this is a valuable experience.
Comment on project
I like the idea of this project where we can book the cab in advanced through website. But the unfortunate is we are not able to integrate all the functions into the system. I realize that the understanding of the operating system is important for this module.
After going through this project, I have an better understanding on real-time system, like task scheduling, interrupt handler, pre-emptive, deadlock and etc.
Lam Wai Leong (U075597U)
Project Contribution
·  Database Management
·  Implementation of functions in RTAI Kernel Module
My work for the project involves the Database Management and some of the functions in the RTAI Kernel Module, which involves the file database.h, main_logic.c (kernel module) and server.c. The database header file mainly describes the structure, which is used in the main_logic.c, which contains various functions that manipulate the data and ensuring that the data are correct. Involvement in server.c is mainly in codes that will pass and retrieve data to and from the kernel module.
Knowledge Gained
I have learnt about the real time concept, the real time implementation in the kernel module and how data can be passed between kernel module and user-space application. I also gained some knowledge on socket programming, which is implemented by the other group members.
Comment on project
The project is time consuming and without prior knowledge of linux and real time programming, it has been very challenging. Testing out the codes in the uCsimm board is also quite tedious since the downloading of the program takes a while. The bad thing is the group did not manage to make the system fully work.
Renjith Kumar G.K.(U075606N)
Project Contribution
For our SCAS project, I was involved mainly in:
1.  Requirement, Design and Analysis SCAS Web Client.
2.  Implementation of the SCAS Web Client using Apache localhost.
3.  Development of http server scripts (xampp on fedora) and http client scripts (php, html and javascript).
4.  Helped in C socket programming for the http server client.
5.  Involved in the discussion of RTAI task and algorithm development.
My main task was to write the web client through which a person can book at taxi. I have implemented it using Apache server and php, html scripts. The captured data from the web page is written to files which in turn is read by a C program which communicates with the ucSimm board using socket connection and pass the read data. The response given back from the ucsimm is read by the same C program which writes back to another file. This file is then read by the php scripts and display on the web to the client.
The whole process takes less than 6 seconds for completion.