Rens Roosloot
Menu

Bioreactor DO Simulator URS

Volledige gerenderde weergave van URS.md.

Laatst gesynchroniseerd: 7 oktober 2026

URS - Bioreactor DO Simulator

Version: 0.1.0
Date: 2026-03-18
Status: Initial concept draft

1. Purpose

This document captures the user requirements for a browser-based Bioreactor DO Simulator concept to be hosted on roosloot.com.

The purpose of the project is to provide an interactive, visually clear demonstration of dissolved oxygen (DO) dynamics and PID-style control behavior in a simplified bioreactor context.

The simulator is intended to be educational and believable, but not a validated engineering or scientific model.

2. Scope

In scope for the initial version:

  • a standalone static web page hosted within site/
  • a simplified dissolved oxygen process model
  • manual input adjustment for key process variables
  • optional automatic PID control
  • real-time or near-real-time graphing of simulated behavior
  • concise explanatory copy and visible model limitation disclaimer
  • operation fully in the browser without backend dependency

Out of scope for the initial version:

  • validated process engineering use
  • full biochemical or cell-growth modeling
  • pH, temperature, perfusion, or advanced multi-loop control
  • user accounts, cloud storage, or server-side simulation
  • upload and replay of historical plant data
  • GMP/GAMP validated behavior
  • mobile-app packaging

3. Intended Use

The project is intended to be used as:

  • a portfolio/demo project on roosloot.com
  • an educational visualization of process dynamics
  • a lightweight interactive showcase for controller behavior

The project is not intended to be used for:

  • real process control
  • engineering design decisions
  • regulated manufacturing or GMP operations
  • validated scientific prediction

4. Intended Users

Primary users include:

  • visitors of roosloot.com
  • technically interested users
  • students and hobbyists exploring control loops
  • colleagues, recruiters, or potential collaborators

The experience shall remain understandable for users with limited prior control-systems knowledge while still rewarding more technical experimentation.

5. Functional Requirements

5.1 Simulation Core

  • FR-001 The system shall simulate dissolved oxygen behavior over time.
  • FR-002 The simulation shall update in discrete time steps.
  • FR-003 The system shall allow the user to start, pause, and reset the simulation.
  • FR-004 Reset shall return the simulator to a defined default state.
  • FR-005 The simulation shall behave deterministically for identical inputs.

5.2 Manual Inputs

  • FR-010 The system shall provide a manual mode in which the user can directly influence process inputs.
  • FR-011 The user shall be able to adjust oxygen-related gas input.
  • FR-012 The user shall be able to adjust nitrogen or equivalent dilution gas input.
  • FR-013 The user shall be able to adjust a process inertia or time-constant parameter.
  • FR-014 The user shall be able to adjust a reactor volume or equivalent scaling parameter.
  • FR-015 The user shall be able to adjust oxygen demand or background consumption.

5.3 PID Control

  • FR-020 The system shall provide an automatic control mode using PID-like control logic.
  • FR-021 The user shall be able to enable or disable automatic control.
  • FR-022 The user shall be able to set a DO target/setpoint.
  • FR-023 The user shall be able to adjust proportional gain.
  • FR-024 The user shall be able to adjust integral gain.
  • FR-025 The user shall be able to adjust derivative gain.
  • FR-026 When automatic control is enabled, the system shall calculate controller output during the simulation.
  • FR-027 Controller output shall influence the simulated process response.

5.4 Visualization

  • FR-030 The system shall display the simulated DO value on a time-based graph.
  • FR-031 The graph shall update dynamically while the simulation is running.
  • FR-032 The current DO value shall be shown numerically.
  • FR-033 When automatic control is enabled, the setpoint shall be visible in the graph or control panel.
  • FR-034 When automatic control is enabled, controller output should be visible numerically or graphically.
  • FR-035 The interface should help the user distinguish stable, overshooting, and oscillatory behavior.

5.5 Presets and Disturbances

  • FR-040 The system should provide predefined presets for example controller behavior.
  • FR-041 Presets should include at least stable, aggressive, and oscillatory examples.
  • FR-042 The user should be able to load a preset and run the simulation immediately.
  • FR-043 The system should support a disturbance during simulation.
  • FR-044 A disturbance should represent a temporary process change such as increased oxygen demand or a sudden response shift.
  • FR-045 The disturbance should visibly affect the simulated response.

