How Edeva Uses MongoDB and IronMQ to Power Real-time Intelligent Traffic Systems

Edeva AB develops and markets intelligent traffic systems. Their product is a dynamic speed bump called Actibump. The selective system makes it possible to handle the compromise in accessibility, traffic flow and speed control, which is not possible with static speed bumps.

Actibump consists of one or more road modules that are mounted into a cast foundation and a radar unit that transmits information to a central control system. The road modules raise and lower in response to vehicle speed and are controlled and monitored over the Internet. Actibump can be expanded with variable speed limits, automatic traffic control (ATC), transponder systems for emergency vehicles, and real-time background data capture for statistical analysis of traffic.

From Road Trials to Production

An Actibump in Sweden

Actibump has been in operation in Linköping, Sweden in 2010 at a location at which unprotected road users cross a street used by cars and public transport. The speed of a vehicle approaching the Actibump is recorded with the aid of radar measurement or induction loops. No action is taken if the vehicle speed is within the legal limit, but if it is approaching faster than is permitted, a part of the roadway pivots downwards, creating an edge. Driving over this edge causes discomfort for the driver encouraging them to reduce speed before reaching the obstacle.)

Here's a video of an Actibump in action:


How Actibump Works

Vehicle speeds have been actively monitored before and after Actibump has been installed. The percentage of vehicles exceeding the speed limit in the three years since installation has dropped from 70 percent to 20 percent, demonstrating Actibump’s proven long-term beneficial effects. The results also show that at least 95% of passing traffic keeps to the speed limit when passing Actibump. This leads to significantly increased safety for unprotected road users.

Reducing Speeds on the Øresund Bridge

blankIn December 2013, Edeva AB won a public procurement for variable speed impediments to the Øresund Bridge. The bridge is a double-track railway and dual carriageway bridge-tunnel across the Øresund strait between Sweden and Denmark.


Øresund Bridge between
Sweden and Denmark

The bridge runs nearly 8 kilometers (5 miles) from the Swedish coast to the artificial island of Peberholm, which lies in the middle of the strait. (The remainder of the link is by a 4 km tunnel from Peberholm to the Danish island of Amager.) Actibump will be installed in four of the eleven lanes at the toll station for Sweden for Denmark-bound traffic, and will help make the work environment safe for bridge personnel.

About Edeva AB

Edeva is led by David Eskilsson and is a spinoff from Prodelox, a leading product development company, and a member of  the LEAD business incubator in Linköping.  In response to the positive evidence of success and the visibility gained from the Øresund Bridge installation, Edeva expects to more significantly expand their opportunities in Europe during 2014.

Edeva’s Actibump solves a worldwide problem, to handle the compromise between traffic safety, accessibility, traffic flow, and work environment in public transport and do so in an intelligent and mindful manner. Edeva uses MongoDB and's IronMQ as core pieces within their infrastructure to  collect and process real-time data and create more intelligent traffic systems. Edeva’s combination of mechanical engineering and advanced data collection and processing demonstrates that the Internet of Things is real and within easy reach.

Details on How the Actibump Works

Choosing a Central Database (MongoDB)

MongoDB Documents and Collections

Edeva identified the opportunity to centrally collect and analyze traffic data in real time, enabling their customers to unlock deeper operational intelligence into traffic management. The application would initially collect data on each vehicle, including maximum speed, average speed and vehicle type, but they also intended to expand this in the future to include weather conditions, congestion levels and other metrics that would improve traffic flow and the safety of road users. 


The development team initially considered using MySQL as their central database, but quickly realized that their changing data requirements would not be supported by its rigid relational data model. With the need to ingest highly variable and rapidly changing sensor data from their Actibump modules and run analytics against it in real time, the development team chose MongoDB. As a consequence, Edeva can dynamically adjust measurements and configuration, while aggregating data to customer dashboards in real time. In addition, the engineering team can quickly evolve their application to meet new customer requirements.

[Before] Local Web Server, FTP, Batch Uploads

