SOFTWARE
Monitoring and ensuring optimal bacterial growth conditions can often be a time-consuming task due to the long periods required for bacteria to grow and replicate. This was no exception in our wet lab activities, as our bioreactor required constant supervision and in-person presence in the lab. Additionally, identifying problems and when they occurred was challenging. To address this, we developed a remote interface for the bioreactor, reducing the time required for supervision and automating data collection by storing bioreactor readings in a remote database.
To implement our software tool for the bioreactor, we used the Scrum framework, delivering features incrementally while adjusting after each iteration. The main stakeholders were our wet lab colleagues, who directly influenced the feature development, as they best understood the needs for automating laboratory activities. We started by defining the Minimum Viable Product (MVP) and expanded functionality over several iterations, allowing us to address their needs progressively. Each MVP provides an opportunity to learn from real user interactions and feedback. This helps refine the product based on actual user needs and preferences, rather than assumptions made at the start of the project [1].
Initially, we conducted a requirement analysis with the stakeholders and dry lab team members to outline the MVP. This approach ensured that the software tool was functional from the start while evolving through continuous feedback loops. With each MVP, we added more features to the bioreactor interface, eventually completing the full product specification as outlined below:
This iterative development process ensured that the tool evolved in sync with the needs of the lab. The Scrum methodology allowed for continuous value delivery and agile adjustments based on feedback, resulting in a robust and responsive bioreactor interface that effectively optimized laboratory processes.
Based on our project requirements, we identified the need for a modular software architecture, which includes several key components (Fig. 1):
We decided to containerize each of these components (except Arduino Client) using Docker to ensure a standardized deployment environment. Docker ensures that all dependencies and environment configurations are encapsulated within containers, preventing compatibility issues across development and production stages. This allows for efficient scaling, isolation of services, and easier updates. Additionally, containerization streamlines the development workflow by creating consistent environments across different stages of deployment, reducing the "works on my machine" problem and accelerating the release cycle [2].
Overall, this architecture ensures that the bioreactor software is robust, scalable, and efficient, allowing us to integrate all the necessary functionalities seamlessly.
We designed the database schema for the bioreactor software to efficiently handle measurements, control settings, and alert parameters in separate tables. As shown in Fig. 2, the schema consists of three key tables:
This schema ensures flexibility, allowing easy expansion with new sensors or control parameters by adding columns to the existing tables.
In the implementation of our bioreactor server, we have developed a comprehensive set of API endpoints to facilitate both data retrieval and control of the bioreactor’s operational parameters. The API provides endpoints for retrieving and updating control settings (e.g., mixing speed, temperature), posting and fetching measurement data (temperature, pH, turbidity), and subscribing to alerts. Subscriptions allow users to receive email notifications when specific parameter thresholds are met. Additionally, users can manage these subscriptions by subscribing, retrieving all active subscriptions, or unsubscribing. The API documentation is presented in an interactive format using Swagger documentation (Fig. 3).
One of the API consumers is the Arduino microcontroller, which every minute sends a POST request to the server with the latest measurements. After that, it sends a GET request to fetch the latest control settings. The server responds with the current control settings, which the Arduino uses to adjust the bioreactor’s parameters. If the temperature is lower than the set value, the Arduino sends a signal to a relay to turn on the heater. If the temperature is higher, the relay turns off the heater.
In our bioreactor web client implementation, we've created a user interface to access the server's endpoints. The UI is divided into three sections: Measurements, Controls, and Alerts.
All this functionality is demonstrated in the video below (Fig. 4).
The bioreactor server, web-client, and Arduino code are available in our GitLab Software Tool repository. The requirements for running the server and web-client are minimal, as all necessary dependencies are installed using Docker. The requirements are as follows:
The Arduino code can be uploaded to the microcontroller using the Arduino IDE.
We have simplified the setup process: the user only needs to run a single command to build and start all services after cloning the project. Follow these steps:
git clone https://gitlab.igem.org/2024/software-tools/vilnius-lithuania.git
cd vilnius-lithuania
docker compose up --build
This command will set up and start the following services:
You can then access the client by navigating to http://localhost:8000.
Overall, out of 5 planned MVPs, we have successfully implemented 4. The MVP5 was not implemented due to time constraints and the complexity of the glucose monitoring system. However, the current system provides a robust and efficient solution for monitoring and controlling the bioreactor remotely. The system has been well-received by our wet lab colleagues, who have found it to be a valuable tool in their daily activities. The system has significantly reduced the time required for supervision and data collection, allowing our team to focus on other critical tasks.