Sustainable WAsTe Collection (SWAT): One Step Towards Smart and Spotless Cities

Abstract

For decades, urban areas have been faced with the huge challenge of waste disposal and collection. Even though developed countries have tackled this matter from multiple perspectives, some issues remain unsolved when talking about sustainable smart cities. In particular, waste collection and transportation routes are mostly planned statically, without bearing in mind real-time container capacity, as well as other unexpected events which might be of interest – for example, a blocked container lid or fire inside the container. In this paper, we propose a service-oriented sustainable solution to these problems based on the use of novel technologies which will provide us with real-time information and instant notifications of any issues related to waste containers and their collection. This way, thanks to the offered real-time services for the Internet of Things, local governments and official bodies will save resources and time. Even more, citizens will also have easy access to such services and information and therefore will benefit from real-time awareness about the container status.

1 Introduction

Currently, there is a great focus on the development of smart cities and, specifically, sustainable smart cities. Not only is it a current day research area, but it is also a priority for governments, environmental protection agencies and even European commissions [1]. Furthermore, citizens have become aware of the importance of living in a sustainable world, but they need the means to be able to cooperate in the process.

Within this field, waste collection topic has always been socially excluded. Due to the unpleasant sight waste containers might present, many towns are replacing them by underground ecological islands with waste collection facilities. These solve the problem of bad odors that were present near a traditional waste container. However, underground containers do not solve the problem when waste is not collected frequently enough, or when there is an unexpected amount of waste disposal.

In general, whichever type of container is used, there are frequent unpleasant and even dangerous situations due to waste disposed outside the container. The reason is that the mechanism established by councils for waste collection mostly consists of a fixed weekly schedule with a fixed route to be followed every day, regardless of how full or empty the containers are; besides, there is almost no monitoring on waste containers. This causes three main problems, among others: (1) money is wasted when collecting waste from empty or almost empty containers; (2) both residents and neighborhoods are affected when not collecting waste from full containers; (3) dangerous or unsuitable situations are not detected.

In the past some works about forecasting models for waste collection were published [2]; however forecasting is not always accurate and do not provide information about unpredictable facts. Now, some emerging proposals can be found on waste containers’ fill level monitoring [3, 4]: they mostly focus only on providing optimized routes to the collection company office. Nevertheless, they do not provide additional real-time alerts to other interested parties nor dynamic updated routes to the track driver application based on alerts which might happen when the track is already on the way. To solve this problem, we propose SWAT: an Internet-of-Things (IoT)-based hardware infrastructure and software architecture for Sustainable WAsTe Collection. SWAT will monitor and provide us with waste islands information in real time and will send notifications about their status to any interested parties, such as the Fire Brigade. Please note that even though we refer to containers in ecological islands throughout the paper, the proposal is applicable to any type of waste container.

The remainder of the paper is organized as follows: First of all Sect. 2 explains the required background on Event-Driven Service-Oriented Architecture (ED-SOA) and Complex Event Processing (CEP) to facilitate the understanding of this paper, and presents related work. Then our solution SWAT is described in detail in Sect. 3. Afterwards SWAT evaluation and discussion are presented in Sect. 4 and 5, respectively. Finally, conclusions are drawn in Sect. 6.

2 Background

In this section, the software technologies particularly relevant for this paper scope are explained, as well as an overview on other waste management solutions is given.

2.1 Event-Driven Service-Oriented-Architecture

Service-oriented architecture (SOA) is a logical way of designing a software system to provide services to either end-user applications or to other services distributed in a network, via published and discoverable interfaces [5]. The essential goal of a SOA is to enable general-purpose interoperability among existing technologies and extensibility to future enhancements. In particular, in this paper we will make use of REpresentational State Transfer (REST) services [6].

On the other hand, Event-Driven Architectures (EDAs) promote the detection of events and the subsequent intelligent reaction to them [7]. Currently, the integration of EDA and SOA is known as Event-Driven SOA or SOA 2.0. SOA 2.0 will ensure that services do not only exchange messages between them, but also publish events and receive event notifications from others. For this purpose, a highly distributable communication and integration backbone is required. This functionality is provided by an Enterprise Service Bus (ESB), a middleware application that provides interoperability between different communication protocols and which can be used as an integration platform that enables existing applications to be exposed as services [5]. Mule [8] is one well appreciated ESBs because of its integration with cloud platforms and multiple tools and scenarios. SOA 2.0 leans on CEP, a technology that allows the analysis and correlation of large volumes of data as explained subsequently.

