Fleet Management Taxi

Document Sample
Fleet Management Taxi Powered By Docstoc
					                             Contract n° 507953




   DBE calls procedure

Annex - Proposal Part B

 Type of instrument: Integrated project


     Date of preparation 29 Nov 2005
                NITAX S.A
             C/ Salamanca 12
       50005 ZARAGOZA (Spain)

Coordinating person: José E. LOPEZ-SOLER
        e-mail: jose.lopez@nitax.net

         Phone :+34 976 565549
          Fax: +34 975 556846

                 Project  funded    by   the    European
                 Community under the “Information Society
                 Technology” Programme
Contract Number: 507953
Project Acronym: DBE
Title: Digital Business Ecosystem


Short Description:


Keywords:
Partners owning:
Partners contributed:
Made available to: All Consortium and EC

Versioning
Version Date            Author, Organisation
1     BRIEF COMPANY DESCRIPTION ............................................................... 4

1.1      BACKGROUND                                                                                            4

1.2      EVOLUTION                                                                                             4

1.3      NITAX CURRENT PRODUCTS                                                                                5

1.4      PROJECT OBJECTIVES                                                                                    5

1.5      CAPABILITIES FOR DEVELOPMENT                                                                          6


2     DESCRIPTION OF THE APPLICATION AND SCENARIOS ........................ 7

2.1      PLATFORM FOR TAXI RESERVATION                                                                         7

2.2      ELECTRONIC COMMERCE                                                                                   8

2.3      BUSSINESS ECOSYSTEM                                                                                   8

2.4      PARTICULAR SCENARIOS TO INTEGRATE                                                                     9


3     USER CANDIDATES .................................................................................. 10

4     WORK PLAN............................................................................................... 11

4.1      WP TO DEVELOP                                                                                       11

4.2      GANNT CHART                                                                                         14


5     PROJECT BUDGET AND REQUESTED FUNDING .................................. 15
1 BRIEF COMPANY DESCRIPTION

  1.1 BACKGROUND

NITAX S.A. is a company whose origin goes back to 1969. During those years repairing
and servicing tasks to the public transport market, mainly within the taxi sector, were
started. These activities constituted the core business of the company for several years.


However, thanks to the innovator and ambitious spirit of NITAX founders, businesses
opportunities were rapidly foreseen in the growing Spanish taxi market and efforts for
pushing the company towards the creation of its own products were applied.


Since those years, NITAX has evolved from a company focused on fixing and repairing
services to the antique taximeters to a company that designs, manufactures and
commercialises its own high-tech product portfolio.


  1.2 EVOLUTION

The above mentioned evolution has been accompanied with an adoption of different
technologies from the electromechanical industry: first servicing tasks were provided to
the old mechanical taximeters but rapidly the electronic technology was incorporated to
the design and manufacturing activities of NITAX.


Different stages of the electronic industry development were adopted during the product
evolution. At the beginning, the simply electromechanical taximeter only used partial
electronic components to provide the required functionality. These devices were
followed by the very first fully-electronic taximeters, which used MSI chips and other
digital electronics. The availability of further scales of integration and new electronic
devices helped the equipment to carry out its continuous evolution, reaching fully
microprocessor controlled taximeters lately in the 70’s. Nowadays taximeters and its
peripherals are manufactured using top level electronic technologies.
  1.3 NITAX CURRENT PRODUCTS

In the scope of the present proposal, we will refer only to the product that is related to
DBE, namely the SIDUS system, a platform for Taxi Fleet Management.
More than two years ago, NITAX decided to go for a product aimed to Taxi Fleet
Management. The purpose of a Taxi Fleet Management System is the efficient
assignment of taxi services to the end user. A key aspect in this kind of solutions is to
get the relevant information in real time and its effective management.