Prior Solution: Local Web Server + FTP

Prior to using IronMQ, Edeva didn’t have a good way of moving the gathered data from the server connected to the speed bump. The data was downloaded to MongoDB in batches every week or two. The original solution was based on recording the data onsite within the computer that controls the speed bump and using a web server installed locally to provide access to the data from the central system.

The data was accessed using FTP and similar solutions. Earlier attempts were based on reading a weeks worth of data at time. Attempts to collect the data from the local server on the site was very slow and unreliable, making it hard to get accurate data from the speed bump.

[After] IronMQ, HTTP, Real-time Processing

Improved Solution: IronMQ + HTTP/REST

Partway through the trial period, John Eskilsson, the technical architect of the Actibump system,  evolved a revised system to move the captured data from the speed bump to the central system in a more reliable and timely manner. He chose to use message queues early in the process as he realized that buffering was needed between the Actibump road modules and the backend datastore.

John looked at a number of queueing systems and chose IronMQ because it is cloud-based and extremely easy to implement. Since it has built in access control and is accessible via REST from outside AWS, Edeva could simply hook it into the current solution on the computer on site. John has written an extension to the Yii framework that makes it even easier for them to use the PHP API.


Components within the Actibump Compute Stack

Edeva is gathering the radar data via a C program that feeds the data into a local datastore on the Ubuntu-based computer within the speed bump module. The local processor polls the datastore for data every second and posts it to IronMQ. (The schedule was set so that the disk I/O and latency of the C server remains low and so that slow transmission speeds are accommodated.)

Edeva has a PHP harvester running on the central system that polls IronMQ every second and adds the data to MongoDB. By using IronMQ as the buffer, they can make sure that every message gets delivered one time only. When the data is in MongoDB, the administrative web interface can be used to browse the data in near real-time. It takes about 3 seconds from when a car passes the speed bump until the data is in MongoDB which is more than sufficient for current needs.

Results and Future Work

Edeva has moved over 1.3 million events so far in production. This figure is from two speed bumps and will increase dramatically when the Øresund Bridge Actibumps come online in addition to other Actibump installations. Future work includes using’s IronWorker service to scale-out the program that harvests the event queue today and doing a fair amount of statistical analysis in the background on a continual basis.

Edeva also plans to collect additional information from the modules by adding additional sensors. Very little if any refactoring will be needed within the system given the flexible data schema and the use of a message queue to streamline and buffer the data inputs.

What John Eskilsson, the technical architect of the Actibump system, says about the combination of MongoDB and IronMQ:

John Eskilsson
We use MongoDB for capturing all the vehicle data. It is perfect for this since the various vehicle events we collect can send different types of data. Since MongoDB has a dynamic schema, we can easily change the data being sent from the bump and still be able to run analytical queries on the data set without any work and run queries on this new data instantly.
IronMQ has been very reliable so far and was extremely easy to implement. It was one of the primary reasons for why we selected IronMQ. We can take down the central server for maintenance and still rely on the data being gathered in IronMQ. When we start up the harvester again we can consume the queue in parallel using IronWorker and be back to real-time quickly. We can also perform statistical data calculations via IronWorker and MongoDB without putting any additional loads on our main app servers.
Which this combination, we now have near real-time data. We have a system that can easily scale to take data from a large amount of speed bumps from all over Europe and the world. The ease of use of the two has be huge benefit to allow us to get up and running and into production. But it’s the flexibility, scalability and reliability of this architecture, and companies behind the products, that give us the confidence we’ll be able to handle the traffic loads we foresee.
John Eskilsson has driven the software development and built the technical architecture for Edeva AB the past two years. He works with PHP, NetSuite, Solr, MongoDB, MySQL, JavaScript, and C and is a key contributor to the Yii Framework. He likes to share his technical findings with people which you can see here.

For more information on Edeva AB and their intelligent traffic systems, visit their website


To learn more about how MongoDB and can help you build solutions for the Internet of Things, visit MongoDB and today.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.