Big Apple Car: Calling all drivers via real-time tracking and accurate closest-car dispatching

Real-time widgets inform non-technical staff of technical issues for speedy resolution

Client profile

New York-based Big Apple Car has served the ground transportation needs of clients traveling throughout the tri-state area since 1983. When the company had driver dispatch issues with their Pick BASIC program, Sierra Bravo helped analyze their business needs and resolve them through program modifications.

Big Apple Car created its own highly-sophisticated application, but it had some difficult-to-track issues within the network interface components. A wireless internet gateway (WING) server acted as a gateway between their dispatch system and computers in cars. The WING server is a software package that runs on a Windows server and waits for a connection from a WING client — in their case, custom-developed Pick BASIC program established a connection and sent messages to the cars and receives messages from the cars over this link, including current GPS coordinates.

Objectives

Big Apple Car’s WING server would, from time to time, quit relaying messages to and from the WING client program. The Pick BASIC program lacked appropriate error-detection and link status analysis, making it difficult to see if outgoing and incoming messages were being processed, and difficult to tell if outgoing messages were actually being relayed to the cars. Furthermore, it was difficult to determine the point of failure in the system. Recovery from a failure required a reset of all software programs and related networking hardware.

Solutions

Sierra Bravo recommended a series of improvements to the client program to provide activity logging to identify points of failure. In addition, performance improvements, redundancy and automated failure recovery logic was added to the client program. This modified client program is a more reliable connection with the WING server and more capable of detecting and resolving problems with the network connection and in other layers of the application.

Additionally, we recommended that the new client program log statistical information regarding the messages sent and received and a web application be developed to display these statistics via a widget on a web browser, which automatically refreshes the window every few seconds to show the number of messages sent and received.

Incoming Message Processor

This program handles incoming messages from the cars; each message, in turn, generates a response back to the car. This program runs as a background process, constantly scanning an “inbox” queue for messages received by the WING client program. Each program handles a specific request and ultimately produces some sort of response — which may generate a list of open stands, acknowledging or rejecting the driver’s request to be added to a stand.

Situation

Originally, this program was designed to run as a single instance and processed each request sequentially. Since some requests take longer to process than others, this program could get behind on responses, causing delays in the driver’s button-press being processed or acknowledged. This would result in the driver pressing the button again, resulting in further delays.

This program had been split into two separate programs allowing to simultaneously process requests received by drivers. This two-stranded approach improved the situation, but still didn’t provide the immediate response drivers expected from the system since either, or both, could get behind. Since each program handled a different class of messages, the load-balancing on the two strands was not optimal; one program could be all caught up and waiting for something to do while the other had several messages backed up in the queue.

Solutions

We redesigned this program to run in a 100 percent load-balanced manner, allowing each instance of the program to process requests in a first-in-first-out basis. This allows for as many threads as necessary to run and process the incoming message queue, resulting in a more immediate response to the driver’s button-press and reducing the number of redundant button-presses.

Because some programs handling certain messages take several seconds to run, they were reviewed to determine if more efficient methods could shorten the process.

Sierra Bravo created a program to feed statistical information to the web-browser screen so users could also see the types of messages being processed and how many unprocessed messages remain in the queue. This information helps determine how many instances of this program should be running for optimal performance.

Dispatch – Background Processes

Situation

All background processes need to be running at all times for the system to work properly. Though none of them should fail, they could get stuck or stop running due to several possible problems. While not immediately evident that one of these processes had quit running, the only way one might notice that one had stopped was that some part of the system was not functioning. For example, if the process managing GPS coordinates of cars quits running, it may take a while for users to notice that the system doesn’t know locations of cars. There needed to be a way to identify problems and observe the performance of each of background process.

Solutions

We reviewed each process to determine if some could be combined into a single program. This would reduce the overall effort required to manage the processes and simplify any programming required to create a system to manage them.

We expanded the web-based monitoring program to include the status and idle time for each process. The programs were updated to add a time/date stamp of the last activity so that an “idle time” for each process could be determined. The web-based monitoring program displays each background process along with its idle time and a color-coded status indicator — where a green light would indicate that the program was functioning, waiting for requests. A yellow light would indicate that the program had gone beyond its typical idle time and may be ready to move into a red state. The red light would indicate that the program had been idle beyond acceptable limits and likely needed to be restarted.

Results

The solution that Sierra Bravo provided revolved around the performance and monitoring enhancements made to the existing application. Sierra Bravo’s engineers succeeded in identifying and understanding the specific areas of the application that were failing. Each application was then reviewed and modified to meet performance and reliability requirements.

“Sierra Bravo is good at diagnosing problems, efficiently resolving them, and then monitoring our system from a distance,” said Big Apple Car’s Paul Radovsky. “They bring the whole menu of tech solutions, from soup to nuts.”

The modified application ultimately saves time in identifying and resolving system problems. It also reduces the overall cost of maintenance; since the monitoring program can tell users exactly where the problem is, tech support can find the problem much faster. This information was used by the programmers to make adjustments to the system to eliminate future occurrences of problems whenever possible, resulting in a more reliable solution.

This web-based monitoring program/widget provides a single-screen view into several aspects of the system, including the status of all the background processes along with a health indicator. It shows the traffic on the WING server for incoming and outgoing messages processed on an interval. It also shows overall system performance as well as a list of the processes (and port numbers) that are consuming a large amount of the CPU. Furthermore, the monitoring system provides an easy-to-access audit trail of communications between the dispatch system and the drivers, allowing dispatchers to quickly view and discuss activity with drivers and answer questions as needed.

“At Sierra Bravo, they think of things others wouldn’t,” said Radovsky. “With the widgets Sierra Bravo created, our non-technical staff can quickly and easily identify and pinpoint issues. This had made solving problems easier for our company.”

Back to Case Studies