The description of the architecture of a product for Fleet Management helps to
understand that is a truly system composed of several elements working in a common
environment and in a timely and synchronised manner. Main components are:
   -   Central Site. Based on a server-client architecture, it incorporates:
           o Incoming calls demanding taxi services are received via a PBX
           o Real-time GPS positions of fleet vehicles are received through
              Internet over GPRS
           o Geocoding is performed by means of a GIS platform
           o Large amounts of data are managed by a RDBMS
           o A productive user interface facilitates the Operator daily work
           o Other software components acting as interconective glue
   -   Vehicles: GPS positions are tracked and sent to the Central Site.
       Destinations for hiring are provided to the vehicle from the Site Central.
       Information about the economical transaction for the price to be charged
       to the user is also securely managed
   -   End users: namely the passengers. Telephone, Internet or SMS can be
       adequate channels for the demand of a taxi service




  1.4 PROJECT OBJECTIVES

SIDUS-CAW (CAbs via Web) is the concretion of the SIDUS solution in the DBE context.
As a brief summary the purpose for the SIDUS-CAW application is, at least:
   -   to develop a platform for taxi reservation considering its full life cycle
   -   should include static (e.g. web based) and mobile environments (e.g.
       GSM, UMTS)
   -   to include secure electronic commerce functionalities
   -   open to different kind of services nature (on demand, pre-paid, …)
   -   to be able to propagate and be visible in DBE ecosystems


  1.5 CAPABILITIES FOR DEVELOPMENT

The decision of developing a system for fleet management was a crucial issue in the
context of NITAX capabilities. The necessary technologies and know-how for a suitable
architecture implementation were different from the ones mastered by NITAX at that
moment.


This lead to the decision of incorporating new know-how and new development
technologies. Hence, the adopted strategy was to split efforts between in-house and
subcontracted developments. So a careful selection of subcontracted technological
partners gave a fast route to product development and technological transference.


At this moment the capabilities in terms of software development at NITAX, together
with our partners, is of high quality and is at the very edge of the state of the art. For
example object oriented programming, .NET, java, client-server architecture, software
for communications and GIS integration are some of the technologies used by NITAX at
his current developments. It is also important to mention that developments linked to
electronic devices are usually carried out. An example was the integration of on board
equipment for fleet management with a certified COTS Point of Sale.
2 DESCRIPTION OF THE APPLICATION AND SCENARIOS
The application to be integrated in the DBE context will cover several key aspects in the
daily operation of a taxi service reservation and its full life cycle.



   2.1 PLATFORM FOR TAXI RESERVATION

A user friendly web interface will be developed. A key issue for this application is the
platform independence: the rationale for this application indicates that demanders will
use devices ranging form desktop PC to hand held or mobile-phone based equipment.
The implementation should not forget new ways of services demand as the TDT. User
interfaces must take into account all this scenarios.
The application will provide a previous registration for the user. All gathered data will be
used for subsequent communications with the user, but as a general rule, phone and
password could be adequate for user identification.


Topics to be covered will be:
    A. With reference to the user
            a. User registration
            b. User authentication
    B. With reference to the user subscription
            a. Subscribed user
            b. Non subscribed user
    C. With reference to the user category
            a. Private user
            b. Corporate user
    D. With reference to the service
            a. Query about the service(s)
            b. Status of the services (finished, scheduled, on course…)
            c. Time of arrival (when applicable)
            d. Payments status
  2.2 ELECTRONIC COMMERCE

Safe transactions are the very basic requirements for the application. But many other
aspects will be covered. Some requirements to consider are:
   A. To provide secure transactions
   B. To create trustworthiness within the end users
   C. To include a broad scope of payment media
   D. Be open to create different transactional models as response to different
       cases of use. For example:
           a. Service On demand
           b. Pre-paid services
           c. Corporate subscription
           d. Frequent consumers
           e. Others




  2.3 BUSSINESS ECOSYSTEM

SIDUS-CAW will consider not only end-users as the usual taxi services demanders but
also other actors will be taken into account. The platform should integrate appropriate
interfaces for different agents who participate or could participate in the generation of a
taxi service. As an overview the following cases can be considered:
   -   Travel agencies: when a travel package is configured, taxi services are
       likely to be needed
   -   Hotels: its customers are common users of taxi services
   -   Companies: VIPs, executives, visitors and many other people who
       occasionally use a taxi service for displacement to or from a company
       facilities
   -   Tourist resorts: similar to the case of travel agencies
   -   Government and public administration : for example a city council could
       foster the use of taxi as tourist guide for city promotion
   -   Others
