How Edeva Uses 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
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.)
An Actibump in Sweden
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.
How Actibump Works
Reducing Speeds on the Øresund Bridge
In 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.
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.
Øresund Bridge between Sweden and Denmark
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 Iron.io'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)
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.
MongoDB Documents and Collections
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 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.
Prior Solution: Local Web Server + FTP
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
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.
Improved Solution: IronMQ + HTTP/REST
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.
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.)
Components within the Actibump Compute Stack
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 Iron.io’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:
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.
For more information on Edeva AB and their intelligent traffic systems, visit their website www.edeva.se.
Start Building With Iron.io Today
Try all features right away. No credit card required.