Faculty of Engineering & Information Technology School of Information, Systems and Modelling

Noise Detection and Management for Smart City using IoT

BY
Anton Kravets
Carlos Caceras
Yucheng Zhang
Wael Saleh H Alqethami

 1. Introduction and Scope of the project

In this project, we will work on a Noise Detection and Management for Smart City using IoT. We will use this system to monitor the sound levels in fixed locations using microcontrollers and sensors. Sensor data is uploaded to the cloud, where it is visualized via a web application. If the sound levels exceed the intended threshold, the system will notify the appropriate people, such as patrolling teams or authorities. We’ll also keep track of sound levels over time and when alarms are sent out. We’ll utilize various software and hardware to do thing

IoT-enabled Intelligent Transportation Systems (ITS) are getting a lot of traction in academia and business to improve noise detection in smart cities. A vast increase in the number of noise issues has been recorded due to the ever-increasing number of overness. Noise equipped with a slew of sensors allows us to monitor the present state of the overness and its surroundings and make incident detection easier. (Tan et al., 2021) The suggested method intends to use sophisticated smartphone characteristics to build and construct a low-cost solution for upgraded transportation systems that can be used in detecting. (Garcia et al., 2016)

Once the data has been collected, cities may utilize it to improve the city’s infrastructure, public services, and other features. (Jha et al., 2020) There will be several advantages for a city and its residents if it expands in line with the smart city concept, actively leveraging IoT and other information technologies: The city’s utility consumption has been reduced. Well-managed public lighting systems. The city’s traffic flow, noise levels, and other factors have improved. Putting this project to use without infringing any privacy rules, noise monitoring devices may detect excessive noise and other warning indications of a party. Their sensors calculate the pressure of sound waves in the air to calculate sound levels. (Tan, 2009)

1.1.         Project Scope

WSNs, which are rapidly spreading across cities, allow environmental monitoring systems, including those used to identify excessive urban noise, to gather vast data. To collect and analyze data in a more accurate and timely manner, wireless sensor networks that are less expensive may be used rather than typical expensive noise level meters because of their ability to provide a more granular approach. An IoT-based “smart city” concept is based on this idea. This project employs wireless noise detection sensors and other devices and technologies for continuous ambient noise level monitoring. The idea covers the entire noise data information system from sensor construction through data presentation and analysis. This project aims to make a sensor system for continuous noise detection in cities better in terms of design, functionality, and performance (Alías & Alsina-Pagès, 2019).

1.2.          Stakeholders’ analysis:

The Primary group of stakeholders has been identified as Citizens and Police. Citizens’ groups act as the primary system triggers since their excessive noise starts the chain of operations within a system. In addition, the group of Citizens benefits from the application of such a system, as it will significantly increase their quality of life. The police group, in turn, acts as an actuator that enforces the law and controls the level of noise pollution in the smart city.

The Secondary group of stakeholders in the local city government. This group provides a legislative basis for applying and using this system in the urban environment.

2.  System Requirements Specification

2.1.         Problem Analysis and Operational Processes

Problem analysis

The primary problem this project aims to adjust is the difficulties of detecting and controlling noise pollution in a modern city. As urban construction is taking a significant role in building smart cities, construction noise always occurs during the work progress of constructing residential or commercial architecture and other facilities such as roads and railways.

A noise detection system provides a long-term solution to support citizens’ low noise level requirements. Instead of directly constraining the working period or duration of the construction teams, implementing noise detection sensors within the residential building can be more accurate and convenient in estimating whether there is actual noise impacting citizens’ life.

Operational Process

The operational process of the noise detection project includes four procedures. These four procedures compose the operational process’s life circle, which will take place during each phase of the development process.

Figure 1 Operational Process

Evaluate Input and Output

Evaluating the input and output of the project is essential because the evaluation result can determine whether the project is financially feasible to continue. The inputs are all resources of the developer group, such as materials, knowledge, and personnel types, while deploying outputs to reduce the extended use of potential resources. The difference between inputs and outputs is that the cost increases the more you use the inputs. On the other hand, as the use of the outputs increases, the cost of the outputs decreases. (The project input and output refer to the Project Estimated Cost in section 4.)

