The “Phone Home” Pattern and Roles in the Transit Appliance Ecosystem

The core idea for transit appliances is that they are from a user perspective, very simple devices. Ideally the only control is an on/off switch.

To support this and to support deployment at scale, you want a device that can simply be installed and then remotely configured and managed. This leads to the ‘phone home’ pattern – the idea that when an appliance is powered up, the first thing it does is ‘phone home’ to get its configuration information. For our Insignia Infocast prototype this looks like a simple HTTP GET request passing the MAC (ethernet) id of the device as its identifying information. Here’s a diagram of the interactions that then ensue:

Here’s the sequence described:

  • The appliance “phones home” with a unique id and gets back a URL pointing to a configured application (assumes the full configuration can be described in a URL).
  • The appliances uses the URL to fetch its “application” (an application in this case being an HTML page with Javascript [or conceivably Flash] logic embedded).
  • The application then issues an ongoing series of AVL queries to the data provider (running for hours, days or even weeks).

So who are the parties in this ecosystem?

  • Appliance providers – provide hardware platforms that can display web pages. These can be viewed as “web browser kiosks” at the simplest level (although they do not need to provide user input devices like keyboards and mice or touch screens).
  • Configuration providers – provide a user interface via which configurations can be established and maintained specifying what devices use what applications and display what set of arrival information.
  • Application providers – provide alternative ways of displaying arrival information for various use cases.
  • AVL Providers (probably mostly transit agencies) provide access to the actual arrival data.

What are the relationships that need to exist in this ecosystem?

  • Appliance providers MUST partner with configuration providers. An appliance has to know where it ‘phones home’ to. An agreement must exist that the configuration provider will answer!
  • Configuration providers must have knowledge of application providers, but don’t necessarily have to have a formal relationship if the application providers have made their URL configuration formats open and accessible.
  • Application providers must know how to get AVL data from the data providers.
  • AVL providers (transit agencies) don’t have to do anything other that document the interfaces to their data.

Obviously a single entity can play more than one role. To take TriMet’s Transit Tracker as an example, the user is the appliance provider, using their PC as the appliance and TriMet plays all three other roles: configuration provider (menus to select stop), application provider (display of arrivals) and the AVL provider (populating the arrivals).

It’s not clear to me yet how roles will break out in the real world, but I can tell you that in trying to bootstrap this ecosystem Portland Transport is going to try to play three roles:

  1. Appliance provider – we’re going to at least prototype several types of appliances (the Infocast being the first, I also want to get something wall-mounted, probably driven by a cheap PC, out there as a prototype). We may continue to play this role in the Portland region, working to get the hardware widely distributed, but have little ambition to supply the actual appliances outside Portland. We may also find it more effective to identify partner organizations that can do this more efficiently than we can.
  2. Configuration provider – this is the service we’re working hardest on at the moment. This feels like an organizing role in the ecosystem, bridging the various other partners. We’re going to open source all the code involved, so other people could get into this, but it’s not clear to me why multiple configuration providers are an advantage in the ecosystem, so maybe this is an enduring role.
  3. Application provider – my hope is that there are many, many of these so we can provide users with lots of alternatives. But we’ll continue to develop Transit Boardâ„¢ as an example in this category. And we may provide software components to make it easy for other people to develop applications.

Does this identification of roles and relationships make sense? Who are candidates to fill the various roles? Are there different ways to think about this ecosystem?

This entry was posted in Architecture. Bookmark the permalink.

2 Responses to The “Phone Home” Pattern and Roles in the Transit Appliance Ecosystem

Leave a Reply

Your email address will not be published. Required fields are marked *