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

  1. Multiple configuration providers are useful, if for no other reason, than to establish redundancy. And, depending on how much “local knowledge” is required, having different configuration providers in different locales may be crucial. Perhaps you intend for all of the local knowledge to be handled at the application/data provider level, but there’s still the question of what application provider to use.

    And a configuration provider may also be able to provide other value-added services (display ads, weather information, sports scores, what-have-you) that is outside the scope of a “transit appliance”. Indeed, with this architecture, it’s possible that “transit appliances” might not be used to display transit information at all! (Likewise, were transit appliances to become a commercially successful enterprise, I would expect that many vendors would bundle devices with configuration provision–perhaps to the point of hardcoding the configuration provider, and programming the device to interact with nobody else).

    One other question: Will (or might) transit appliances have GPS receivers in them–thus enabling them to figure out that they are stationed (for example) at the Starbucks near Powell and 39th, and that therefore they should display arrival information for the 9, 75, and 66, without requiring any other configuration?

  2. Chris Smith says:

    Scotty, a couple of observations in response:

    1) I think it is likely that appliance suppliers WILL hard code a configuration provider, it’s the simplest thing to do.

    2) Integration of advertising or other information is more likely by the application providers. The architecture under development would support capturing options for such things as part of the configuration process.

    3) The ‘automatic configuration via GPS’ model is certainly possible, but unless you had an appliance that was going to be mobile, the economics of adding hardware to avoid a one-time operation seems questionable. It is possible that configuration could be reduced to providing an address (show all transit stops within 1/4 mile for example).

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>