Asking for Feedback

In this procedure, the responsible person for the project will conduct surveys on each stakeholder of the project. They report the currently developing progress and ask for feedback about the project. For example, project managers would collect the opinions of each developer in terms of challenges or possible direction. Product outcomes for the current stage will be tested by selected groups of users and asked for usability feedback. Also, the project suppliers and government will consult related follow-up support.

Analyze Process

Continue to analyze the process. Check for potential risks, such as additional taxes or capital costs. Also, think about whether the product/service can be produced in the shortest time and at the lowest price. Managing error rates, ROI, et.al

Analyze Result

Before implementing the current outcomes, the developer should analyze the detection data results regarding whether they satisfy the project requirements, such as accuracy and flexibility. The analysis subjects refer to the testing segment of section 2.

2.2.         Development Methodology

Selected methodology: Waterfall Development Methodology

We are considering the available resources, developing cycles, and the need for project stability. Our group believes that waterfall development is the most suitable methodology for the Noise Detection System Project.

Advantages

The linear nature of waterfall development allows developers to understand and manage a project in a more organized. Because the final product for this project is not commercial goods or services that will enable developers to proceed series of post-deployment corrections or frequent maintenance, instead, it is essential for a project manager to conduct a completed and precise project development plans and reduce the possibility of devices redeployment in citizens’ residences.

Constrains

The constraints of selecting a waterfall development methodology are also remarkable. Not only the project managers are required to equip abundant developing experience and vast project perspectives. The project development process usually be sluggish to control the integrality, security, and reliability. Due to the rigid structure and strict controls, the waterfall methodology’s developing cost could be higher than other methodologies.

2.3.         Functional Requirements

Noise detection

      The system should be able to detect the decibel level of sound within the supported detect range.

Setting of Noises

A system is required to allow administrators to modify which decibel environmental sound level is regarded as Noice.

Automatic Warning Support

The system must automatically send an alert to a citizen who lives in the residence that has detected noises. The alert will be delivered through SMS.

Police department Reporting Support

The system must send a report to the nearest police station if a residence has been detected to keep making noise after three automatic alerts have been sent to the residence.

 Citizen Report Support

       Citizens can report to police the neighbors or surrounding environment making noise through the system. The reporting system interface would be carried on both the website and mobile application.

2.4.         Non-Functional Requirements

Financial efficiency

To meet the stable project plan, the financial cost of the overall project and recourse should be restricted to a sustainable level. (Detailed financial planning refers to Cost estimation and budgeting)

Long-term viability

The system should ensure the Cloud-based systems can provide uninterrupted service for a long time and the durability of the detection sensor.

Time-efficiency

The wireless sensor networks that support the noise detection system are expected to reach 110Mbps data delivery speed to ensure a timely noise alert. In the absence of network failure conditions, the network speed fluctuation should be minimized to 100 – 200 pings.

Accuracy

This system should guarantee that the noise measurement result deviation reduces to 8db. At the same time, the system should ensure that false alarm situations will not happen.

Expansibility

This project can provide insight into the application of such a sensor on a broader scale (the city’s urban area where coverage will be accessible) and the criteria and expectations that this low-cost wireless sensor unit can meet.

Diversity

The system should support a variety of sensor interfaces to meet the needs of diverse measurements.

2.5.         Testing

To develop a high-efficient system, usability, reliability, security, and performance should be tested. Taking the following components:

1. Hardware:
   1. Sensors.
   1. Launchpad.
   1. Computer
   1. Network
2. Software:
   1. Application
   1. Data

Therefore, system testing should be defined by the components of which it consists and distributed into the following categories:

Components:

1. Sensor testing.
2. Launchpads testing
3. Raspberry PI testing
4. Safety testing
5. Cloud Infrastructure
6. Connectivity:
   1. Transfer of data:
   1. Seamless connection
   1. Disconnection handling

Functional:

1. Temperature Sensitivity
2. Vibrations Sensing testing
3. Patterns recognition testing
4. Matching the violator location with sensor results
5. Errors/Failures handling

Performance:

1. Request handling
2. Interruption testing
3. Device (CPU) testing
4. Synchronization

Security

1. Data validations
2. Encryption testing
3. Corrupted packets (Black Holes, Worm Holes)

3.    Architecture / Design 

3.1.         Use case Model

Development of the Noise Detection Smart City begins with developing the Use Case model to provide a high-level representation of the system. The Use Case model includes boundaries of the system (blue rectangle), actors that interact with the system from outside and use cases as an actions/outcome of their interactions.

As Figure 1 represents:

Actors:

1. Police
2. Citizen
3. Cloud
4. Raspberry PI
5. Sensor

Use cases:

1. Sensing environment (Noise  and Vibrations): Sensors gather analogue data from the environment
2. Collecting Data and uploading it to the cloud. Transforming analogue data into structured digital information and allocating it into the SQLite database
3. Monitor/Analyze Noise Level and Patterns. In this use case, the system will detect a high level of noise that is repetitive and continues. This required filtering the peak or short-time sounds, loud sounds that are hindrances and are not statistically important.
4. Send a warning to a citizen. After the high level of noise is detected and a pattern is established, the system will compare noise data with residential data, which will identify the violator and send him a notification/warning via SMS
5. Receive report. When >3 warning has been sent to the citizen, the system will send the report to the nearest police department. The officer can see the report, indicating the violator’s profile and the level of noise that he made
6. View Dashboard. Citizens and the Police officer can get access to the dashboard, where they can see the map of noise
7. Report to police. A citizen can report to the police via the systems’ interface regarding their neighbors or outside objects (cars, trucks) if they pollute the environment with noise but fails to register by the systems sensors infrastructure.

Figure 2 Use Case Model

3.2.         Architecture Model

The project’s architecture consists of the interaction of the 3 main areas: hardware, software, and application. They all work in conjunction through a low latency network (6 LowPan).

Figure 3 Architecture Model

3.2.1.      Hardware

The hardware setup is comprised of the main computer (raspberry pi), Launchpad CC2650 running 6lowpan (server), and  for general purposes, local wifi (phone sharing services)

Raspberry Pi processing unit is the main computer that is going to be transmitting data from the two sensors, one directly connected to the 6lowpan network (accelerometer sensor) and the Arduino compatible microphone sound sensor module (decibel sensor) that’s connected to the raspberry pi directly (for educational purposes as it can’t be deciphered with the current firmware of the software).

3.2.2.      SOFTWARE & APPLICATION

Security

Police officers will have access to the smart city website. They will be able to log in with their personal information under the Noise Detection tab, where the user will be asked to log in with their police badge number and password. All this information is securely stored in the database table.

Storage

Information such as locations, coordinates, addresses, unit numbers, owners, and landlords is stored in a table linked directly with their assigned sensor number located in every Unit (houses, apartments, offices, etc.).

Database cloud

The primary function is to register a temporary log used to send Warnings and Notifications. On the Citizen side, this will be represented via MMS Message and Email (a total of 4 warnings). On the Police officer interface screen, this will be shown as a notification only and as a pop-up message on the last warning, which will give the current location, name, and decibel levels registered in the previous 4 hours. In conjunction, it will also provide all the information stored in the ‘cloud functions logs data record’ that is explained below.

Cloud functions log data record

A history log for every Unit is stored on the server. Data such as the number of times the user has been visited by police, history of fines, and decibel levels data stored every 10 mins. All of this data will be shown on the police officer interface screen, which is helpful for further actions giving a better approach to the user.

3.3.         Class Model

The project will take advantage of the object-oriented programming approach. Such an approach allows for the development of a set of classes that represents objects. Their characteristics and associations are similar to the real world. Thus, the project team has established the following courses (Figure 2):

• Notification (Generalization of Warning class)
• User (Generalization of Police class)
• Sound Sensor CC2650 – Arduino Microphone
• Accelerometer Sensor CC2650
• Raspberry PI

