I assembled the benchtop prototype yesterday in about 20 minutes. I will be using it to test the Arduino code in the coming week. 

All-in-all, the signals are very simple. Most of the microcontroller inputs and outputs only have two states - "on" or "off". Even for the 4 digit, 7 segment display and the water bath temperature sensors, there are existing code libraries that make controlling or reading from the components easy.

Five microcontroller inputs:

• two water bath temperature sensors
• sous vide cooker power momentary push button
• set point monitor momentary push button
• IV tube switch

Five microcontroller outputs:

• sous vide cooker power button red LED ring
• set point monitor button blue LED ring
• 4 digit, 7 segment display
• buzzer
• sous vide cooker power relay

The challenging part is developing the logic to enforce a conditional operating sequence. Enforcing which and when controls are available to the operator is a strategy to reduce the cognitive load on the operator as well as to prevent the operator from creating a hazardous condition. Ultimately, this approach is used to ensure the safety of the operator and the patient during device operation.

With the understanding that detailed and easy-to-understand documentation is an important part of open-source design, I have taken the approach of documenting the operating logic in table format. It is something I made up and it does not yet capture all the nuances. I imagine there has to be a better format out there for this type of logic (pseudo code maybe?). Please leave a comment if you have a suggestion.

The table below details the following statement in Boolean logic: "When the device is plugged in, the sous vide power standby and water bath temperature monitor will be activated." The columns represent only the objects that are effected by the control action. The initial conditions must be satisfied in order for the action to be valid. The final conditions are enforced once a valid control action has occurred.

In the example above, the descriptive statement provides more clarity than the table. I find that the opposite quickly becomes true when documenting a control action that is dependent on multiple initial conditions and results in a multitude of final conditions.

It's hard to identify gaps and improve the conditional operating sequence without a good comprehensive format. I know I can just start coding without a solid plan upfront and eventually arrive at the intended operating logic. For the OpenFluidWarmer, the goal is not to just arrive at the intended operating logic but also to justify each line of code and prove that all gaps are closed.