Architecture
| Kungliga Tekniska Högskolan | Architecture Description |
|---|---|
| WeatherBrain | Version <1.1> |
Abstract
| This document describes the architecture for the KTH “WeatherBrain” project. It describes the approach selected to meet the architectural demands of the specified system. |
|---|
Version History
| Date | Version | Author | Description |
|---|---|---|---|
| 11/04/2022 | <1.0> | Fredrik J | First edition of the architecture report |
| 25/05/2022 | <1.1> | Fredrik J, Casper, Philip, Daniel, Ville | Update for iteration 5. |
Table of Contents
The purpose of the Architecture Description is to describe the approach selected to meet the architectural demands of the specified system. The architecture description:
- Describes how the architectural demands are met by the approach
- Explains the most important design decisions
- Specifies the aspects of the design that must be consistent across the system.
The scope of this document is limited to consideration of:
- Architecturally significant aspects of the system.
This scope of this document does not include consideration of:
- Detailed analysis, design or implementation of non-critical solution elements.
This document contains the following sections:
- Architecture Goals and Constraints – references the subset of the solution requirements and constraints that are architecturally significant in that they shape the architecture and are used to validate the architecture
- Architecturally Significant Scenarios – lists the scenarios that are considered architecturally significant, along with their dependencies and relative priorities
- Architectural Views of Design Model - contains a set of architectural views onto to the Design Model that together define the architecturally significant static and dynamic aspects of the system design
- Other Architecturally Significant Views – optionally describes other architecturally significant views such as analysis views, deployment views and implementation views
- References – provides full reference details for all documents, white papers and books that are referenced by this document.
This section references the subset of the solution requirements and constraints that are architecturally significant in that they shape the architecture and are used to validate the architecture.
The architecture goal is that the group should develop an application where a user should be able to track and predict the weather at a location of their choosing. The user will be able to view the weather at the selected location using the web browser. The architecture “behind the hood” will consist of the IoT device which will collect the local weather data. This device will then upload that data to the Microsoft Azure database.
The different parts of the architecture will be working together with the machine learning component to deliver reliable and accurate weather data.
Each component of the entire architecture design will be working together to produce the required result. This means that each part of the architecture needs to be working correctly in order to produce reliable and accurate weather data.
The predictions will be limited to seven days in order to make the program reliable and easier to construct since the entire project is supposed to be finished in only eight weeks.
Below are the significant scenarios listed.
| Scenario | Priority |
|---|---|
| Concurrent usage of the service | Medium |
| Prediction accuracy | Medium |
| IoT device internet connection and database connection | High |
| Back-end service connected to the front-end service | High |
| Authentication / admin page | Low |
| IoT device and Machine Learning model | High |
One important scenario to handle is if for example more than one person wants to use the app at the same time. It should be possible to have many users using the app simultaneously.
The system should then be able to handle those requests and respond within a certain delay time. The measurement for this would be a couple of seconds. With a good design and build of the program this would be possible. We will create a concurrent web-server that can handle multiple requests, this makes sure that the application can be accessed from multiple users at the same time.
The weather prediction is suppose to be accurate, however first this project the goal is to get a prediction and we could make it
Another scenario is the prediction of the weather should be as accurate as possible even though quick changes in the present weather could occur. We will focus on getting the system up and running and educate ourselves and try different kinds of Machine learning models, in order to get more accurate results.
It is important to collect enough and good data for the actual spot where the live measurements should be, the machine learning functions should then be able to collect the quick changes in the present weather with humidity, temperature and air pressure and predict the upcoming weather for the upcoming hours/days.The different data should be over a certain interval to predict the upcoming weather.
The Machine learning model will have a small dependency to the IoT device, because we want to train the model with the new data that has been reported for the IoT device. Hence we want to ensure that the IoT device is connected to the internet at all times. The optimal way to approach this is to check and send errors if we get offline, so we can research the cause of the error and fix it until the next data package is sent.
Back-end needs to be connected and up and running at all times. The front end depends on it. If we host the server at a home computer there are more risks involved i.e bad configurations or that the server male function / shutdown. We will approach this by hosting the service on a server in the cloud, in our case Azure. Their servers are more reliable than setting up our own.
The authentication service can be achieved through different kinds of services, one would be to create our own, another could be Firebase Authentication. Which would be considered as more secure and we wouldn’t have to worry about GDPR and similar regulations. Our approach to solve this problem is to use Firebase Authentication, but this would mean more dependencies, in this case the Firebase Authentication. However it’s considered a reliable service.
The app will use a model-view-controller approach. This is because when the presentation layer of the app(the view) the model layer handling the data does not get affected. The team felt that this was the best way to approach the task so the work is easily divided and the team is able to work on different parts at the same time without any problems. The website will not show that much information, its main component is the weather prediction for the upcoming week. The model is very much like a DAO, it is an API that provides the data that should be fetched by the controller and displayed by the view. This component will contain relevant functions regarding the prediction and the data available.
Below you can see a 4+1 model to show the architecture from different standpoints.
The application will be deployed using Microsoft Azure. A Rest API will be created so that data can be fetched from the database on Azure. This will enable the programmers to easily access all necessary data and implement it in the chart, statistics and everywhere else it is needed in the application.
The raspberry pie will also have to be connected to Azure so that it can upload data to the database.
| WeatherBrain @2022 |
|---|