1.

INTRODUCTION
Cloud mobility software is to be an integrated smart transport management solution to facilitate in the
deployment and operations of public transit systems while linking effectively all users incorporated in the
transport system operations.

1.1. PURPOSE
• Integrated traffic and mobility management
• Demand based management and fleet deployment i.e., routing, navigation, scheduling.
• Multimodal transit data integration.
• Real time Publication of mobility information in open mode through various platforms such as
onboard/station PCB displays, mobile APP, web-based platform etc.
• Travel time management system
• Traffic data modeling and simulation.
•

1.2. INTENDED AUDIENCE AND USE

1.2.1. PASSENGERS
• Make payments
• Self-service payment verification.
• Route, boarding and offboarding station selection.
• MOBILEAPP/WEB Software utilization to monitor/track ETA, bus operations relative to
other buses, stations, terminals.
• Give feedback, structured and unstructured through respective channels
• MOBILEAPP/WEB Software utilization to track private travel trend.

1.2.2. TRANSPORT COMPANY

i. FLEET CONTROL
• Allocate and monitor real time bus route deployment variables.
• Monitor passenger demand along various routes in real time.
• Access fleet KPI status e.g., utilization, availability from maintenance.
• Monitor and evaluate fleet depreciation trend.
• Analyze bus sweeping efficiency in ferrying passengers across stations by monitoring
passenger clearing data.
• Approve fleet operation expenses for payment requests (fuel, excess operating hours
etc.).
ii. OPERATORS
• Operate buses along allocated routes
• Monitor active operating buses along the route
• Monitor onboard and on-station passenger direction information (terminating
points).
 • Book maintenance schedule in case of an emergency breakdown or planned
preventive maintenance.
• Handle passenger drop-off requests made from Bus signaling switches, MOBILEAPP
or WEB BASED software.
• Issue tickets; verify payments
• Assist passengers.
• Act as dedicated data collectors to facilitate route mapping.
iii. MAINTENANCE AND WORKSHOP
• Receive and handle PPM/CM schedules
• Clear attended vehicles ready for use
• Record/maintain fleet diagnostics history.
• Request consumables, spare parts, tools for fleet maintenance
• Schedule due planned maintenance
•
iv. FINANCE AND ACCOUNTING
• Track payments made; income attained
• Approve payments for requested fleet expenditures
v. IT/SYSTEM ADMIN
• Support, debug systems
•
vi. PROCUREMENT
• Procure spares, consumables as requested from maintenance and by monitoring
trends of requests.
• Request payment for procurements raised.
vii. MANAGEMENT
• Access real time income revenue dashboard
• Access real time bus deployment statistics
• Access real time passenger information statistics
• Access real time evaluation trend.
• Access real time metric forecasting (e.g., revenues, running costs, fleet depreciations,
YoY parameter indices, market growth propensity growth etc.).
• Access real time customer segmentation data.

1.3. SCOPE
• Passenger boarding and exiting data selection should provide variables to generate a bus route
demand algorithm i.e., the station with high boarding/exiting requests to be allocated more buses
priorities to ply the routes.
• Exiting stations selected to be studied on how much they have been utilized as exit points (i.e.,
obtain the percentage of which the exit points selected have been successfully utilized as exit
points) to obtain the deviation rates with which the selected exit points were not utilized so as to
model passenger behavior of the factors which would lead to passenger’s selection not to be
implemented.
• Online payment and earnings disbursement to operators, government, system developers,
institutions or payment collection to government (GePG) and generate a payment debit order for
every booking payment made thru the system.
• Bus arrival API display on each station with real time bus information (headway, terminating
points/route code) for all buses within the network proximity along the route.
• Buses should be fitted with transponders that transmit real time data for direction/terminating
point and respective headways between buses along its operating route as well as towards
stations in proximity while simultaneously receiving information about each station the approach
in real time for displaying in on-board PCB displays and for voice assist announcing immediately
when closing in on the station and boarding platform. If possible, bus route/terminating point
should be announced with automated voice assist once the bus is parked on station, ready so that
the boarding passengers will be made aware of the bus terminus.
• Have card payment options which can be linked with digital/mobile accounts as well as scannable
ticket payments. User’s account should enable tracking of passenger’s travel history, payments
made, security notifications, account access authentication, as well as be able to top up account
wallet, view credit etc.
• System should incorporate self-service ticketing and payment verification infrastructure to
facilitate 24hrs operations especially for clients with no digital platform access for bookings and
accessibility.
• Track tickets from boarding access to offboarding access. This is so as to monitor passenger
duration trends within the BRT ecosystem. Transit duration averages, minimum between similar
points, averages? And the contributing variables affecting that e.g., delayed bus headway,
excessive passenger demands, accidents, bus sweeping insufficiency etc.
• Passenger feedback structured feedback mechanism. Like how long does it take between
boarding the station access, to boarding the bus, to offboarding the station? And the contributing
variables to such observation data. This should be made easier through the deployed Mobile APP
or web-based user Platform.
•

1.4. DEFINITIONS AND ACRONYMS

i. ETA- Estimated time of arrival
ii.

2. OVERALL DESCRIPTION

2.1. USER NEEDS

2.2. ASSUMPTIONS AND DEPENDENCIES

3. SYSTEM FEATURES AND REQUIREMENTS

3.1. FUNCTIONAL REQUIREMENTS

3.1.1. USERS
i. PASSENGERS
• Access mobile app or web-based platform
• Book tickets online
• Choose boarding and exiting station
• Make payments and self-verify payments via fixed scanning equipment and system
generated scan codes (QR, BAR etc.)
• View real time multiple buses and user location via dedicated platforms.
• View buses in transition while on station to know the buses approaching the station as
well as their respective ETA and terminal directions.
• View transport history i.e., movements made, respective payments made, frequent
stations boarded and offboarded, duration covered in transition, distance covered in
transition etc.

ii. OPERATORS
• Confirm deployed allocations e.g., route scheduled, activity transfer
• Report tasks e.g., equipment troubleshooting etc.
• Book tickets for clients outside the cloud platform ecosystem
•
iii. MANAGEMENT
• Schedule bus route deployment
• Authorize bus operation clearance
• Oversee and counteract bus route operation variables e.g., headway, bundling, passenger
demand, position, sweeping capacity etc.
• Request and approve fleet activities transfer e.g., from operations to maintenance
• Evaluate fleet KPI
• Extrapolate scheduling allocations based on demand data.

3.1.2. SOFTWARE
• Generate payment codes for passengers
• Monitor passenger count within the buses, stations, and terminals and their transitioning
rates.
• Monitor bus sweeping capacity and provide necessary evaluation step to be taken
• Offer web based and mobile app UX/UI for various type of users.
•
•

3.1.3. HARDWARE
• Payment verification devices and accessibility control turnstiles.
• Real time passenger count scanners within the station, terminals and buses.
 • .

3.1.4. NETWORKS AND COMMUNICATIONS

3.2. EXTERNAL INTERFACE REQUIREMENTS

3.3. SYSTEM FEATURES

• System should be available on the internet
• System should utilize cloud computing features
• System must be available 24 Hrs. a day
• System must be accessible by both mobile apps and web browsers
• System must be able to generate/process, accept and verify electronic payments
• System should enable users to authenticate their own devices for secured account login
verification on the devices that may try to access their respective user accounts.

3.4. NON-FUNCTIONAL REQUIREMENTS

• All Data transmissions should be securely encrypted
• Real time vehicle location should be accurately and precisely updated to the most
relevant current position at any time and position.
• Enhanced Secure data hosting for client’s data privacy and security.
•