Digital Signage with AT&T M2X and the Data Service Exchange

November 23, 2015 / AT&T, M2X, Elasticsearch, Kibana, WebSocket, MTA, GTFS, Digital Signage, Metro, riak / Posted By: wotio team

As with so many industries, the Internet of Things is changing the face of digital signage. With so much real-time, contextual data available, and with the ability to apply custom business logic and analysis in the cloud and send signals back to connected devices for a closed feedback loop, is it any surprise that the retail and advertising markets are taking notice? According to the International Data Corp.:

Digital signage use in retail outlets will grow from $6.0 billion in 2013 to $27.5 billion in 2018

Companies are already anticipating this trend. For example, our partners at B+B Smartworx have designed an entire vertical digital signage solution centered around their Wzzard Intelligent Edge Node and Spectre Cellular/Internet Gateway devices.

In this post, we use the data service exchange™ to combine the device management capabilities of the AT&T M2X platform with publicly available NYC subway data and an instance of Elasticsearch to quickly build out an example end-to-end digital signage solution.

About the MTA

According to its website, the MTA, or

Metropolitan Transportation Authority is North America's largest transportation network, serving a population of 15.2 million people in the 5,000-square-mile area fanning out from New York City through Long Island, southeastern New York State, and Connecticut.

And since

MTA subways, buses, and railroads provide 2.73 billion trips each year to New Yorkers – the equivalent of about one in every three users of mass transit in the United States and two-thirds of the nation's rail riders. MTA bridges and tunnels carry more than 285 million vehicles a year – more than any bridge and tunnel authority in the nation.

all those eyeballs seemed like a logical opportunity for our imaginary IoT digital signage company.

MTA integration

In order for our digital signage company to maximize the revenue opportunity that these subway travelers represent, we realized that it would need to know when a given sign is approaching a given train station. That way, the ads displayed (and the advertising rates we charged!) could be contextualized for attractions at or near each stop in real time. In other words, we wanted to create an advertising-driven business model where we could sell ad-spots on our digital signs just as if they were commercials on television, displaying commercials for companies near specific train stops as the trains approached those stops.

Rather than spec out a costly greenfield hardware solution with additional sensors like GPS to enable the tracking of signs on the trains (especially considering the satellite reception to the subway trains would be far from ideal much of the time), we decided to support a hypothetical existing installed signage base and infer the train position based on the data available through the MTA Real-Time Data Feeds service. A data service which was also, conveniently enough, already available as a feed on the data service exchange.

Interested readers may want to peruse the GTFS-realtime Reference for the New York City Subway for all the gory details, but we're sure that since you're reading this blog you have already realized that composing a solution out of existing data service integrations is much better than writing each of them yourself from scratch!

(Of course, combining web-based data feeds like the MTA and combining them with IoT device data is nothing new to For another example in the Smart City space, see how we combined traffic disruption, traffic sign, and traffic signal data from London Datastore with ThingWorx, ARM mbed Device Server, Elasticsearch, and several ARM-based devices from u-blox, NXP, and Multitech at Mobile World Congress 2015.)

About AT&T M2X

Now that we decided that we would be modeling our digital signs as a virtual combination of web-based data and actual device connectivity, we needed to select a device management platform to provision and manage the digital signs themselves.

AT&T's M2X platform provides time-series data storage, device management, message brokering, event triggering, alarming, and data visualization for industrial Internet of Things (IoT) products and services. As such, it seemed like a good fit to function as either a device management platform (DMP) or data service provider (DSP), to use terminology. Throughout the balance of this post, we will show how we used it as both.

About the AT&T M2X adapter's ability to integrate to multiple device management platforms is certainly no surprise to readers of this blog. For example, we have recently seen posts using ARM mbed Device Server, oneMPOWER, ThingWorx, DeviceHive, PubNub, Firebase, and even, just to name a few!

In a similar vein, we created an adapter to integrate M2X with In order to streamline the process of getting connected to M2X, we also made it available through the M2X developer website.

This means that we can connect and manage devices using AT&T's M2X platform and can allow them to communicate with other data services using the data service exchange--exactly the combination that we were after to allow us to model our digital signs as hybrid, or virtual devices that combine physical device data with other data feeds like the one from the MTA.

Technical Overview

With the major building blocks for our digital signage solution thus identified, we were able to sketch out an overview of the system architecture:

We decided to configure the GTFS adapter to fetch MTA data every 30 seconds using a scheduler. We would also provision a logical resource for each sign device to represent the current advertising lineup for that sign.