2.2 Complex Event Processing

CEP is a cutting-edge technology which provides powerful techniques for processing and correlating events to detect relevant situations (complex events) in real time. An event can be defined as anything that happens or could happen [9]. We can have simple events —they are indivisible and happen at a point in time— and complex events, which contain more semantic meaning summarizing a set of other events. Besides, events can be derived from other events by applying or matching event patterns, that is, templates where the conditions describing the situations to be detected are specified. Such event patterns are defined using specific languages developed for this purpose known as Event Processing Languages (EPLs). In this scope, a CEP engine is the software used to match these patterns over continuous and heterogeneous event streams, and to raise alerts about the complex events created when detecting such event patterns. In this paper we make use of Esper [10], which is a well-known open source CEP engine, written in Java, what facilitates its use in multiple platforms.

2.3 Summary of Existing Approaches

Some cities are starting to propose smart approaches in order to provide sustainable waste collection systems as is being done in one district of Los Angeles [11]. BigBelly company propose the use of their intelligent containers which compress the waste and send a message to the collectors’ telephone when they need emptying [12]; currently a pilot is being performed in New York. Dugdhe et al. depict a proposal for suggesting a schedule for waste collection trucks [4]. More mature is Enevo research project funded by the European Commission’s Horizon 2020 program [3], a solution combining fill-level monitoring and dynamic route planning to eliminate inefficiencies and costs associated with inflexible static waste collection routes. We can also find some mobile applications which encourage citizens to recycle providing them information about the waste type and where to find the appropriate container [13].

However, as far as we are aware, none of them has supplied appropriate infrastructure to provide real-time information not only about container fill level but also other unexpected events, such as a blocked container lid, unsuitable material disposal or a fire, which might be of great interest for governments and official bodies as well as for the citizens. Besides, SWAT consider that the truck driver will carry a mobile application which will be updated in real time, even during the waste collection route, so any unexpected issue can be dealt with immediately. Moreover, existent solutions provide and notify their status to management offices only, whereas our proposal considers that citizens play a key role in the sustainable waste collection process.

3 SWAT: Sustainable WAsTe Collection

In this section, we are going to show a high-level overview of SWAT infrastructure and proposed architecture to easy the comprehension of the remaining subsections. Then we get into details: firstly we describe the hardware infrastructure, secondly we explain the management module and then the software clients are described; finally we make clear how alerts are detected and how actions are risen automatically.

3.1 SWAT Infrastructure and Architecture

Figure 1 represents a schematic view of the developed prototype for SWAT infrastructure. On the left hand side, we can see the board and sensors to be installed in waste containers; that is, the hardware requirements. On the right hand side, we can see the mobile devices which will receive a notification when a certain action is required regarding waste containers; that is, the software clients. Finally, the central part of the diagram shows all Internet-based communications and the management software module. The operation proceeds as follows:

Fig. 1.

Sustainable WAsTe Collection schematic view

• 1. Waste containers equipped with the hardware infrastructure and corresponding sensors will provide information concerning how full the container is, if any obtrusive element is blocking it, as well as information about the temperature and air opacity inside the container. This information will be constantly sent through the Internet to the server where the management software module is installed. The information is also sent to an IoT platform where any interested party – a citizen or an environmental agency, for instance – can check container status in real time.

• 2. When the sensors’ information from waste containers reaches the management software module, the latter processes and stores such information, detecting any situation which requires an action (such as a fire or a full container) in real time.

• 3. When actions are required, notifications and alerts are sent to the relevant management office/body (firefighters, waste collection company, et cetera).

Regardless of the special actions required on risen alerts, before the waste collection employee starts his daily collection, the system provides him with the optimal route according to container status information, which can be automatically updated during the route if any additional alert is detected.

3.2 Hardware Infrastructure

