This is definitely the furthest-along and most realistic set of plans I’ve seen. Props to the team working on it! Thanks as well for providing the numerous warnings, and asking for the eval (rather than jump in both feet first and start building/distributing, as some news agencies would want us to do…).
Although you didn’t ask for this,I wanted to provide some feedback on the embedded controls software (and am choosing to do this as a post, and not an IM, for audit purposes):
The Arduino is an excellent prototype platform, but will definitely be insufficient for maintaining safe operation. Safety Critical (medical included) devices generally will want some level of hardware-level redundancy and checking to ensure the controls are up and running. In addition, the main control loop is running “as fast as possible” , with telemetry and the pressure control loop at the same priority. Again, perfectly fine for prototyping, but you’ll want something more robust before you start pumping air into a human.
TI’s Hercules platform is one line of safety-critical processors that has the internal goodies required to ensure the code execution is still moving along nicely. I think it would satisfy your IO requirements as well. They sell a $60 launchpad module which, though not 100% drop-in with the arduino you have, would likely fit the bill. You’ll want to check their example code and docs to ensure the safety features are enabled, self-tested at power-on, and are applied properly to ensure the life-sustaining critical loop tasks are executing on time. Note this is in addition to your existing fault detection strategies.
Additionally, you’ll want to pair the new hardware with a real-time operating system that supports task prioritization and preemption (or, at least, some form of interrupt-based “this task needs to run now” concept). OpenRTOS is an option that can pair with that hardware platform. The key reason here is allowing your pressure control loop to be at a high priorty with a well-defined execution rate (20ms? 10ms? not sure…), while the telemetry, LED blinking, screen update, etc. tasks take a back seat.
Let me know if you’ve got questions - these aren’t the only options, just two I’ve happened to fiddle with in the past (abet in separate projects, never together).
Even using these, the device still obviously doesn’t hit regulatory requirements - but it would be much closer to what as an engineer I’d call a “safe” system for human life support. I’d definitely recommend having something to address the software/hardware solution on your roadmap going forward, if you don’t already.
Finally, and this is purely cosmetic: For ease of public audit, I’m much more a fan of K&R C style. But that’s a topic for another day.
All this being said, there is (as many others have spoken to) the liability question, which varies from country to country. I know in the US there hasn’t been a declaration of anyone-can-manufacture yet, which is fundamental restricting to teams without a legal department. Still, it is worthwhile being prepped if that ever does change, or requests come in from individuals you trust not to sue you.
EDIT: Again, I do really want to say great job! It’s this level of documentation and well-thought-out process and design that is useful for rapid iteration. Efforts like these are the ones that will concretely posture us to take on the great challenges we face!