We were pleased to note that by modeling the data as virtual resources in the operating environment, we would be able to easily route data for specific devices or groups of devices to specific data services. For example, calculating advertising rates for different signs could be as simple as routing them to different "versions" of a data service implementing the pricing logic. In other words, the complex problem of dynamically changing the advertising lineups based on MTA updates occurring at different frequencies had been reduced to a series of simple routes and transformations of data streams within the operating environment.

While we were thinking along these lines, it occurred to us that we'd probably also want to be able to track and report on the number of times each ad spot was displayed and which sign on which train and at which location etc. It was easy to simply route all the same device notifications to be indexed in an instance of Elasticsearch. We also needed a datastore to house our advertising lineups for each sign as they were sold, so we opted for the [No-SQL]) key-value store Riak from Basho. And we did all this without breaking or even affecting the rest of the solution.

Such is the power of the data modeling and routing facilities: it enables solution providers to decouple the logical model of the data, and the services operating on various subsets of that data, from the implementation of the data services themselves. Nice.

Digital sign provisioning application

For the purpose of our simple example, a pair of web applications have been created to illustrate how custom applications can be created around device provisioning and signage data visualization. In a real scenario, we'd probably leverage another data service like ThingWorx or JBOSS to build out our user interfaces. Or for that matter, we might want to use something like the iOS or Android libraries to build a mobile app, for example.

The example train provisioning application uses a Web Socket connection to the operating environment to listen for and display the trains currently in service based on the MTA data feed.

Using an interface like this one, an operator from our digital signage company could provision which of our signs (if any) reside on a given train

resulting in the following display:

indicating in this case that a sign with a device ID of 1464a49ea6f1862bf6558fdad3ca73ce is located on train $4 1337+ UTI/WDL. In order to accomplish this feat, the train provisioning application sent a message back to the operating environment over a Web Socket connection to request a train sign device be provisioned to the given train. A quick review of our architecture diagram above will show that in turn, that message was used to register the sign as a device in M2X.

Additionally, now that the device has been provisioned in M2X, any advertising lineups for this train and its next stop can be looked up in Riak. For example, in the following screenshot you can see that there are lineups provisioned for two signs on the 01 1450 SFY/242 train, and for one sign on the 01 1454 242/SFY train.

M2X as a device management platform

Recall that we said that our train provisioning application sent a message requesting that we register a sign as a device in M2X. You can see from the following screenshot that a sign device was, indeed, registered successfully (the device ID we used in M2X is a composition of the train id and sign id)

Now, as new messages with updated advertising lineups are determined by the Request Signage Data adapter and sent from the operating environment, we can see that they are, indeed, being received in the M2X interface for this sign:

Displaying the dynamic ads on our digital signs

In lieu of actual digital signs, we created a simple simulator application to demonstrate how the the advertising lineup from a sign on a given train changes as it approaches each station. Once again, the application leverages's Web Socket protocol adapter for near real-time notifications to keep the application's lineup synchronized just like a digital could.

For example, we can see that the lineup of ads that have been sold for the first sign on train #01 1454 242/SFY is one list while stopped at station #106S

but changes once the train leaves the station and is approaching station #107S

M2X as a data service provider

Besides the obvious utility for managing and provisioning devices, as described above, the M2X platform can also be used as powerful data service.

For example, we could create dashboards for a simple overview of the advertising statistics for a given digital sign device

or we could display the number of ad impressions delivered, or number of distinct advertisers represented in a time-series graph

Of course, we have only scratched the surface in our simple example. There are many more features of the M2X platform. And they become even more powerful when combined with the data service exchange™.

Riak and Elasticsearch

We have discussed Riak and Elasticsearch in previous posts, so you can read more there to see details and other applications of those data services.

Flexibility and Future-proofing

This prototype of a dynamic signage system demonstrates how a complex solution for a real, Industrial IoT vertical can be composed from a relatively small number of existing data services and declarative routing logic in the operating environment. This approach shows the flexibility and choice of working with an exchange containing multiple data services. You add components as you need them based on their fit and functionality.

And new components can be added in the future with only the work needed to add the new service. Get a new source for ad inventory? Add the API or data service as a provider with an adapter. Want to manage how much inventory comes from different providers? Add a data service that allows you to control the flow of ads based on the rules you set.

The data service exchange gives you choice during your initial design and provides flexibility going forward allowing you to continue to get the most from your initial investment and still add new products down the road.