...
Overall Description
Regterschot Racing expects wants us to create build an API where a member of the racecrew can view the data sent by a racecar in real-time. Regterschot expects . This data needs to be converted into charts that accurately represents the data in a clear way. This means that the data should be understood by the raceteam. All graphs are placed in a dashboard that is seen by crewmembers that are logged into the application. Viewers can also see a restricted set of data. Regterschot wants this API to be deployed in a web-application. The data that is retrieved from the broker, will eventually end up in a database. The web-application and needs to have a stable constant connection with the database. It to the database, to show past data. The present data is retrieved from a broker that the team at Regterschot Racing had already made. This broker will send data twenty times per second to the application. It is important that the communication with the database and broker provides a fast and reliable way to bring data to the website. The system needs to be easily expandable, so that it may be able to add new features in the future. Because Regterschot Racing wants this application to be expandable, we need to have a clear and informational instruction on how the code works. Our project will be followed up by multiple groups that will build upon our code. These groups might be international groups and therefore everything needs to be documented in English, so that they may understand how our code works.
User Classes and Characteristics
...
Our web-application's back-end will be built in Java 17 and Maven and our front-end will be built in Angular 14.0 and Bootstrap 5.0. The application will run in Wildfly 25.0.0, which allows us to run the website locally. We will use Java Database Connection (JDBC) to establish a connection between our database and our web-application. We'll also use a Broker to establish a connection between the racecar's sensors and our application, which allows us to recieve receive a constant stream of data. The broker will also send data to the database, so that past data can be seen aswell.
Design and Implementation Constraints
The product owner has not given a lot of constraints for this project. There are still a few technical limitations that limit our options. The car's data is being sent to the database twenty times per second. For constant streaming of data to the application, it is required to use TCP as a communication protocol. This data has to be converted into charts and in order to do this fast and reliable, we will have to use Google Charts. Google Charts runs in a web-application and can update the data twenty times per second (Lijden & Kooy, 2022).
Product Functions
The product must present data from the sensors of the racecar. The user is able to login to the site and choose how the data is presented. The product stores all the data from the sensor for future purposes. The crewmember is able to add, delete and update a tab. The crewmember can place charts in the tab that contains data from the chosen sensor. The viewer and crewmember can watch past and present races.