Design Document Fleet Management System Preface: This document outlines the design of the Fleet Management System. Audience: Fleet Management System Development Team Development Team: Shawn Chase, Software Engineer Seth Duda, Software Engineer Steve Haapaoja, Software Engineer Adam King, Software Engineer Ben MacFarlane, Project Manager
1. INTRODUCTION 1.1.
Purpose of the system The purpose of the Fleet Management System is to provide transportation companies with a unified solution to fleet management, route planning, and vehicle monitoring, while also providing passengers with a way to estimate local vehicle arrival times, and better use their time. The system consists of interfaces specific to types of user that will provide simple access to the features useful to them.
1.2.
Scope of the system The Fleet Management System will provide schedule and route planning, vehicle / driver tracking, and maintenance monitoring for transportation companies. For passengers it will provide estimated arrival times for a given stop based on real time GPS information.
1.3.
Objectives and success criteria of the project The objective of the Fleet Management System is to provide transportation companies with an easy-to-use interface for managing their vehicle schedules and fleets, while also providing these company’s passengers with the ability to predict, based on real-time GPS data, the arrival of vehicles to scheduled stops. Success of the project will be determined by the accuracy of the predictions as well as the ease of use of the interface and reliability of the system.
1.4.
Definitions, acronyms and abbreviations
Design Document
1
1.4.1.
GPS The Global Positioning System is the world’s only fully functional Global Navigation Satellite System. The system relies on satellites to retrieve information about a device’s location, speed, direction, and time. The Fleet Management System will use GPS devices to track fleet vehicles in real time.
1.4.2.
Fleet Manager The Fleet Manager will be the company employed by the transportation company to keep track of all the vehicles and their use. This user will use the Fleet Management System to track vehicles and plan vehicle maintenance.
1.4.3.
Fleet Dispatcher The Fleet Dispatcher is an employee hired by the transportation company to plan and manage vehicle schedules and routes, as well as monitor driver performance. This user uses the Fleet Management System to plan out vehicle schedules and assign drivers and vehicles to routes.
1.4.4.
J2me The Java Platform, Micro Edition or Java ME (previously known as Java 2 Platform, Micro Edition or J2ME) is a specification of a subset of the Java platform aimed at providing a certified collection of Java APIs for the development of software for small, resource-constrained devices such as cell phones, PDAs and set-top boxes.
1.5.
References “NextBus: About Us” http://www.nextbus.com/corporate/about/index.htm “Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite” http://rewrite.rickbradley.com/pages/moving_to_rails Oracle website http://www.oracle.com/index.html
1.6.
Overview The Fleet Management System is a multipurpose solution for transportation companies and their customers. This document gives a description of specific users involved in the Fleet Management System solution, as well as the services available to each user.
2. CURRENT SYSTEM 2.1.
NextBus.com NextBus.com is a website dedicated to real-time tracking of buses and estimating arrival times to stops. Its focus is on improving customer services within the transportation industry, and thereby increasing use of public transportation.
2.2.
Other Fleet Management Systems There are many proprietary fleet management solutions available to transportation companies. These systems are generally database
Design Document
2
management and reporting system designed for usage by organizations with fleet vehicle assets. 3. PROPOSED SYSTEM 3.1.
3.2.
Overview The Fleet Management System is built around a MVC ( Model View Controller ) architecture. In the following sections you will see an overview of the subsystems, hardware / software mapping, persistent data, security, global control, and boundary conditions. The Model View Controller architecture separates all of the views from the business logic and controllers. This will allow systems designers to easily extend the system in the future with little interference of existing components. We have also separated all of the location tracking, time estimation and route tracking entirely onto the oracle database backend. This also provides developers with the ability to extend the front-end without affecting any of the business logic. Subsystem Diagram
Design Document
3
3.2.1.
View This subsystem is responsible for presenting information to the user within a web browser. ( on a mobile phone or computer ) The view uses information from the Controller and Domain Model to populate the screen. The view is also responsible for providing the user an interface to the Controller.
3.2.2.
Controller The Controller subsystem is responsible to taking all input from the user, processing the data, and selecting the correct view to display. When the controller receives input from a user, it communicates with the Business Logic subsystem to retrieve persistent data from the database. This information is represented as objects in the Domain Model subsystem. The persistent data is then passed from the Controller to the correct View.
3.2.3.
Domain Model The Domain Model is a object-oriented representation of all of the persistent data in the system, along with other special classes to assist with reporting and other tasks. This subsystem would be the “Model” in the Model View Controller architecture.
3.2.4.
Business Logic The Business Logic subsystem contains all of the system business logic dealing with persistent data access. It hides all access to the database, allowing developers to easily extend the Controller and View subsystems. This subsystem is responsible for population of the Domain Model objects, which are passed back to the View.
3.2.5.
Database Interface The Database Interface subsystem provides a later between the database and the Business Logic subsystem. This subsystem is responsible for managing a connection with the database, sending queries, and retrieving information.
3.2.6.
Route Tracking The Route Tracking subsystem lives on the database itself. This subsystem is responsible for tracking vehicles, estimating times, and tracking routes. By sitting directly on the database, this subsystem provides an extra layer of security and improved performance. This subsystem is implemented with PL/SQL on the oracle database.
3.2.7.
GPS Device The GPS Device subsystem is the GPS interface for the vehicle driver. This subsystem will communicate with the Controller Subsystem using HTTP requests. It is responsible for sending GPS coordinates to the Fleet Management System.
Design Document
4
3.3.
Hardware/Software Mapping
The Fleet Management System lives on three different hardware/software systems. In the above model, the top system is the Apache Tomcat Application Server. This is where all of the subsystems in the Model View Controller architecture reside. The View subsystem is implemented using JSP technology. The Controller is implemented using Servlets & the Domain Model is made up of Beans. The Business Logic subsystem using the Database Interface to communicate with the database server ( Oracle 10g ). This is where the Route Tracking subsystem lives. Finally, there is the Blackberry Smartphone 8300 hardware system. This is where the GPS Device subsystem is located.
Design Document
5
3.4.
Persistent Data Management
The above diagram is a basic outline of the database schema. Below you will find a detailed outline of all of the persistent data elements. Users FirstName LastName Username Password Last_Login Session Role Design Document
6
Schedules Company_ID (FK) Schedule_Type_ID (FK) Route_ID (FK) Schedule_Item ID Schedule_ID (FK) Order Schedule_Stops Route_Stop_ID (FK) Schedule_Item_ID (FK) Schedule_Time Schedule_Assignment Schedule_Item_ID (FK) Vehicle_Operator_ID (FK) Vehicle_ID (FK) Schedule_Types ID Type Companies ID (PK) Name Street City State Zip Country Vehicles ID (PK) License_Number UID Company_ID (FK) GPS_Devices ID (PK) Operator_ID (FK) Design Document
7
Company_ID (FK) Vehicle_Operators ID (PK) FirstName LastName GPS_Device_ID (FK) Company_ID (FK) Stops ID (PK) Lat Lng Street City State Zip Country Name Company_ID (FK) Routes ID (PK) Name Company_ID (FK) Route_Stops ID (PK) Route_ID (FK) Stop_ID (FK) Order (FK) Route_Tracks Route_ID (FK) Lat Lng Order GPS_Sessions ID (PK) GPS_ID (FK) Created Updated Design Document
8
Expired Closed Operator_ID (FK) Company_ID (FK) Vehicle_ID (FK) Route_ID (FK) Curr_track_ID (FK) GPS_Locations Session_ID (FK) Lat Lng Datetime Speed Direction Distance_from_last_track Route_Tracking Session_ID (FK) Next_est_track_ID (FK) Prev_est_track_ID (FK) Distance_to_next_track Estimated_Times Vehicle_ID (FK) Route_ID (FK) Stop_ID (FK) Estimated_time Last_Updated Database access with be though an ODBC driver on the Tomcat Application Server. The database server will run Oracle 10g. Queries will be sent to the server directly from the Business Logic subsystem. ( through the Database Interface ) The Route Tracking subsystem will be located on the Oracle 10g database as PL/SQL procedure, packages, and triggers. 3.5.
Access Control and Security There are four main users; these include the passenger, the dispatcher, the office manager and admin. John, the passenger, has basic anonymous access. John can search for a bus company and schedule, locate a bus and route, and find out when the next bus arrives at a certain stop. Bob, the dispatcher, has all of the above access as well as managing which buses are on which route. He also can view all active vehicles. Lastly, Bob is able to edit the schedules. Mike, the office
Design Document
9
manager has all of the above access as well as things such as managing employees, GPS systems and things of that nature. Tom, the admin, can add and configure new companies to use our product. All sensitive data will be encrypted to assure our users safety. 3.6.
3.7.
Global Software Control
Boundary Conditions Our system will run on Tomcat and the database in Oracle. For our system to launch, all you have to do is start both Tomcat and Oracle. Both tools are fairly intuitive and easy to use. For errors the system will use a standard 401 error to maintain the look and feel for the site. Functional errors will also have the same results, showing the error from either Tomcat or Oracle depending on the user’s access. These errors will show for the office manager and the system
Design Document
10
admin. Special information pertaining user data of other companies will only be shown to the administrators.
4. SUBSYSTEM SERVICES 4.1.
User Interface Design
4.1.1. Passenger 4.1.1.1. Track Vehicle
Design Document
11
4.1.1.2. View Arrival Times
4.1.1.3. View Company Schedule
Design Document
12
4.1.2. Dispatcher 4.1.2.1. View Routes
4.1.2.2. Manage Route Schedules
Design Document
13
4.1.2.3. Find arrival Times
4.1.2.4. Track Vehicle
Design Document
14
4.1.2.5. Active Vehicle
4.1.3. Manager 4.1.3.1. User Management
Design Document
15
4.1.3.2. GPS Management
4.1.3.3. Route Management
Design Document
16
4.1.3.4. Stops Management
4.1.3.5. Vehicle Management
Design Document
17
4.1.3.6. Driver Management
4.1.3.7. Statistics
Design Document
18
4.1.4. Administrator 4.1.4.1. Add New Company
4.1.4.2. Configure Company
Design Document
19
4.2.
Output Design
4.2.1.
Driver Data Output
4.2.2.
Bus Statistic Output
4.3.
Class Diagram
Design Document
20
4.3.1.
Domain Model Subsystem
Design Document
21
4.3.2.
Controller Subsystem
Design Document
22
4.3.3.
Business Logic Subsystem
4.3.4.
Database Interface Subsystem
4.3.5. Route Tracking (Oracle PL/SQL) Package: RouteTracking Procedure: UpdateEstimatedTimes Procedure: UpdateLocationTracking( Session_ID, lat, lng ) GPS_Locations Trigger: UpdateLocation ( On Insert )
Design Document
23
4.4.
Process Logic The majority of the business logic is stored within the Oracle Database as PL/SQL packages, procedures and triggers. Below is a outline of these processes. Package: RouteTracking Procedure: UpdateEstimatedTimes Description: Calculates estimated times for all active GPS Sessions & stores these times into the Estimated_Times table. This procedure is call once every 5 minutes by a scheduled job on the Oracle database. This is calculated based off the current speed, and distance from the closest location on the route. By following the route path, we can estimate the distance to any stop along the path. Using this distance we can generate an estimated time of arrival. Procedure: UpdateLocationTracking( Session_ID, lat, lng ) Description: Calcaulates datetime, speed, direction and distance using the last known location on the GPS Session. Updates GPS Session with this new location. Then, calculates the next closest location along the route ( based on current position, speed & direction ). This function calculates the distance from the last known closest location on the route to every other position on the route less the estimated distance traveled since the last GPS_Locations update. The position with the smallest distance is estimated to be the current location.
4.5.
Google Maps / AJAX Communication A large part of the Fleet Management System will be designed using Google Maps & AJAX. To standardize communication between the Controller subsystem and AJAX controls, we have defined a standardized XML format for sending data between the Fleet Management Server and a user’s browser.
Design Document
24
< .. >
Design Document
25
< .. > 5. COSTS, BENEFITS & SCHEDULING 5.1.
Estimated costs - $170,130
5.1.1.
Salary Costs - $152,280 Software Engineers - $2,080 / 45hr Week Project Manager - $2,500 / 45hr Week The following cost breakdowns are estimates of labor which will be
Design Document
26
described in detail in the Project Schedule (see 5.4), and are subject to change pending notification and approval from the client. 5.1.1.1 Software Design and Planning - $46,600 Software Design and Planning will take place over the course of 5 total weeks. 4 Software Engineers will work full time, along with 2 weeks of work by the Project Manager. 5.1.1.2 Software Development - $44,100 Software Development will take place over the course of 5 total weeks. 4 Software Engineers will work full time, along with 1 week of work by the Project Manager. 5.1.1.3 Software Testing and Troubleshooting - $52,420 Software Testing and Troubleshooting will take place over the course of 6 weeks. 4 Software Engineers will work full time, along with 1 week of work by the Project Manager. 5.1.1.4 End User Training - $9,160 End User Training will take place over the course of 2 weeks, with 1 Software Engineer and the Project Manager working full time. Product manuals will be supplied to the client with detailed instructions on how to use the system. 5.1.2.
Software Costs - $600
5.1.2.1.
Software Development - $0 The project team will utilize Ruby on Rails for its programming needs, an open source programming language.
5.1.2.2.
Project Management - $600 Microsoft Office Project along with Star UML to plan the project.
5.1.3.
Hardware Costs - $17,250
5.1.3.1.
Handheld GPS Devices - $2,250 The drivers will be equipped with Blackberry Devices, costing approximately $150 each. This case assumes that 15 devices will be purchased to be used in the field and as backups should a device fail.
5.1.3.2.
Server - $15,000 A Dell server will be purchased to host the database and application software. This will include the Operating System, Tape Backup Hardware and Software, Database Software and all applicable licenses.
5.2.
Estimated Benefits
Design Document
27
5.2.1.
Tangible Benefits
5.2.1.1.
Reduced maintenance Costs With the proper tracking of mileage, maintenance issues and general vehicle condition with this system, vehicle maintenance can be more efficiently planned. Better upkeep of regular maintenance at the proper intervals keeps vehicles operating longer without unexpected problems or breakdowns.
5.2.1.2.
Improved Scheduling Efficiency Centralized management of vehicle and driver deployments allows management to keep vehicles on the road at the proper times. Through knowing which vehicles are where, dispatch time is reduced and drivers spend less time idle and more time on the road servicing customers.
5.2.1.3.
Increase in Customer Base The ease of use and practicality of this system will attract more customers wanting more information from their transportation service provider.
5.2.2.
Intangible Benefits
5.2.2.1.
Customer Satisfaction Customers will be able to track vehicles to better plan their day to day activities. The information available to them will ease frustration waiting for vehicles as well as provide a valuable asset to customers who operate on a tight schedule.
5.2.2.2.
Employee Satisfaction An easy to understand interface and functionality of the system will ease employee frustration over problems with the existing system.
5.2.2.3.
Employee Performance Tracking Management will be able to better tack employee performance through logging of driver data for performance reviews.
5.2.2.4.
Improved Driver Efficiency Drivers will be better able to know and plan for their routes throughout the day, reducing confusion on where they are supposed to be at what times.
5.3.
Project schedule – 15 Weeks The following breakdowns of project pieces include estimates of the time required for each component of the project. These estimates are subject to change pending notification and approval from the client.
5.3.1.
Hardware Purchasing – 2 Weeks Blackberry devices and a server will be researched and purchased for this project. This includes shipping times to the office.
Design Document
28
5.3.2.
Hardware Setup and Configuration – 1 Week The server will be setup and configured for use by the project team, including troubleshooting software installs and configuring tape backups.
5.3.3.
Back-end Database Design and Planning – 3 Weeks End-user interviews and analysis of the current system will be utilized to determine what types of data will need to be included in the system. The database will be planned out and properly normalized before coding and development.
5.3.4.
Back-end Database Coding and Development – 2 Week Coding of the database from the design of the Project Team (see 5.4.3).
5.3.5.
Back-end Database Testing and Troubleshooting – 1 Week Testing and troubleshooting of the back-end database system by itself.
5.3.6.
Device Connectivity Server Coding – 2 Weeks Coding of the software to connect the Blackberry devices to the backend server.
5.3.7.
Device Connectivity Testing and Troubleshooting – 1 Week Testing of software used for connectivity between Blackberry devices and the backend server.
5.3.8.
Front-end Design and Planning – 2 Weeks End-user interviews and analysis of the current system will be utilized to determine the look and feel of the front end. This will also include determining what data needs to be gathered from the enduser, as well as the layout and design of the user interfaces.
5.3.9.
Front-end Coding and Development – 1 Week Coding of the front-end from the design of the Project Team (see 5.4.8)
5.3.10. Front-endTesting and Troubleshooting – 1 Week Testing and troubleshooting of the front-end interface. 5.3.11. System Testing and Troubleshooting – 3 Weeks Testing and troubleshooting of the entire system. This will include 1 week of real-time environment testing utilizing a test group of employees from the client. 5.3.12. End User Training – 2 Weeks The Project Manager and 1 Software Engineer will hold training seminars for the client’s employees to familiarize themselves with the software and system. User Manuals will be created for additional training.
Design Document
29
5.4.
Allocation of Coding Tasks The programming tasks will be broken up by subsystem; Seth will program the domain model subsystem; Steve will program the controller subsystem; Ben will program the business logic subsystem; and Shawn will program the database interface subsystem.
Design Document
30