Some of the cases above mentioned pose new paradigms in both the business and
operational models that supports the taxi daily work. For example new ways of work
organization and planning, and, obviously, more global operational effectiveness could
be achieved when the taxi is saw as a small but true enterprise unit.




   2.4 PARTICULAR SCENARIOS TO INTEGRATE

As a starting point, the scenarios that the proposal will develop are:
   -   Services reservation for end users
   This covers the tipical scenario when a private user wants a taxi service for a
   particular displacement. Channels used for this kind of demand will be:
           o The internet (a web based front-end)
           o A mobile phone (by means of SMS or WAP)
   All topics, already indicated in previous paragraphs, concerning the payment
   (safety and media) will be covered. Besides, user registration-authentication
   and tools for demand scheduling will be provided.
   A simplified flowchart follows:
                                                        SERVICE
                                                        DEMAND




                                                       WEB Based




                                                         DESK or              WAP / SMS
                             PC User Interface
                                                         MOBILE                Interface




                                                         USER
                                                                         NO   REGISTRATION
                                                      REGISTERED


                                                           YES




                                                         USER
                                                     AUTHENTICATION




                                         Scheduled     On Demand                ...




                                                          RBDMS                        Service
                                                                                                  END
                                                        transaction                   Execution




                                                     Invoicing/payment
   -   Services reservation in a Hotel environment
   Usually a desk interface will be used. The main differences when compared to
   the previous scenario lie in the implied monetary transactions. In this case
   there is no invoicing process for the end user but for the Hotel, which acts as
   a reseller/dealer or service facilitator. This implies an interaction with the
   business processes of the Hotel
                                            SERVICE
                                            DEMAND




                                           WEB Based




                                         PC User Interface




                                             USER
                                                             NO     REGISTRATION
                                          REGISTERED


                                               YES




                                             USER
                                         AUTHENTICATION




                             Scheduled     On Demand                    ...




                                              RBDMS                            Service
                                                                                          END
                                            transaction                       Execution




                                         Invoicing/payment        Hotel Business
                                                                   Processes




3 USER CANDIDATES
The SIDUS-CAW application is planned to be installed in two user facilities:


USER 1. RADIO TAXI COOPERATIVA SANTANDER. C/La Prensa s/n. SANTANDER (Spain)
User 1 is a radio station which currently provide taxi services using analogic radio
communication (standard 1397) in Santander, a northern Spanish city. At the beginning
of the year it is planned to install the SIDUS platform. It provides services to 200
vehicles and is by far the biggest radio association in Santander. Currently they
collaborate with Hotels in order to provide timely taxi services for their customers.
SIDUS-CAW will be tested in this environment


USER 2. TELE TAXI ALMERIA. C/ Cartagena 7, 04007 ALMERIA (Spain)
User 2 is a medium size radio station in Almería, in the south-east of Spain. They have
started to install on board vehicles equipment and incoming demanding services are
already served by the PBX subsystem. Due to the tourist affluence during all the year,
Hotels seem to be potential candidates for testing the SIDUS-CAW




4 WORK PLAN
It is exposed below the Work Packages in which project has been divided. Every work
package shows the activities to be done, the start and end date referred to Month 0 and
the expected results to be provided.


  4.1 WP TO DEVELOP

WP1       Name: Definition of the Scenarios to developed
Start Date: M0                              End Date: M0,5
Description:
T1.1 This work package will complete the set of scenarios: End User and Hotel. The
scenarios will be fully specified.
The definition will take into account the current functionalities of the application to
integrate.
Expected results:
D1.- Document the features to be integrated and the scenarios in which the application
is integrated.
Milestones and dates:
D1 completed in M0,5
WP2       Name: Common analysis of the scenarios
Start Date: M0,5                               End Date: M1
Description:
T2.1. Every scenario will be analysed and detailed. It will be analysed the business
case, the agents (applications) involved, the message flow with the detailed
parameters of every message, possible forks and joins, error cases, …
Detail individual analysis of the interface of the individual application to the DBE.

