High-Level Requirements & Solutions

  • Wednesday, Nov 18, 2020
blog-image

Over the course of the first semester, Team Titan took the time to communicate with our clients with the purpose of establishing the needs for a final product. Provided here are the top-level, abstracted requirements that need to be met before we can deem our project a success:

Written in Python 3

The original version of our client’s software operates using Python2, which has just recently reached the end of its support cycle period. To provide the clients with extended security support and prevent external library deprecation, the move to the updated version of Python is mandatory.

Rewritten GUI

Our client established a Graphical User Interface (GUI) using a UI framework called GTK. The purpose of the user interface is to render data visualizations, and plot them to the screen in line-graph format. The control panel also enables the user to control the Cryocon temperature regulation device, delivering pre-determined commands to the device.

Because the UI is handwritten, and many variables are hardcoded into the one Python file, the team expects to:

  1. Redesign the UI using an alternative UI framework, Qt5, which provides excellent pre-made widgets and optimizations
  2. Modularize the UI from the main logic, which would allow the Ice Lab team to duplicate, and create their own UI implementations as their needs evolve over time.

Use a Database System for Storing Experimental Data

The current implementation uses data stored to CSV data files, which are stored in a folder hierarchy on the lab’s computer system. So that we can ensure that this data is stored in a more safe and reliable way, we plan to implement data storage using MariaDB, a database management system that the client is already familiar with, to store data. This adds features such as redundancy and data access tools.

Anticipate Hardware Upgrades

In the lab, one aspect of the job that we can guarantee is that the client expects to implement new features and new hardware as time goes on. The way it’s done currently is by writing small Python scripts, essentially drivers, that contain dictionaries of hardware API command bindings. Our team wishes to simplify this process by, as stated previously, creating the project using a modular, object-oriented approach. A specific module will be directed toward accepting these ‘driver’ scripts, and storing them in an organized project file structure.