Envisioned Solution

The solution we are building will be comprised of four parts. They are as follows: a simulator that generates output a Site Weather and Power Recorder (SWAPR) device would produce, reader software which reads and packages data sending it in a TCP packet to our database server, a database server which takes in the TCP packets to build custom object and store it, a website which will take in objects from the database server and serves as our GUI environment to be used by coast guard. Pictured below is our subsystem diagram that exemplefies this.

As you can see from our System Diagram above, we have five different subsystems: Simulator, Reader, Database, Website, and Orchestra.

We will first take a look at our Simulator Subsystem. There are two main parts: Randomly generating SWAPR data and Sending data over RS-232 protocol. We will complete use System.Random class to complete the first requirement. Our second requirement will be solved using the Serial Port class. Both classes are a part of the .NET framework.

The second subsystem we will look at is the Reader Subsystem. The reader subsystem also has two parts: Reading data over RS-232 protocol and Sending that data over a TCP connection. We will complete the first part using the Serial Port class. The second part will be completed using the TCPClient class.

The third subsystem will be the Database Subsystem. We have two parts: Establishing a TCP Host connection with the reader subsystem and hosting the server on AWS. Our first part will be solved using AWS SQS which will allow us to connect to the database securely without exposing the database to the outside world. This will be done by connecting with AWS SQS over a TCP connection and sending the data collected. Once the data is in the SQS queue, we will use AWS Lambda functions to send the data to our database. The second part will be hosting the database on AWS using RDS. This is a pretty simple task but setting up the security policies to link the database with the SQS queue will take some tinkering.

Our biggest subsystem is the Website Subsystem which has two parts the frontend and backend. The frontend will be responsible for creating a list, map, and chart view that summarizes the data in a human readable way.

This is an example of the website frontend list view.

This is an example of the website frontend map view.

This is an example of the website frontend chart view that displays the Wind Direction and Speed, Wind Speed, and Antenna Power Frequency Chart.

The second part of the website is the backend. The backend will be responsible for providing the functionality needed to make the frontend work. We will need a way to have user accounts and role-based permissions, notification system, database management system, and data export system. The user accounts and role-based permissions will be faked in our MVP and if time and budget allows then we will use Windows Active Directory to solve this functionality. The notification system will be responsible for analyzing the SWAPR data that is retrieved for one of four statuses showed in the table below. If there is a status that is anything other than green then the notification system will queue an error message to show to any user with an admin role. The database management system will be responsible for collecting to the database and querying for data in two ways. The first way will get the newest entry from every SWAPR device in the network to support the list and map summary views on the frontend. The second query will get data from one SWAPR device over a date range to support the chart view. The data export system will use the second query type and will export the data used to create charts into a .csv file for external purposes.

Our last subsystem is called the Orchestra subsystem. The Orchestra will be responsible for creating a connection between the Simulator and Reader subsystems over a virtualized COM port. The Orchestra subsystem is a stretch goal but if completed then it will be used for lab stress testing of the SWAPR system. We plan to complete this subsystem using an open-source program called com0com and some custom windows scripts to automate the process.

As we start to implement the solution outlined above, we expect for things to change but we feel that we have made our best attempt at identifying a solution that will satisfy our client. Even if our packages and frameworks change, we expect that our solution outline will not change much. If you would like to read more on our plan to implement this project then please refer to our Tech Feasibility document.

If you are interested in learning about our key features more then take a look at our High Level Requirements page which outlines the key requirements, functional, performance, and environment requirements.