Figure 4 Class Model

3.4.         Sequence Diagram

A sequence diagram provides a representation of the sequence of messages which are communicated between system objects. There are three main dialogs within a system:

1. Exchange of data between sensors and launch pad (Hardware layer – analog-digital)
2. Exchange data between the launchpad and raspberry PI and analysis of results (Software layer)
3. The process of accessing the results and receiving the report by the police (Application layer)

Figure 5 Sequence Model

3.5.         User Interfaces Mockups

The following are the web UI mockups that supposedly would be accessed by police officers via the internet. As can be seen, his journey begins with logging into the internal information system. Then, the officer sees the map of Noise in the Sydney Area. If the system detects a high level of noise’ pattern, the warning will be displayed on the officer web interface.

Figure 6 Login Page

Figure 7 Map of Noise Page

Figure 8 Notification Page: Citizen Profile + Location

4. Project Plan(s)

4.1.         Assumptions and justifications:

At this stage of the project, there are many ambiguities and uncertainties in many aspects of the project, so this section is prepared to document and list assumptions and justifications of the following planning effort listed in this section. Following is a list of assumptions:

• The project management approach used in this project is a hybrid approach (which is a mix of adaptive and predictive approaches), which is due to some level of uncertainties in relation to stakeholders, time, scope, cost, and other relevant aspects.
• The system development plan – the subject of this section – is not intended to be detailed and rigid. It is intended to be initial and carry an acceptable level of flexibility to allow the project team to use their creativity and adapt to any new changes in requirements and/or technologies.
• Technical specifications listed in Sections 1, 2, and 3 are not to be considered final. Further technical requirements and specs may elaborate as the project progress, so the Product Breakdown Structure (PBS) shown in the next paragraphs is an initial version and is subject to validation and change in the early stages of the project.
• Assume there is a project sponsor for the project, representing himself or an organization (for example, University, development and research department in a technological company, etc.). The project sponsor’s role is important to approve this plan, and make available the fund, resources, and necessary support, in addition to approving major project changes.
• We assumed that the project sponsor wanted the project to finish in approximately six months.
• The project is assumed to start on the 1^st of May 2022.
• Need to assign a project manager to the project.
• The prototype will be tested in the field. So, we assumed the system would be installed in a local neighborhood of the city, with a mix of types of housing and apartments. It consists of 7 one-floor houses and one-4-floors mid-rise building. Each building floor consists of 3 apartments. Thus, the initial estimate of the quantity of the Noise Sensor Units required is assumed to be 30 unit.
• Microsoft Project Software is used as a tool to facilitate time schedule planning. Also, it is used to load resources, input rates, and estimate approximate project costs.
• Time and resource estimation: The activity’s time durations are estimated based on a top-down, high-level estimation and based on the previously mentioned assumption that “the project will take approximately six months.” Accordingly, activities’ durations were estimated based on consultation with experienced project team members in similar projects and based on web research. Similarly, resources were identified, hourly rates selected, and further detailed in the next paragraphs based on similar project research and national salary survey websites.
• It is assumed that Project Management Activities are part of the project scope; it is listed in the project schedule as one activity; however, it includes Planning, Stakeholder Mgmt., Communication Mgmt., Scope Mgmt., Schedule Mgmt., Quality assurance and control, Resources Mgmt., and Procurement Mgmt.
• Project management activities are assumed to be distributed over the project duration.
• To estimate the project budget, the estimated cost resulting from resource usage in the project is calculated, resulting in the direct and indirect cost estimate, 10% risk contingency, another 5% management reserve, and 5% overhead are assumed. Refer to the budgeting section for details.

4.2         Project objectives:

Short-term objectives (specific to this project):

1. Develop a stable and cost-effective noise detection and management system utilizing the latest technologies in IoT and existing infrastructure when possible.
2. This project will be carried out in order to assess the sensor’s long-term viability, durability, and accuracy.
3. To design and implement a sensor system for continuous noise detection in cities better in terms of design, functionality, and performance.
4. Monitor and improve the performance of the system.