The aim of the hardware infrastructure implemented is to acquire and send the following data from each ecological island: temperature, unsuitable waste, fill level, blocked lid, smoke presence and battery status. For this purpose, we used a Raspberry Pi B+ as the central unit to be connected to the implemented circuit and plugged sensors (see left-hand side of Fig. 2). The Raspberry Pi obtains the sensor measurements and sends the data to the management software module every 10 min. The most relevant elements connected to the circuit are:

Fig. 2.

Hardware infrastructure and container mock-up

• Temperature sensor: it measures the temperature inside the container. We have used TMP35 temperature integrated circuit, which provides an output voltage linearly- proportional to the Centigrade temperature of 10 mV/°C.

• Dust/Smoke sensor: it measures air opacity in the container. We have used sensor GP2Y1010AU0F which is an optical air quality sensor, designed to sense dust particles: it is based on an infrared emitting diode and a phototransistor which are diagonally arranged to allow the sensor to detect the reflected light of dust in air.

• Limit switch sensor: it detects container lid blockages. It is a limit switch connected to mass and to a pull up resistor.

• Ultrasonic transducer sensor: it detects how full the container is. We used Ultrasonic ranging module HC - SR04: sending a pulse input and measuring pulse signal back, we can calculate the waste level in the container.

• Lithium polymer (LIPO) battery: it provides energy to the circuit in case of power failure or cloudy weather. The 7.4v and 3200 mA LIPO battery used provides more than enough battery to feed the circuit, since the system load in text mode with the minimum required services and consumes less than 200 mA. Please note that the higher consume of the system is when sensors information is submitted; to minimize it we send the information from all sensors at the same point in time.

• Solar cell: it charges the battery. We used an 8.5 V solar cell, which feeds the system charging batteries when there is a feeding failure and at night. Also, we needed to use a LM7805 voltage regulator in between the solar cell and the LiPo battery.

Besides, as shown on the right hand side of Fig. 2, we implemented a scaled container mock-up and installed the software infrastructure on it in order to test the system’s functionality.

3.3 Management Software Module

The architecture proposed and implemented for the administration software module is shown in Fig. 3. It is composed of an ESB, a REST Application Programming Interface (API), a CEP engine, an SQL Database, a Not-Only SQL (NoSQL) Database, an E-mail service and a Google Firebase service. Let us describe each element in detail:

Fig. 3.

Management module architecture

• ESB. As previously explained an ESB eases communication between several devices and software modules in heterogeneous systems [5]. In this approach, we use the ESB to transform and route the information reaching the system from the sensors in the hardware infrastructure to the CEP engine and to the event consumers.

• REST API. This is a set of functions that can be invoked, according to REST principles. In this case, a REST API will be used as the interface to external software for the management module, i.e. other software can interact with the ESB through this API. Some of the services offered by the API are:

  • The collector truck employee will be able to obtain the optimal route for waste collection from his software client. Please bear in mind we use Google maps to provide the optimal route; our contribution is knowing -according to the real time container waste level- which containers should be visited.

  • The hardware infrastructure may post the data taken from all container sensors.

  • A citizen could get information about the closest container not damaged or full.

• CEP engine. As previously explained, the CEP engine allows us to analyze and correlate a high number of information events with the aim of detecting relevant or critical situations (alerts) in real time [9]. In this case, we detect when there might be a fire in the container and when it is full or blocked, based on the information provided by the sensors and routed to the CEP engine by the ESB, and we send the corresponding alert to the official body in charge.

• SQL Database. As could not be otherwise, we will use a relational database to store the information about local agencies, container location, alerts available in the system, et cetera.

• NoSQL Database. We will use it to store simple events coming from the hardware infrastructure (sensor measurements) and complex events coming from the CEP engine (detected situations of interest). The reason to have an additional NoSQL database is to facilitate the scalability of the system, so that a growing number of sensors connected to the system would not decrease its performance.

• An email service. Any type of alert will be sent to the licensed agency.

