To audit the pollution in the Matanza-Riachuelo River, the Buenos Aires city government joined forces with Microsoft to build an innovative IoT solution that used a fleet of drones.

Riachuelo River pollution

Key technologies

Core team

  • Alejandro Banzas – Senior Technical Evangelist, Microsoft Argentina
  • Soledad Merlo – Audience Marketing, Microsoft Argentina
  • Marcelo Felman – Senior Technical Evangelist, Microsoft Argentina
  • Ezequiel Glinsky – DX Leader, Microsoft Argentina
  • Estanislao Vazquez – Account Manager, Microsoft Argentina
  • Augusto Chesini – Innovation and Development Manager, GCBA
  • Hernan Patron Costas – Developer, GCBA

Customer profile

Buenos Aires, founded in the sixteenth century, is Argentina’s capital and one of the most visited destinations in South America. The population swells every day as workers commute into the city and tourists arrive to explore its many cultural and historical offerings. The Buenos Aires city government, Gobierno de la Ciudad de Buenos Aires (GCBA), recognizes the value of technology in managing a large and complex city, delivering better resources for citizens, and supporting future growth, so it actively works to find new and innovative IT solutions.

These solutions include helping to make city operations more efficient, and providing information and services to city residents and the many commuters and tourists who visit the city every day. To address the need for efficient information management, Buenos Aires recently created the Ministry of Modernization. This ministry works with organizations across all areas of city government to provide training and technology assistance for modern effective governance. To help meet its modernization goals, Buenos Aires has established relationships with key technology companies; in addition to local IT firms, the city has built a valuable relationship with Microsoft.

The greater metropolitan area is home to 15.6 million people, and is bordered by General Paz Avenue and the Matanza-Riachuelo River, one of the most polluted rivers on earth.

The city government teamed up with Microsoft to build an innovative IoT solution to audit the pollution in the Matanza-Riachuelo River by using a fleet of drones.

Problem statement

The Matanza-Riachuelo River is a 64-kilometre (40 mi) waterway in Argentina that originates in the Buenos Aires province and defines the southern boundary of the city of Buenos Aires. Approximately 3.5 million people live in its drainage basin of 2,240 square kilometers (865 square miles).

The river is polluted from large amounts of industrial waste generated by numerous factories along the river, especially tanneries. Among the most dangerous contaminants are heavy metals (arsenic, chromium, copper, zinc, and lead) and waste water from the basin’s saturated layers. Chromium, for example, had a mean value in the soil of 1,141 parts per million (ppm), which is significantly higher than the recommended level of 220 ppm. A 2013 article published in Salud Colectiva found that 80% of water samples taken from wells near the Matanza-Riachuelo River basin were not safe for drinking due to contamination. For reports about different aspects related to Cuenca Matanza Riachuelo (CMR), see the ACUMAR website.

To audit the pollution in the river, GCBA wanted to create a drone solution that measures the water conditions meter by meter by using sensors, and then posts this information as points on a map.

Solution and steps

In the proposed solution, the drone will land and take off from one point to another, reading the sensors and storing the data in local memory. After that, the device will synchronize the data to Azure IoT Hub and the developed backend.

The sensors will measure the following:

  • GPS
  • GSM
  • pH
  • Temperature
  • Flow
  • Chlorine
  • Calcium
  • Iodes
  • Nitrates
  • Nitrites
  • Dissolved oxygen
  • Turbidity
  • Conductivity


In our first brainstorming meeting, we generated a lot of ideas. GCBA had already developed drones, but they were not connected to the cloud, so we discussed the solution architecture and the technologies we needed to make that happen. It was determined that the drones would have a Raspberry Pi 3 running Windows 10 IoT because it has an important versatility in terms of process power and connection to sensors. Attached to the Raspberry Pi 3 would be sensors and a GSM module to send the data to the backend services.

Architecture diagrams

After we identified the problem and possible Azure services that could be connected to the solution, we realized that some of the services would not be necessary in the first stage. The initial diagram in Figure 1 shows this architecture more clearly (that is, it includes services for future features), and the sketch in Figure 2 shows the current solution (what we ended up using).

Figure 1. Backend initial architecture

Figure 1 - Backend initial architecture

Figure 2. Backend current architecture

Figure 2 – Backend current architecture

Although there are many different services involved, the most critical piece of software resides on the Azure IoT Hub. This service acts as the bi-directional connection between the drones and the Azure cloud, triggering and ingesting the rest of the process.

Inserting and manipulating data

Following is the solution’s high-level flow for processing data, specifically, inserting and manipulating data:

  1. The GSM modem embedded in the drone sends the sensor data to Azure IoT Hub.

  2. IoT Hub sends the sensor data as messages to an Azure Service Bus queue, along with the latitude, longitude, device ID, and timestamp.

  3. Three workers exist inside an Azure Service Fabric deployment:

    • Worker1 takes the raw data and then:

      • Sends the raw data as files to Azure Blob storage; this operation allows us to implement Azure Data Factory or another data pipeline with the data.

      • Sends the per sensor data to another queue.

    • Worker2 takes the per sensor data from the queue and then:

      • Prepares, validates, and sends the per sensor data to Azure Table storage.

      • Sends an update message to another queue.

    • Worker3 is fired when the update message arrives; it then prepares the data to be shown on the map.

      • The data is stored in an Azure SQL Database with spatial support, which allows us to query the database asking for the information available for a defined space of the river.

