NoiseTracker Web Application
Underwater noise pollution can impede marine fauna from using sound for essential life processes such as foraging, socializing, and navigation. Raincoast Conservation Foundation (RCF) approached the UBC Cloud Innovation Centre (UBC CIC) wanting to gather more sound data to help with analysis, research, and policy recommendations to support conservation of marine habitats. The NoiseTracker prototype was developed – a client application coupled with a cloud-native web application – to enable information sharing of underwater sound levels.
Approach
RCF and the UBC CIC developed the NoiseTracker prototype – a robust solution that includes a client application that enables hydrophone operators to contribute acoustic data to the Noise Tracker platform and a cloud-native web application that can be deployed for use by administrators to manage the web application and onboard hydrophone operators, and the general public, to view noise metrics and noise data visualizations.
Background
According to Raincoast Conservation Foundation, the natural soundscape of our oceans — waves, wind, the musical vocalizations of whales and other rhythms of marine life — is being drowned out by human-made noise (i.e. noise pollution). Underwater noise is highly pervasive, as sound travels 4.5x faster in water than in air, and many marine organisms rely on sound to carry out essential processes such as feeding, navigating and communicating. Excessive noise levels can damage animals’ hearing, and constant, pervasive noise can act as a thick smog that blankets the natural soundscape, interfering with these important functions for many marine species.
Many organizations, including nonprofits, First Nations, academic institutions, local governments, and industry leaders monitor ocean soundscapes along the Pacific coast using hydrophones (underwater listening devices that detect and record underwater sounds).
These monitoring efforts are currently disjointed, with no single, unified approach. NoiseTracker aims to foster collaboration between these existing operators to monitor underwater noise trends on a central platform, increase science-based decision-making to reduce noise impacts on marine life and inform the public about anthropogenic noise.
Solution Details
The Software Client
The software client was developed to be installed on the computer devices of hydrophone operators and can enable hydrophone operators to share sound data with NoiseTracker. Administrators can meet with members of the acoustic monitoring community to determine if they would like to be involved. Once a hydrophone operator agrees, an administrator can install the software client, configure the settings for hydrophone operators which then allows sound files from the hydrophones to be processed and sent to NoiseTracker in the cloud.
The Web Application
The web app consists of functionality for authentication, data storage in AWS, a central dashboard for administrators, a settings tab for hydrophone operators, and public view of an interactive map. In the back-end of the application, users can be authenticated and data can be processed in the AWS cloud and utilized to display information for presentation on the web. The web front end allows general users to view a map of the coastline, see where hydrophones are located, click on hydrophones and view various noise metrics such as Sound Pressure Levels (SPLs) and spectrograms of the past 24 hours. Hydrophone operators can use the web app to download the computed metrics from their hydrophone data and view a directory of other hydrophone operators for collaboration purposes. Administrators can add and edit new hydrophones and operators, and manage the visibility of various metrics.
Screenshots of UI
Interactive Map
Operator Profile
Admin Dashboard
Technical Details
This section provides an overview of the components and services we used to develop the prototype.
The solution consists of 3 main components:
- The client software which will run as a desktop application
- The backend data processing layer that interfaces both the web and client applications
- The web application with separate views for members of the general public, hydrophone operators, and administrators
The client software gets installed onto the Hydrophone Operator’s local computers and the web app and backend are deployed in AWS. Once the client software is installed and configured on the Hydrophone Operator’s desktop, the hydrophone data gets processed and is sent to the backend data processing layer in the cloud.
Administrators input hydrophone operator configuration information into the database through the admin dashboard, enabling them to publish the hydrophone metrics through the public view of the web application.
Architecture Diagram
Step-by-step
The following includes a simplified walkthrough of the solution and describes how all of the components interact.
Client Software
The client application is a portable platform-independent executable application for hydrophone operators. After an initial configuration, two processes run in parallel.
The Analyzer Process monitors the audio files in the hydrophone’s output directory and detects new files. Once a new audio file is detected, the client reads the audio data from the file and processes data into multi-decade SPL data, which is time-stamped and saved as a JSON file in a temporary results folder.
The Uploader Process checks the temporary results folder periodically and uploads any existing SPL JSON files into the cloud storage. After the upload process, temporary files are deleted from the local results folder to save space on the client.
- Client software fetches the hydrophone details and configurations by calling an API endpoint. This endpoint invokes a lambda function (7) that fetches the details from the Noise Tracker Database (8).
The client application also needs to upload the analysis results into the cloud, which is done by uploading JSON files in the Noise Tracker S3 Bucket.
Backend Data Processing Layer
The backend consists of storage and processing units. An S3 bucket is used to store milli-decade SPL data, spectrograms, and hydrophone details. The processes in the backend are handled by AWS Lambda functions which run periodically or on demand to perform a specific task.
- Upon successful authentication, the API Gateway will forward the request to one of the lambda functions.
- For requests requiring data from the database, the lambda function will connect to the RDS PostgreSQL database with the appropriate query and get the data.
- For requests related to S3, the lambda function will request to get objects from S3 and return data accordingly.
- Once a day, the average monthly SPL values are calculated using data from S3 and are stored in the database.
- Once a day, the 1-minute interval spectrograms are combined into a single daily spectrograms which are stored in S3.
- Each hour, the 1-minute interval spl data is combined into hourly spl values which are stored in S3 to reduce the size of the data the web application needs to fetch.
When an admin creates a new operator using the admin dashboard, a new user is created in the Cognito user pool.
Web Application
The interactive map page is the default view in the web app. Users can view broadband and specific frequency band dB levels, spectrograms, SPL diagrams, and hydrophone metadata. Operators and administrators can also log in to access different views and functionalities specific to their role.
- The user sends a request to an Amazon CloudFront distribution with caching enabled. If there is a cache hit, CloudFront returns the cached data. The AWS Web Application Firewall (WAF) helps to protect the application from common web exploits and bots that can affect availability, compromise security, or consume excessive resources.
- On a cache miss, Cloudfront will send a request to an Application Load Balancer (ALB).
- The ALB checks the health status of the container. If the status is healthy, it forwards the request to the container which runs on Amazon Elastic Container Service (ECS). The ECS loads a container image file that contains the web app from a repository in the Amazon Elastic Container Registry (ECR). The image file is used to run on a container as an ECS task using Fargate, a serverless compute engine for containers. If a task fails, the ECS Service will redeploy a new task.
- When an admin or operator user logs in to the web app, the web app will forward the authentication to Amazon Cognito. Upon successful authentication, a JSON Web Token (JWT) is returned.
- The web app then makes requests to various endpoints on the Amazon API Gateway.
- Each request is passed with the JWT token that will trigger an AWS Lambda Authorizer to check if the user is in an authorized user group (admin or operator).
Check out the web app solution on GitHub.
Learn more about the client software on GitHub.
Visuals
Infographic
Demo Video
Acknowledgements
Photo by Mark Williams. Photo not to be shared, re-used or distributed without express permission from the photographer.
About the University of British Columbia Cloud Innovation Centre (UBC CIC)
The UBC CIC is a public-private collaboration between UBC and Amazon Web Services (AWS). A CIC identifies digital transformation challenges, the problems or opportunities that matter to the community, and provides subject matter expertise and CIC leadership.
Using Amazon’s innovation methodology, dedicated UBC and AWS CIC staff work with students, staff and faculty, as well as community, government or not-for-profit organizations to define challenges, to engage with subject matter experts, to identify a solution, and to build a Proof of Concept (PoC). Through co-op and work-integrated learning, students also have an opportunity to learn new skills which they will later be able to apply in the workforce.