• Firebase Service. Firebase is a Google platform which provides several facilities for mobile applications (https://firebase.google.com/). In this case we make use of their facility for mobile notification submission. Mobile devices of the corresponding agency or official body will be sent a notification. Firebase could have also been used to store the relational database information, but we opted for an external database to keep it in the local server.

Therefore, the process is as follows:

• 1. Sensing data reach the system through the REST API.

• 2. These data flow through the ESB.

• 3. The sensing data are transformed into events: (a) events are sent to the CEP engine; (b) events are stored in the NoSQL database.

• 4. Alerts are detected in the CEP engine (according to previously predefined patterns): (a) notifications/alerts are sent to the corresponding management office/body and corresponding actions are automatically taken; (b) complex events are stored in the NoSQL database.

• 5. The information in the databases can be consulted through the REST API.

3.4 Software Clients

Two Android mobile applications were developed: one for official bodies and another one for the maintenance and collector company, with the following uses in mind:

• Emergency and maintenance bodies (police, firefighters and maintenance staff) will have a mobile application which receives the Firebase alerts sent from the management software. In Fig. 4, the first and second image show the main menu from such application and a received alert, respectively.

  Fig. 4.

  

  Official bodies and waste collector employee software client

• Maintenance alerts can be sent to the second mobile application, aimed at the waste collection licensed company. It is also used, for example, to obtain the optimal waste collection route, as shown in the fourth image of Fig. 4; the main menu of this application is shown in the third image.

3.5 SWAT Alerts and Actions

All ecological islands will send their data to the management module every 10 min. However, in order to avoid feasible fire or unsuitable container use among readings, a specific process will be checking their status every 5 s, in order to raise the alarm as soon as possible, if necessary. This means that if such data are sensed, the alert is sent to the management module at once.

Let us explain now what exactly our system will detect, how we define what we wish to detect and what will we do upon every triggered alert.

SWAT Alerts

The management module contemplates 4 critical situations, as summarized below:

• PotentialDust (Alert level 1): it detects unreasonable air opacity, that is, the density of dust or smoke in the air.

• PotentialFire (Alert level 2): it detects fire in the container.

• PotentialLowBattery (Alert level 3): it detects when the ecological island’s battery level is not enough for proper functioning.

• PotentialBlockedLid (Alert level 4): it detects container lid blockages.

The definition of such situations to be detected in the CEP engine can be done manually by coding the patterns; alternatively, those who are not expert on programming languages but have knowledge about the matter of the patterns in question, can use our graphical intuitive interface created for this purpose, called MEdit4CEP [14]. This tool is capable of automatically transforming the modeled event patterns into Esper EPL code. Moreover, this interface allows us to deploy patterns into the system automatically: we only need to graphically define and add the new desired patterns. At http://dx.doi.org/10.17632/z6pzv33xhy.1 we can find an example of how the event pattern for detecting potential low battery (PotentialLowBattery) in an ecological island has been modeled and automatically transformed into EPL code by using MEdit4CEP.

We would like to highlight that this management module can be extended to detect new critical situation types: we only need to implement the new patterns coding them manually or graphically with MEdit4CEP and deploying them in the CEP engine.

SWAT Actions

The actions to be taken when the explained alert situations are detected follow:

• Alert Level 1: inappropriate material disposal, such as construction waste. The police department is notified by a mobile notification using Firebase.

• Alert Level 2: there is fire in the container. The firefighters and police department are notified by a mobile notification using Firebase.

• Alert Level 3: low battery level. The maintenance service is notified by a mobile notification using Firebase.

• Alert Level 4: blocked container lid. The maintenance service is notified by a mobile notification using Firebase.

With the built mock-up, we have only been able to test a limited number of functionalities and situations. In order to test the system in depth and see if alerts were raised appropriately, we implemented a daemon that simulates the values taken from every sensor from several island and sends continuous data to the management module. Besides, we send it to an IoT platform with the purpose of making it available to additional clients and applications: this way, anyone could use these data in their software clients and citizens could check it from their Internet browsers, for instance to see whether the container where they are going to dispose of their garbage is full.

4 Evaluation

Our prototype is constantly sending data to a channel in ThingSpeak IoT platform; in particular this channel can be followed at https://thingspeak.com/channels/72664, where we can see our ecological island battery level, temperature, dust level, fill level and if the lid is blocked or not, as well as the location of the container.

In order to demonstrate the feasibility of the solution proposed in this paper, SWAT, we have carried out some performance tests concerning the amount of data supposed to be managed by medium and big-sized cities around the world. The full software architecture was deployed in a workstation with i3-540 (4 M cache, 3.6 Ghz), 8 GB of RAM memory and SATA2 hard drive and we have used an emulator to generate the messages sent to the system. Since a medium-sized city can have around 5000 containers, we tested the system, receiving 5000 messages every 10 min – every message contains 5 sensor measurements. We used ESB and database consoles to monitor this simulated data in real time. We checked that the system perfectly supported this load of events and responded in less than a millisecond with the corresponding complex events detected as well as the corresponding notifications; thereby, the alerts were launched in due time according to the values entering the system. As a big-sized city can approximately have around 20000 or 30000 containers, we also tested the system managing 30000 messages every 10 min and this worked appropriately.

Regardless of the number of containers expected to be dealt with by the system, we proceeded with additional performance tests to check how the system managed bigger amounts of data. We tested the system sending big amounts of events and increasing the number of events per minute submitted to the system (test set 1, 2 and 3 with 13300, 26700 and 53800 events per minute, respectively). As we can see in Fig. 5, even though we increased the submission speed over 50000 events per minute as well as the total amount of submitted events; the system continued running perfectly, detecting the corresponding relevant events.

Fig. 5.

Results of the performance tests

As a result, we consider the system is highly scalable. Of course, we could use enterprise editions rather than community ones for implementation software as well as more powerful workstations or even distribute several components of the system in different machines to scale it around the world.

5 Discussion

The proposed software architecture makes use of emerging technologies which provide the platform with significant advantages, namely (1) being able to process and analyze the data coming from several garbage ecological islands in real time, (2) being able to therefore detect and notify the corresponding alerts to the interested parties in real time. There are further benefits from using this software platform:

• The system is highly scalable, what means that a garbage collection company having containers in multiple locations – in the same or different cities – might deal with all of them using the same platform.

• The fact of being able to be notified of the status of every container in real time implies a save of resources and budget for all the parties: the garbage collection company will optimize the routes and save on fuel and employees, consequently they will be able to offer better prices for their services to the local governments, which will therefore also save on their budget dedicated for these purposes. Moreover, the citizens will be happier with their local governments and with their cities. Besides, fires will be detected earlier, and notified to all the interested parties, avoiding further personal and material damages. Last but not least, avoiding the accumulation of garbage outside the containers, will avoid the subsequently insalubrity and unhealthiness for the citizens and city in general.

• The system is also easily extendable thanks to the use of the ESB and therefore it could be integrated in the future with other relevant rising approaches, for instance to improve the promotion of appropriate waste disposal [15], or to include additional prevention policies.

• Since the device to be installed in the container is considerably cheap (less than 10 euros plus the cost of the solar cell if power supply if not available), the company which is in charge of waste collection could save big money in fuel when rescheduling the route according to the necessities of the containers.

In our near future work, we will complete our software architecture with the integration of other event consumers, such as actuators, social network services and a mobile application for the citizens. These consumers will be easily integrated into our architecture thanks to the ESB, which helps to increase the flexibility of heterogeneous environments. On the one hand, the use of actuators will become a benefit since some mechanical actions could then be taken at ecological islands when detecting specific event patterns. For instance, the actuator motor would force the container mouth to close or open in two situations: (1) close the mouth when the container is full, to prevent citizens from trying to introduce more waste, which can lead to clogging of the hydraulic system openness, and (2) open the mouth to ventilate the container in case of fire. On the other, the integration of the architecture with social network services like Twitter will permit twitting the detected alerts in an account to which interested citizens might subscribe. Even more, the mobile application will permit the users to check and receive notifications about the status of the nearby containers at any time as well as to provide information about them to the system – a citizen might detect for instance some accumulation of waste put down around the container by an antisocial citizen, which would not be detected by the sensors.

6 Conclusion

SWAT is an Internet-of-Things (IoT)-based hardware infrastructure and software architecture for Sustainable WAsTe Collection that will save waste collection companies’ money and will prevent neighborhoods from suffering incommodities caused by full or damaged waste containers. SWAT will monitor and provide us with waste container information in real time, as well as alerting maintenance and official bodies when actions are required. Therefore, SWAT can help to pave the way to future smart sustainable cities and can make citizens aware and involved in this long journey.