| Fleetster is a reference solution that showcases the extensibility of the Axeda Platform. You can see the live Dashboard and Mobile apps here in the Developer Connection site as you follow along through this tutorial. After learning more about the construction of these applications, you will begin to understand how easy it is to take a web application from concept to completion in only a few days.
As a mobile workforce management application, Fleetster features workflow integration, alerts management, location-aware tracking, and statistics on driver behavior. There are three parts to this solution:
Let's begin with a look at the telematics unit that transmits the information. |
Visit the M2M AppGarage to see how Axeda and its partners built this Fleet Management reference application.
|
Telematics
The Vehicle Telematics Device used in Fleetster is a Datalogger by Danlaw. The unit reads data from the vehicle engine such as speed and acceleration. It is equipped with GPS to make location data available as well. The Datalogger uses the Axeda Wireless Protocol over the cellular network to transmit the data to the Axeda Platform, where it is accessible to the Fleetster application.
Mobile App
As a driver, I log in and record my work activities as they happen during the day. The large, clickable icons make Fleetster easy to pull out of your pocket, click an activity, and put back.
Maintenance items, such as a completed oil change, are also entered through the mobile app.
Behind the scenes, each click registers a workflow transaction that feeds statistics about driver behavior into the fleet manager's overall picture of the daily operations of the workforce. The fleet manager can stay aware of drivers missing their breaks, neglecting their vehicles, or racking up unnecessary miles between jobs.
Dashboard
The Fleetster Dashboard tracks driver behavior and vehicle maintenance over time and provides a range of top-level to detail views. The reports can be customized to present information in any format desired.
As a fleet manager, I can log in and see driver activity and vehicle location.
Selecting a driver, I can view recent work items that were automatically read and submitted to Axeda. Selecting a vehicle, I can track maintenance done and view items due or overdue.
Shown - Wall tab - notable recent items, driver activity throughout the day
- Statistics tab - data table with recent work transactions, sortable by time or activity type
- Trends tab - pie chart with total amounts of time spent on any one activity
- Contact tab - contact information for the driver
- Side panel alarms - actionable information, overdue maintenance items or breaks missed alerts
- Vehicle Link - link to vehicle information such as maintenance history, which brings up the following screen:
Shown - Maintenance Due tab - an indicator showing maintenance overdue and upcoming maintenance
- History tab - a data table with maintenance history
- Back Button - navigation back to the home page
The workflow and maintenance items entered by the driver through the mobile app become available in the dashboard for monitoring.
Now that we've seen how Fleetster works, let's take a look at the code that makes it happen.
Dive into the Code
The Dashboard relies on nine Groovy scripts, four javascript files, and one HTML landing page, while the Mobile UI depends on eight Groovy scripts, three javascript files and one HTML landing page. We'll take a brief look at the most important of these to see how they work together to form Fleetster Mobile. Additional comments and information may be found in the source code, included in the zip file at the end of this article.
Groovy Scripts
The most important of the Mobile UI Groovy files is FleetAddShiftTransaction.groovy, which processes each icon click to register a workflow transaction. It uses the ExtendedObjectBuilder and ExtendedObjectHelper classes as shortcuts to the Extended Object SDK.
FleetAddShiftTransaction.groovy takes the following parameters:
- usernm - REQUIRED - The name of the calling user/driver
- day - OPTIONAL - a date string in the format YYYYDDMM
- time - OPTIONAL - a time string in the format hh:mm, provided in 24 hour time rather than AM/PM
- type - REQUIRED - a one word transaction type, such as onDuty
- detail - OPTIONAL - an integer that represents a menu level corresponding to each activity, 1 for top level menu, 2 for next level menu, and so on
The script starts off by defining a function that reformats the date string into a Java Date Object. Then it creates an ExtendedObjectHelper object and an ExtendedObjectBuilder. The ExtendedObjectHelper adds shortcut functions like store and delete that make it easier to work with Extended Objects. ExtendedObjectBuilder extends the native BuilderSupport class for creating Extended Objects. Next it creates a Context, a UserFinder, and a DeviceFinder.
The key point to realize here is that each driver exists both as a User and a Device, and the shift transactions are stored as an Extended Object accessed by the User id. Here we retrieve the driver as a User first so as to find the shift Extended Object, and second we retrieve the driver as a Device which is associated with the vehicle Device. Now that the vehicle information is available, we can also find its Current Mobile Location.
Now we're ready to work with the Extended Object. First, we use the ExtendedObjectHelper to search for a shift referred to by the driver User id and identified by the day string received as a parameter. In other words, if we're looking for Ted Nugent's shift on September 1, 2011, we'll search for a shift with "tnugent" and "20110901" as identifiers.
Using Groovy's closure feature, we use the shift object to create a list of transactions ready to be rendered as JSON output at the conclusion of the script. Next we add in the newest transaction, triggered by the icon click in the mobile app. The updated transactions list is then sorted by time, and used to create a summary list that represents total time spent in each activity. The old shift object is deleted, and the new shift object is created using the summary and transaction lists.
The Groovy script could end here, except that this script serves double duty in triggering alarms when drivers have missed breaks. This task could also be created as a scheduled task, but for reference purposes it is included in this script.
Now let's take a look at the Dashboard Groovy scripts. Since the Dashboard is dedicated to viewing information, almost all the scripts retrieve subsets of data about drivers and vehicles, rather than add to the data.
The most frequently used Dashboard Groovy script is FleetGetDriverShift.groovy . This script retrieves a shift object and outputs it as JSON. It takes the following parameters: day - (REQUIRED) - a date string in the format YYYYDDMM deviceId - (OPTIONAL) The vehicle device id
usernm - (OPTIONAL) The driver username - either vehicle device id or the driver username must be supplied This script starts off almost exactly like FleetAddShiftTransaction.groovy. In fact, the main difference is that FleetGetDriverShift.groovy only retrieves the shift and doesn't add in a new transaction.
Javascript
Now that we have the data available to our web application, let's take a look at the javascript that retrieves that data and displays it. In the Mobile UI, we used Dashcode to build the underlying mobile application. Please refer to the linked tutorial for details on that aspect of building the project. We will focus on the javascript that enables the connection to the Axeda Platform. In the Dashboard application, there is a single function that handles all the calls to Scripto. This approach allows ajax calls and error handling to happen in only one place, enabling easier debugging. For example, App.callScripto, the Dashboard callScripto function, is used in the App.showDetailPage function, which creates the view that pops up when a vehicle or driver is clicked in the browsable list on the left of the Dashboard. The callScripto function is called in the following manner:
App.callScripto("FleetGetVehicleHistory.js",{deviceId: id}, function (details) {
Here the deviceId is the parameter and is passed in when the function is called. The results are available to the callback function as a JSON object stored in the variable "details" that can then be displayed on the page.
In this discussion of Fleetster, we've seen how a telematics device, mobile app, and dashboard work together to capture information about the daily operations of a mobile workforce. We've also taken a look behind the scenes and observed how the javascript and Groovy code creates a flexible, extensible solution.
The source code is available as an Artisan project. Remember to add your credentials into build.properties before uploading.
The source code and a tour of the Dashboard and Mobile UIs are available from the following links:
