AVL: User Interfaces

User Interfaces (UIs) are by definition the most visible part of any technology project. For brevity, both dispatcher and passenger-facing UIs are lumped together. This is not my specialty; rather than rehashing details, I’ll point out two excellent sources for introductory content, and then cover a couple questions that must be considered when buying an AVL product.

Usability.gov maintains an excellent library of public-sector focused content related to usability, user interfaces, and user experience. This article might be an excellent entry point. If that seemed too simple and you’d like to get your feet wet, check out the lessons at Hack Design.

Before beginning procurement, the most crucial UI-related decision is what are the use cases for the product?

UIs are typically distributed as a client or via a web-interface. Regardless of the choice, the two most crucial technical questions surrounds the dependencies required– are there any required libraries or plugins for it to function, and will it run on a tablet or smartphone? While PCs are currently standard issue, the marketplace is changing rapidly. Even if mobile devices are not in your requirements, during the life of your AVL project someone will want to access the system on one.

Finally, no web-based user interface should be accepted if it does not run on a recent version of Chrome, Safari, or Firefox on a desktop computer. Some AVL vendors are still hocking products that require outdated versions of Internet Explorer, and these should be avoided like the plague. Similarly, plugins such as Flash and Silverlight are slowly dying and are a constant source of security vulnerabilities; any system requiring them should be considered carefully.

Fill in the blanks

The second mistake was to adopt a narrow view of the type of […] people have always […], as if all habits were deeply rooted traditions instead of accumulated accidents.

Clay Shirky, Cognitive Surplus

AVL: Traccar

Traccar is a free, open-source AVL package. If your use case is primarily plotting device locations on a map and you can gather some moderate technical resources, it is a great option for you.

I like it for the following reasons:

  1. It has comprehensive support for a plethora of devices, including an Android (and soon iOS) client application, purpose-built trackers, and modems with embedded GPS.
  2. It is very easy to set up on Windows, Mac, or Linux.
  3. The project author is friendly and very responsive.
  4. It is reasonably well-architected and easy to modify, unlike its competitor OpenGTS

 

AVL: Assignment

Assignment functionality takes location data and turns it into information by linking that location to scheduled piece of work (e.g. a transit trip or a delivery itinerary). It is a crucial, yet opaque component of an AVL system. Each AVL product will have a different take on the problem, with different requirements from input data and operator/supervisor interaction.

Assignment sits on a continuum between Explicit and Implicit or Inferred. Explicit assignments are made by an operator or system that assigns a piece of work to a vehicle. Assignments are often provided by a vehicle operator entering their assignment into a device on the vehicle, or a dispatch system with prior knowledge of which vehicle(s) will perform which assignment. Inferred assignments are made by a process that analyzes the vehicle’s recent behavior to guess what piece of work it is serving. Inferring assignments are more complicated in dense networks, where multiple assignments can be likely.

If you are procuring an CAD/AVL/RTPI system, questions to ask about its assignment system are:

What is the interaction that operators are expected to have with the system? Do they have to interact with a new device? What does that interface look like? Specifically, how many new keys do they have to press? Will there be labor relations issues as a result?

Does the system rely on assignment data from an external system (e.g dispatcher entry)?

What validation is done against operator or dispatcher entered data? Can an operator enter incorrect data?

 

What level of intelligence is on the vehicle? Most “computer-on-a-bus” solutions download the entire schedule to the bus and can store data for later transmission when losing connectivity. More simple on-board systems do not store any information on the vehicle; they send only the information they have. How/when are are data on vehicles synchronized?

 

How flexible can the system be when deviating from expectations? For example, how does it handle detours? What about extra unscheduled service?

What does the assignment system it telling you? Does it ever display expected (rather than actual) information? Does it tell you the difference between the two?

AVL: Communication

Communication is the most “magical” of an AVL system’s components– it carries information over the ether from vehicle to server, and when it works, it just works. It is also the most well understood of these components, so this post will focus solely on things to watch out for.

Cellular:
Most AVL systems are now using cellular communications. Hardware is easy to acquire, costs are somewhat reasonable, and speeds are more than enough for low bandwidth applications.

One thing to watch out for is the the “sunsetting” of 2G and 3G networks. In the US, wireless carriers will be shutting down 2G and 3G networks as soon as 2016 (AT&T), and possibly as late as 2020-21 (Verizon). At this point, solutions that provide no upgrade path to 4G should not be considered for the long run.