5.6 Explanatory Content

  • FR-050 The page shall provide a short explanation of the simulator purpose.
  • FR-051 The page shall explain the meaning of key terms such as DO, setpoint, and PID parameters.
  • FR-052 The page shall clearly state that the simulator is a simplified educational model and not a validated engineering tool.
  • FR-053 All user-facing page content shall be available in Dutch and English.

6. Non-Functional Requirements

  • NFR-001 The application shall run fully in the browser.
  • NFR-002 The initial version shall not require a backend server for core functionality.
  • NFR-003 The application shall remain compatible with static-site deployment on roosloot.com.
  • NFR-004 Runtime-required files shall resolve from within site/.
  • NFR-005 The interface shall remain understandable without extensive documentation.
  • NFR-006 Controls shall be clearly labeled and grouped logically.
  • NFR-007 The page shall remain responsive and readable on modern desktop browsers.
  • NFR-008 Smaller screens should remain usable, even if desktop is the primary target.
  • NFR-009 The visual presentation shall feel polished and portfolio-ready while staying aligned with the existing site style.
  • NFR-010 The simulator shall avoid client-side secrets, API keys, and unnecessary third-party runtime dependencies.
  • NFR-011 Motion shall remain subtle and respect prefers-reduced-motion.
  • NFR-012 Input validation shall fail safely for user-controlled values.
  • NFR-013 Model logic and UI logic should be separable for future extension.

7. Constraints

  • C-001 The initial version shall be deployable without server-side computation.
  • C-002 The initial version shall avoid unnecessary architectural complexity.
  • C-003 The initial version shall prioritize believable and understandable behavior over physical realism.
  • C-004 The MVP should remain achievable as a personal portfolio project with reasonable development effort.

8. Assumptions

  • A-001 Most users will interact on desktop or laptop devices.
  • A-002 Users will expect immediate visual feedback from input changes.
  • A-003 A simplified process model is sufficient for the intended educational use.
  • A-004 The initial audience will accept conceptually plausible behavior without scientific validation.

9. Risks

  • R-001 If the model is too simple, technically knowledgeable users may find it unconvincing.
  • R-002 If the model is too detailed in the first version, complexity may slow delivery and reduce clarity.
  • R-003 If too many parameters are exposed at once, the interface may become cluttered.
  • R-004 If the disclaimer is weak, users may over-interpret the simulator as an engineering tool.

10. Acceptance Criteria

  • AC-001 A user can open the simulator in a browser on roosloot.com.
  • AC-002 A user can start, pause, and reset the simulation.
  • AC-003 A user can adjust core manual parameters and observe a changed DO response.
  • AC-004 A user can enable PID control and adjust P, I, and D values.
  • AC-005 A graph shows the DO response over time.
  • AC-006 The interface is clear, responsive, and suitable for public portfolio presentation.
  • AC-007 The simulator functions without backend infrastructure.
  • AC-008 The page includes a clear disclaimer that the model is simplified.

11. Future Extensions

Possible future versions may add:

  • pH simulation
  • dead-time or perfusion-delay behavior
  • changing oxygen demand over time
  • additional reactor presets
  • side-by-side comparison mode
  • data export
  • challenge/game-like learning mode
  • simple versus advanced model selection

12. MVP Candidate

The MVP should preferably include:

  • one DO graph
  • start, pause, and reset controls
  • manual oxygen input
  • manual nitrogen input
  • setpoint input
  • PID enable/disable
  • P, I, and D sliders
  • one inertia parameter
  • one oxygen-demand parameter
  • a few presets
  • a concise explanation and disclaimer block

13. Open Questions

  • Should the simulation run in real time or accelerated simulated time?
  • In automatic mode, should controller output map to one combined gas action or still expose separate gas controls?
  • Should reactor volume materially change dynamics in V1 or only act as a simplified scaling factor?
  • Should disturbances be included in the MVP or deferred to V2?
  • Should controller output be shown in a second graph for the initial release?
Terug naar home