T2.2. Define and develop the contents using the BML (Business Modelling Language)
tool for the specific scenarios/use cases. This will allow the testing of the functionalities
of the BML Tool.
Expected results:
D2.- Document: Analysis with the set of scenarios in the present document.
Milestones and dates:
D2 completed in M1 without the BML specification.




WP3       Name: Development of the Adaptor
Start Date: M1                                 End Date: M3
Description:
T3.1 Drivers will use the DBE platform using the different services developed and will
learn how to use the SF and the ExE and adapt services to it. DBE example services
are in principle simple services but are very helpful in order to learn the main modules
of the SF and the ExE and the steps to create an adaptor and deploy it.

T3.2 Development of the adaptor to integrate the existing applications to the previous
defined scenarios through the DBE.



Expected results:
D3.1 New version of the SW Application with the adaptor to the DBE.
D3.2 Introduction of the information requested in the SF Tools.
Milestones and dates:
D3 completed in M3
WP4       Name: Test
Start Date: M3                                End Date: M4
Description:
T4.1 Install the ServENT in one of their machines with a public IP and the needed
ports open (2002, 2727, 2728). The corresponding adaptors to the individual
applications will be installed in the ServENT.
T4.2 Execute a set of test to show that the different scenarios works and are
integrated through the DBE. It will be checked the scenarios using the DBE distributed
and discoverer features. Further explanations will be provided by the time the tests will
be executed.

Expected results:
Execute the test and share the test results in the foros.
Milestones and dates:
Tests result information shared in the foros in M4.


WP5       Name: Deployment in real users
Start Date: M4                                End Date: M4,5
Description:
Install the new version of the SW application in 2 final users. Then, install the adaptor
to those applications in the ServENT



Expected results:
New SW installation and network configuration in order to integrate the final Users.
Milestones and dates:
New SW installation and network configuration in order to integrate the final Users.


WP6       Name: Feedback from Drivers and Users
Start Date: M4,5                              End Date: M5
Description:
Provide feedback, both SW Developers and Users about the experience in the project
about all aspects.

Expected results:
D7 Document with the feedback from Drivers and Users.
Milestones and dates:
D7 completed in M5
4.2 GANNT CHART

DBE<>SIDUS-CAW Months->         0,0 0,5 1,0 1,5 2,0 2,5 3,0 3,5 4,0 4,5 5,0   MM
 Definition of scenarios                                                      0,5
 Common analysis of scenarios                                                  1
 Devlopment of the adaptor                                                    2,5
 Test                                                                         1,2
 Deployment                                                                   0,5
 Feedback from drivers&Users                                                  0,3
                       TOTAL MM                                                6
5 PROJECT BUDGET AND REQUESTED FUNDING
The following table shows WP cost distribution. The applied resources correspond to a
Project Manager and to a Analyst Programmer. Costs per MM are also shown.
The financial model applied is the FCF with a 20% of overheads.

                                                     Project Manager      AP
                                       Cost per MM         4.100,00 €   3.200,00 €
  DBE <> SIDUS-CAW                      Total MM          MM            MM           WP Cost
  WP1 Definition of scenarios              0,5            0,3           0,2              1.870 €
  WP2 Common analysis of scenarios          1             0,2           0,8              3.380 €
  WP3 Devlopment of the adaptor            2,5                          2,5              8.000 €
  WP4 Test                                 1,2            0,3           0,9              4.110 €
  WP5 Deployment                           0,5            0,2           0,3              1.780 €
  WP6 Feedback from drivers&Users          0,3            0,1           0,3              1.370 €
                               TOTAL MM     6             1,1            5              20.510 €
       Cost Model FCF (20%) Overhead                                                       4.102 €


         TOTAL PROJECT BUDGET                                                        24.612,00 €

According to the tender rules, a 50% of funding is requested. TOTAL 12.306.00€

				
DOCUMENT INFO
Description: Fleet Management Taxi document sample