Saturday, good mood is a weekend feature.

Case Study: DB Schenker Loco Planning

May 9, 2012by Andrei Dragomirin Development, Projects1 Comment
Screen Shot 2012-05-09 at 20.27.45

Loco Planning is a web application that we built for DB Schenker as part of the DBS Trip project. Its main goal is to help DB Schenker employees to plan and view locomotive assignments and route informations (such as stations, distances, departure and arrival times) in a user friendly manner.

Reasons

Before the app, the work was done mainly using Excel spreadsheets and a Windows desktop application. This kind of system lacked some great advantages that web apps could bring to the workflow.

  • Availability – data viewing and planning is not limited to a small number of machines anymore and is now available throughout the whole internal network or even the web. No particular operating system is required, nor any special software, only a web browser and a network connection.
  • Data consistency – all data is stored in a database managed by a Drupal instance, with regular backups and codebase under version control, so loss of data is very unlikely.
  • Access control – user roles provide restricted access, reducing clutter and helping employees focus only on their part of the work.
  • Friendly interface – actions are now more intuitive (drag and drop) and UI elements like calendars and modal windows help simplify the workflow. Data viewing is also greatly improved by the new, customized structure and design.

Interface

The interface of Loco planning is based on a custom grid view. The main areas are the top toolbar, the products (routes) panel, the middle toolbar and the locomotives panel.

The top toolbar consists of the following elements:

  • back button – link back to the main application
  • zoom controls – for zooming in/out on routes displayed on the grid

  • period selector – selects the start and end of the time period to be displayed. A calendar UI element is displayed when focusing on the date inputs
  • all info checkbox – when checked displays additional information on routes (departure and arrival stations)

  • sort – used to sort products chronologically, by product number, route origin, route destination or distance
  • filter – used to filter products containing specific route types (empty, loaded, single or shunting)

The middle toolbar has a locomotive filter (electric or diesel) and a legend on the right side for the various route types and locomotive assignment types.

Grid view types

Each grid unit represents a time unit, based on the selected period length. The distance between two bold lines represents a day, which consists of 1, 2, 4 or 24 units. The size of a unit is consistent across all view types (42 pixels).

There are 4 view types, automatically rendered according to the current period length, or specifically selected using the zoom tools:

View type Period length Time per unit Units per day
Day view 1 day 1 unit = 1 hour 1 day = 24 units X 1 hour
Week view 2 days – 7 days 1 unit = 6 hours 1 day = 4 units X 6 hours
Month view 8 days – 31 days 1 unit = 12 hours 1 day = 2 units X 12 hours
Year view 31 days or more 1 unit = 1 day 1 day = 1 unit X 24 hours

Locomotive assignment and other interactions

A locomotive is assigned to a route by dragging the desired locomotive on the desired route (visual feedback is provided by a blue line connecting the locomotive and the current position of the mouse cursor). A modal window then pops up, in which the user can provide additional required info.

When clicking on a route or dragging a locomotive over it, the route is exposed (other products, and other routes on the same product are blurred), and additional info is displayed (assignments, times, stations, distances). If the route already has assignments, the first assigned locomotive is automatically scrolled in view (if not already visible), and dashed red lines connecting the route and its corresponding assigned locomotive times are displayed.

Technology

The Drupal instance exposes a REST API which returns JSON data. The application queries the API and renders the data using client side templates (EJS).

The architecture of the application is built around the JavascriptMVC framework.

API

The following table describes the main part of the REST API:

API URL Type Arguments Description
/api/loco-planning/products.json GET start_date=<yyyy-mm-dd>&end_date=<yyyy-mm-dd> Retrieves products and their routes for the queried period
/api/loco-planning/locomotives.json GET type=<electric or diesel> Retrieves locomotives and their assignments based on the type filter (all if type is not provided)
/api/loco-planning/routes.json POST Creates new routes
/api/loco-planning/routes.json PUT Creates new routes / Updates existing ones
/api/loco-planning/routes.json DELETE Deletes routes

Front-end

Loco planning consists of a number of controllers or widgets, models and views.

Controllers

Controllers in JavascripMVC are also named widgets because of the way they work. They are attached to DOM elements and listen to events (through event delegation) that happen inside the widget. We use controllers for products and locomotives, and an interface controller for other UI interactions.

Models

Models are a great way to work with APIs. In JavascriptMVC you simply define API URLs for CRUD operations and the framework does the rest. No need to write your own ajax requests, but you can do that if you really need that level of customization.

Models allow you to define conversion and serialization functions (e.g. working with DATETIME format in PHP and JavaScript Date objects in the front-end app), custom callbacks and properties, relationships and more.

We use models for products, locomotives, routes, shuntings (loading and unloading periods) and locomotive maintenances. Routes, shuntings and maintenances all inherit from a segment model which provides common functionality for these entities.

Views

Views in JavaScriptMVC are actually JavaScript templates. The framework has built-in support for common client-side templates (and you can define other if you prefer). We chose EJS since it’s the framework creators’ recommendation and they (the templates) all basically do the same thing.

Helpers

We also built some helper classes for period handling, grid positioning and measurements, modal window control and more.

Conclusion

By building this application we managed to greatly improve the workflow of the DBS employees. We reduced the set of used software tools to just one (the browser) and we provided a custom, much more pleasing working experience.

When it comes to automating and simplifying workflows, securing and centralizing data, and making a software product largely available, the old ways are just not enough anymore. Since the web is here and is one of the most reliable and fastest growing industries, it can overcome many of the drawbacks caused by specific environments and vendor software.

Combining creativity and technology, supported by this great, universal environment (the Web), is certainly one of the best ways to simplify our work and our lives, thus making them even more enjoyable.

Tags:

Andrei Dragomir

Andu is all for the money, fame and glory :). Just kidding, because he’s involved wherever he can find quality, challenges, progress, trust and creativity.

He hates the flaws of humanity like upstartness and shallowness and also...the huge numbers of cars in the world.

A nature lover, he likes trekking and catching dawn at an outdoor music festival. Being a casual guy, he thinks that minds should always be open and people should leave, more often, formalities aside.

1 Comment

What do you think?

*