Long-term objectives (For potential future developments):

1. Offer SmartCity community life of comfort by reducing the noise, utilizing the latest technologies, IoT, existing infrastructure, and tools as much as possible, and considering a cost-effective solution.
2.  Reduce noise complaints calls to the police, thus helping them concentrate more on tasks that matter to the community, e.g., crimes.
3. Be compliant with local regulations and laws, respect the privacy of residents and eliminate or reduce system failures and false alarms to the minimum.
4. In a later stage, when the system is mature and solid, promote the system to local authorities for a wide-scale implementation, hopefully on a national scale.

4.3.         Project Scope of Work:

The work required to complete system development and meet the above-mentioned project objectives includes but is not limited to project management activities, system engineering, software and application development, and testing, hardware, system integration and system testing, installation, system performance and improvement, and system maintenance.

Project management activities include Planning, Stakeholder Mgmt., Communication Mgmt., Scope Mgmt., Schedule Mgmt., Quality assurance and control, Resources Mgmt., and Procurement Mgmt.

The scope of work of the project is further detailed in the WBS section.

4.4.         Team Organisation and Managerial Approach

With reference to discussed assumptions, the management approach is proposed as per the following organization chart, project management is the responsibility of a project manager, authorised by a project sponsor, supported by technical manager and operation manager, in addition to management of external stakeholders’ expectations.

Figure 9 Project Team

4.5.         Work Breakdown Structure – WBS.

WBS is summarized as follow:

4.6.         Project Schedule

Figure 10 Project Schedule

4.7.         Roles and Responsibilities structure.

4.7.         Time estimation issues.

As mentioned in the assumptions, we made assumptions because there is high level of uncertainty at this stage, we used top-down estimation assuming the project will take approximately 6 months. We called this plan as a high-level plan, in next planning iteration, project team can come with more accurate realistic estimation.

Time and resource estimation: Activities time durations are estimated based on a top-down, high-level estimation and based on the previously mentioned assumption of “the project will take approximately 6 months”. Accordingly, activities’ durations were estimated based on consultation with experienced project team members in similar projects and based on web research. Similarly, resources were identified, hourly rate selection, and further detailed in next paragraphs based on similar project research and national salary survey websites.

Other time estimation issues are considered in more detail in assumption and risk sections.

4.8.         Cost estimation and budgeting

With reference to assumptions section above, the following resource table was used to calculate project cost. We assumed project sponsor cost is included in overhead cost of the project.

Resources cost estimate per Unit

Resources listed above are loaded to the schedule and direct and indirect costs are generated accordingly, the following project cost estimates are resulted.

Project Estimated Cost – Activity wise

Project Estimated Cost – Resource wise

Project Estimated Budget:

Project budget is estimated as AU$313,762.68

4.9.         Critical Risk Identification plus mitigation strategies

We used the following table and risk scale to evaluate the risks

5. Conclusion.

The project team has identified a significant problem of urban noise pollution, especially in the nighttime, which decreases the functional capabilities of citizens since they face a lack of deep sleep at night. The team addresses this problem by developing a Noise Detection and Management IoT system as a part of Smart City Infrastructure. The main stakeholder groups have been identified as citizens, Police, and Government, which, interacting with each other through the system, create an automatization control layer.

For the successful implementation of the project, the team analyzed the current environment in order to gather functional and non-functional requirements for the system. Thus, the system should be able to sense the sound environment, detect noise pollution and inform police departments about violators. From a non-functional perspective, the system should be financially efficient, durable to sustain long-term use, expandable, and accurate.

The team has developed an architecture plan that will be further used by the development team in order to build WSN infrastructure. The Architecture Plan consists of: Use case model, Architecture model, Class model, sequence diagram, and set of UI mockups.

The project management team has developed a plan, including work scope, WBS, testing strategy, and risk mitigation strategy. The development and implementation of the system will take 130 days: 01.05.2022- 27.10.2022. The estimated total project budget is $313,762.68