Private/Packet Radio:
Packet radio is what has traditionally powered AVL communication. Older AVL-over-radio systems suffer from very long update intervals– often 5-10 minutes between position updates. Most new systems have much shorter intervals, but it is crucial that you know what the update interval is, regardless of technology or age. Some unscrupulous vendors are still selling systems of a previous generation.

Mesh
Long touted as the next big thing, mesh networking has never taken off commercially. The industry has not given up hope =iIt is still seeing new research. Be wary if it is proposed; the supplier better have a good testing and backup plan.

AVL, CAD, and Real-Time Passenger Info for Beginners

Real-time Automated Vehicle Location (AVL) has now become a commodity product. Unfortunately, some companies are using commodity as an excuse to pass off incomplete or unsuitable products to unsuspecting buyers.

This series introduces the concept of AVL and its extensions, Computer Aided Dispatching (CAD) and Real-Time Passenger (or Customer) Information (RTPI). Each of the following sections introduces a key component. The goal of these posts is not to convey mastery, but to get an idea of the right questions to ask. For a more generic introduction see TransitWiki.

The components I will cover are:

Location locates a vehicle,
Communication carries locations to a server
Assignment informs about on what that vehicle is doing,
Dispatcher User Interfaces are used to managing service,
Passenger User Interfaces help passengers, and
APIs allow developers to connect systems and build new interfaces.
Monitoring systems help the operators keep the system up and running.

The difference between AVL, CAD/AVL, and RTPI products is the combination of these components. I’ll refer to a solution that includes all of them as the “Full Stack”. You’ll find their definitions below the fold.
Continue reading “AVL, CAD, and Real-Time Passenger Info for Beginners”

Getting a non-tech organization to adopt Open Source

This post at opensource.com describes one librarian’s experience with getting his employer to use Open Source software. He makes an interesting point:

By choosing my words carefully and avoiding these four words, I successfully brought open source to our team.
Open source … Free … Contribute … Development

I draw the following conclusions:
The first rule about getting an organization to adopt open source software is to not talk about open source.
The second rule is to NOT TALK about open source.
The third rule is to get buy-in and do it.

Three Great Talks from Write The Docs

I had the absolute pleasure of attending the Write The Docs conference in Portland last week. Write the Docs is “a time and a place for this community of documentarians to share information, discuss ideas, and work together to improve the art and science of documentation.” It was one of the best conferences I have ever attended, with interesting presenters and people across the board. A crazy compendium of notes and links on talks and presenters is here.

The top three talks I saw were:

Brian Troutwine’s talk on instrumentation and complex systems is something that anyone who manages a real-time (e.g. AVL, SCADA, etc.) system should watch. He begins with pointing out that complex systems fiendishly dif­fi­cult to com­mu­ni­cate about. This gap of under­stand­ing is dif­fi­cult to bridge in doc­u­men­ta­tion. Instrumentation combined with documentation is really where the magic happens, and where you see the system actually work.

If you don’t know how the system should behave, you can’t say how it shouldn’t.

IF YOU DON’T TRUST A COMPUTER BECAUSE SOMETIMES IT DOESN’T TELL YOU THE TRUTH, TELLING IT TO TELL YOU TO TRUST IT IS ASKING IT TO LIE TO YOU SOMETIMES.

 

Maxwell Hoffman’s talk on writing for a global audience fit the theme well. He points out that by following
10 rules from standardized aerospace engineering English, our writing can not only be more clear, but better understood in translation. Sadly, the video is not available but notes are.

Millenials are re-incarnated people who died in 60s. They use active voices.

 

Finally, Christina Elmore’s talk on Death by Documentation takes a hard line on the difference between presentation and documentation, and meetings versus conversation. In it, she references two great (and free!) resources: Nancy Duarte’s Resonance Book, and An Introverts Guide to Better Presentations.

Work to elim­i­nate the pre­sen­ta­tion within your orga­ni­za­tion.

Introduction

My name is Tony and I’ve spent most of my career putting GPS on buses.

This blog exists to introduce transit people to technology, and tech people to transit. I will cover a breadth of topics, from the philosophical, to practical, to deeply technical.

I believe in sharing my experience in a clear, concise, accessible, and vendor-neutral (no sales pitches!) manner.

I will be happy if this blog is a fraction as helpful to the industry as Jarrett Walker’s Human Transit blog.

FAQs are below the fold.
Continue reading “Introduction”