Skip to content

Retrieve emulator feedback

nikalc edited this page May 26, 2021 · 7 revisions

Retrieve car telemetry results, feedback and data back from the emulator into database to process for the frontend.

Summary

It would be in vain if the data being displayed was only accessible and visible for mere seconds. How would one benefit from that unless they had photographic memory? Thankfully, that was not our target audience although we all would benefit greatly if we had that type of memory. As a consequence we decided to integrate a database into the design. You may ask why? The answer is simply to store all the information being passed between the user and the emulator so that we ensure traceability, accessibility and controllability. Three keywords that coin our database design implementation. As a result enabling the user to read, modify and update data continuously.

Highlights

  • Store data from the emulator in a database system.
  • Displaying data from the emulator to the user on the frontend website
  • Total access to mission result database
  • Make retrieving telemetry results, feedback and data an optional setting.
  • Data storage system that facilitate safe, reliable and highly accurate data handling

Description

Milestone 3 was of great importance. It was the milestone were we carefully fine tuned our functionalities. Making them more specialised. Thus placing great emphasis on design while becoming more and more customer oriented in the questions we ask ourselves and the design implementation. Looking at design through a different lens. Through the users lens. Key questions unraveled some of the core design implementation. Integrating a database in order to work with potentially large amounts of data. To make working with the data easy, reliable and ensure high accuracy. On top of that we wanted to restrict information access to the user itself, granting them the ability to sort through data and modify it. Making the process easy, fast and efficient.

Also the design was carefully and well thought out. Everything from placements to which international system of units would be most appropriate considering the system itself but also taking into account for our target audience. A silver thread running through our work is to hand over the control to the user. Making the activation of certain functionalities optional so that the user can determine the suitability for each.

Functional Requirements:

  • The system shall be able to store data received from emulator
  • The website shall be able to access mission result database
  • The system shall display data from the emulator on the frontend application
  • The system shall display feedback to the user
  • The system shall transmit every change made to the emulator on to the frontend application
  • The system shall be able to make retrieving telemetry results, feedback and data an option visible on the frontend application
  • The system shall store telemetry results, feedback and data from the emulator in a database
  • The user shall be able to access the information stored in the database

Non-functional requirements:

  • Complete and consistent set data is retrieved from emulator, saved into a database and fully accessible for frontend to process for user feedback
  • The system shall display the car telemetry results, feedback and data to the frontend within a time period of 1 second set from the action.
  • The system shall display accurate and reliable results from the emulator to the frontend application
  • The database shall be able to store at least 1 MB of telemetry results, feedback and data.
  • The system shall display feedback in readable english textformat in time order