Consuming data

The second part, related to data consumption, was also designed during the meeting and looked like this:

  • The client has access to a Bing Maps page embedded with the sensor data.
  • Developers and other government areas have access to the raw data.

Issues and solutions

This initially proposed architecture had some issues we would only later perceive. First, we realized that having the drones taking off and landing every meter had a dramatic impact on battery life, so we decided to change the approach and build a drone-driven boat.

Also, we had a delay in the delivery of the sensors due to Argentinean customs, so we had to adapt the solution to start with a fewer number of sensors, and configure it so we could add new sensors to the device later.

The JSON sent by the device to the backend now is structured to dynamically support type and number of sensors as follows.

	  "deviceID": "pepe",
	  "location": {
	    "lat": -54.99999,
	    "lon": -38.99999
	  "timestamp": 20161205162200,
	  "sensors": [
	  {"key1": "value1"},
	  {"key2": "value2"},
	  {"key3": "value3"}

With this design in place, we solved both issues:

  • Battery consumption would be low.
  • The drone supported adding new sensors.

The new design for the drone is shown in Figures 3, 4, and 5.

Figure 3. Drone-driven boat front view

Figure 3 – Drone driven boat

Figure 4. Drone-driven boat top-left view

Figure 4 – Drone driven boat

Figure 5. Drone-driven boat back view

Figure 5 – Drone driven boat

Technical delivery

Security details

We used Azure IoT Hub and device registration. Communication to the cloud is done by using Shared Access Signatures (SAS) with a short timespan duration. The following class IotHub shows how the SAS token is created:

	using System;
	using System.Text;
	using Microsoft.Azure.Devices.Client;
	using Newtonsoft.Json;
	using Microsoft.Devices.Tpm;

	namespace IoT.Common
	    public sealed class IotHub
		private static DeviceClient _deviceClient;
		public string DeviceId { get; set; }

		public IotHub()
		    var myDevice = new TpmDevice(0);
		    var iotHubUri = myDevice.GetHostName();
		    var deviceKey = myDevice.GetSASToken();
		    DeviceId = myDevice.GetDeviceId();

		    _deviceClient = DeviceClient.Create(iotHubUri, AuthenticationMethodFactory.CreateAuthenticationWithToken(DeviceId, deviceKey), TransportType.Amqp);

		public async void SendData(double lat, double lon, object[] sensors)
			var telemetryDataPoint = new
			    deviceId = DeviceId,
			    timestamp = DateTime.UtcNow,
			    location = new

			var messageString = JsonConvert.SerializeObject(telemetryDataPoint);
			var message = new Message(Encoding.ASCII.GetBytes(messageString))
			    UserId = DeviceId
			//message.Properties.Add(new KeyValuePair<string, string>("distance", distance.ToString(CultureInfo.InvariantCulture)));

			await _deviceClient.SendEventAsync(message);
			//Console.WriteLine("{0} > Sending message: {1}", DateTime.Now, messageString);

		    catch (Exception)
			// ignored

Database schema

The following script shows the table required to run the application.

CREATE TABLE [dbo].[PointToMaps] (
    [PointToMapID] [int] NOT NULL IDENTITY,
    [Timestamp] [datetime] NOT NULL,
    [SensorType] [nvarchar](max),
    [SensorName] [nvarchar](max),
    [SensorValue] [nvarchar](max),
    [Point] [geography],
    CONSTRAINT [PK_dbo.PointToMaps] PRIMARY KEY ([PointToMapID])

Device used

We used the Raspberry Pi 3. The customer had designed and built their devices by using parts of commercial devices. The shell was also designed and 3D-printed by the customer. The device has 1 GB of memory and uses battery power and Wi-Fi/Bluetooth for connectivity. It runs Windows IoT.

Device messages sent

  • Packet size: Data packets, although variable, average at 1 kilobyte.
  • Frequency of send: Frequency is also variable as it depends on the readings of ambient conditions. The maximum frequency is every 10 seconds, and the maximum delay we have seen is 60 seconds, as soon as it’s available on the sensor (some might take longer to read ambient variables).

SDKs and languages used


This combined effort from Microsoft and GCBA delivered a successful project that gave the partner the solution needed in a very time-efficient manner. Building the solution on top of the Microsoft Azure cloud platform was a key component to achieving the desired results in the expected time frame. The project was implemented in four weeks with a dedicated technical evangelist on the account, who helped with all the problems that came around.

The good relationship built during the project resulted in an open door to Microsoft at Things Expert and the possibility of developing other solutions together, some already being discussed by the team.

In GCBA’s own words:

“Our partnership with Microsoft on the Quinquela project, especially through Alejandro Banzas and Marcelo Felman, was a fundamental component in getting our technical team up to speed on Azure technologies, and in building not only Quinquela´s Azure-based backend, but also getting ideas for new projects to empower Buenos Aires citizens through technology.”

The GCBA team defined a macro plan in three phases to make an impact on pollution in the river:

  1. Map the contaminants.
  2. Close the source of new contaminants.
  3. Clean up and implement regular controls.

Additional resources