Makers vs. Virus: Community Contributed Efforts to Help Combat COVID-19!

We're still in the midst of it. It's unfortunate, but true.

Despite best efforts of everyone in practically every single aspect of life possible, we're still seeing new COVID-19 cases daily.

However, there is an incredible sense of community being displayed in the response to this recent hardship.

We've seen a slew of DIY projects.

From creating Arduino-driven, servo-swinging, hand sanitizer-slinging robots to throwing machine learning at NVIDIA Jetson boards and FLIR Lepton thermal camera data, there's a lot of people hell bent on helping the cause.

Perhaps the one of the more noteworthy bits of news on this topic was the release of the design files for the Medtronic PB560 ventilator.

Those interested in taking a look at the initial file set from Medtronic are free to register their details on the download page here.

It's a validated, proven design, having shown up in the wild in successful deployments under a number of re-badged offerings from various suppliers; it's a familiar face to a large number of healthcare professionals.

This is actually quite a big deal, but it's no free lunch.

Medtronic is certainly to be applauded for this gesture. With they amount of work that goes into getting a reliable, tested and certified/validated device onto the medical market, this release massively lowers the bar of entry to this party.

We need this, because unlike the designers at Medtronic, not all of us are design engineers with the years of experience, and awareness of all the potential deadly pitfalls that present when designing a machine that has to interact with humans on such an intimate level.

Let's be frank, these Arduino temperature sensors are well intentioned, but they are never going to get medical approval for use in a clinical settings, and the risk of a hobbyist board latching up for whatever reason, while driving a ventilator turbine at full speed is obviously not acceptable! Let's not even consider a code error driving it into reverse flow...

There are a huge number of design constraints, which extend far beyond the ones people commonly consider, such as power supply and front end isolation, to EMC emission and susceptibility testing.

There's traceability required on such gas-whetted parts as those involved in oxygen enriched service, so that they don't end up with a combustible o-ring, or washer, that might burst into flame during use.

There's the need to employ every belt and braces trick you know, and then some.

Hardware watchdogs? You'll get familiar with those very quickly.

How often do you CRC your serial comms? That's likely going to be a necessity here. Thermal de-rating of parts, Monte Carlo Analyses, part obsolescence, all of this, and so, so much more, has to be considered at nearly every stage of design when working on a product that is subject to such heavy regulation.

You really don't want to have to take multiple runs at certification, many companies have failed to survive failing the first attempt.

There is an absolutely mind-boggling list of things that need to be designed, produced, and passed through the supply chain just right, before being assembled in a facility that also has all the requisite production engineering support.

This thing has to work. No matter what gets thrown at it!

But we have the files right? So we're done?

Not yet, no.

With five main file pack releases, over time, already there is some hesitation on where to start.

The first release was initially lauded, but soon enough found itself berated as lacking anything that could actually be produced.

53MB seems a little light for even the simplest of design packs. With no Bill of Materials (BoM), there wasn't much sense to the design, with no suggestion of what parts were meant to be where.

Roll on Release 2.0, some two days later. 296.1MB! Now we are seeing the sort of files we'd need to get a basic production run perhaps quoted.

Release 3.0 starts to really dig down into the system internals. We're seeing source code and checksums now!

Finally, the "mechanical source". No longer do we have just the part drawings, we have the mechanical CAD files from which they were generated. 627.7MB of SolidWorks assembly data, BoMs, and other information.

Release 5.0 is a nice gesture, "compiled software files" — firmware — for the MCU devices used in the design.

In just over a week, Medtronic have pulled together everything that makes up this product, and made it publicly available. That's an impressive, and significant effort.

"So!" I hear you decree, "surely, we now have everything, let's go, let's build!"

Hang on, still, no I'm afraid.

We have a complete design, that while we have a guide for, is still a puzzle that that relies upon a number of still-proprietary pieces. We need to remove the proprietary elements that gate the production process currently, to make the design as open, and producible as possible!

How do we do this then?

There is a huge effort currently underway, spearheaded by Seth Hilbrand, one of the lead developers for KiCAD PCB and part of the KiCAD Services Corporation, who offer support and consultancy for those who want to get the absolute most out of the package in a corporate environment.

Over on the very active openventilatorSlack group, a torrent of activity is happening, covering all aspects of the design process.

Electronics

The major stumbling block in ramping up the production the original Medtronic design is significant; while it was a solid choice in the day, the main MCU used in the design is EOL.

That's a big issue. Even with last time buy orders maybe existing in a warehouse somewhere, that's not at all acceptable to base future production on.

So already, an effort needs to be made to find a suitable design upgrade path. We need to re-track the main board at the very least.

Code, porting and compilers, oh my!

Within the PB560 box, there are three PIC MCUs used, in addition to the obsolete ST10 part.

One of these, the BMS (Battery Management System) is black box, and programmed with a pre-compiled hex. That's not a deal breaker, but at the very least, it's might be wise to predict that we may need to adjust that at some point, especially with re-implementing the main system functions on a new MCU.

So, as it stands, the code base is currently split across two proprietary IDEs, with Keil being needed to implement the ST10 work, and MPLAB used to support the PICs.

With the ST10 being replaced, there is scope to move away from Keil, towards a more open tool chain — but to what? Perhaps some of the Microchip Arm offerings could lead not only to a simplified supply chain, but also a simplified coding environment?

That's part of the ongoing work — to identify a replacement part that makes sense not only in terms of capability — it has to meet the same requirements least as the ST10 - but also that is sourceable, and has an open ecosystem.

Poking around with the PCB files...

It's important to note that we also should look at what design tools were originally used to create the ECAD files.

PADS, Altium (CircuitMaker), EAGLE, they are all solid choices for porting the ECAD work to, but these are not board that will satisfy licensing for the "freemium" versions of any of these products.

KiCAD is the obvious choice, and with skilled users jumping straight into translating the board layout and schematics over to PCBnew and EEschema respectively, this also affords us great opportunity to make any adjustments needed to other obsolete parts/packages, and tidy up some of the visual bugs found in the original files.

Mechanics and tooling

While we now have the mechanical CAD source, it's worth taking a moment to talk about file interoperability.

We've got the design source, but the majority of the work has been done in Solid Works — one of the main MCAD workhorses of the industry.

However, it's not free software, far from it! Given what it does, that's understandable — there is a reason it's a staple application in any mechanical design house.

So, in a bid to open the design up to as many people as possible, we need to consider potential alternatives, when exporting the files for production. Using a more open format here can really help when sourcing for suppliers!

Dassault Systems has stepped up to the plate, and offered licensing to those actively working on this effort, allowing us to modify and export parts and assemblies along with generating all the required drawings to get the parts actually made!

You might ask, why not just bounce out the STEP and DWG files needed from SolidWorks, and be done with it?

Tooling

Recall the sleek lines of the PB560 at the start of the article? Those lovely injection molded curves. The beautifully formed ports. The membrane keypad that help with IP rating.

Taking the STEP and DWG files, as is, to the bevvy of manufacturers that will need to quote on the parts, will likely be a painful process.

If a plastic part is injection molded, there's a requirement for tooling. That's usually not at all cheap, and you may be looking at several sets of tooling for each part.

That keypad will take some time to layout and have the masks generated for the screen printing of the silver traces, not least the text and graphics inked on to the buttons.

If the source is open, we can change it.

While we want to keep the number of adjustments and amendments to the project structure to an absolute minimum — this design will have to be approved again after any changes, and that takes time and money, so we want to keep that effort as low as possible.

But, if an intricate part with complex tooling requirements results in huge lead times on manufacture, this is where the open nature of our translation efforts comes through in spades.

With an open design, an injection molded part with a long lead time can be redesigned, say, to be produced using 3D printing (SLS,SLA, etc), perhaps at lower cost, but more importantly, more quickly.

We can soak up the time delays imposed by tooling requirements by adjusting certain parts so that they can be produced using more time-favorable processes and technologies.

Right, finally, let's build it!

Hold on, just one more thing. Production support!

This complex machine needs to be actually built.

• There are things like assembly tooling and jigging to consider.
• Did any of our changes have any impact on those fixtures?
• Are things like a PCBA test procedure and automated test equipment provided?
• Can we supply programming equipment to any PCBA contractors?
• How many of the build stages are concurrent/parallel?
• Is this to be built by one sub-contractor, or is it more suitable to have several specialist sub-contractors supplying parts to a production line elsewhere? How many sets of production tooling are needed?
• Much, much more...

A full compliment of production support can in some cases involve nearly as much work as designing the product in the first place!

We're all in this together!

There's an amazing team working diligently on this, but we're also seeing support from some amazing companies being thrown in.

• Without question, this wouldn't be happening if not for the initial contributions from Medtronic. Not only in their release of the design, but for the efforts of every single employee who helped design and produce this product.
• @MicrochipTech have amazing application engineers throwing advice into the ring, helping us out with Compiler licensing and product support.
• @Adafruit — Phil Torrone and Limor Fried have jumped at the chance to offer support where they can. Their enthusiasm is inspiring.
• Both @OSHPark and @AislerHQ have offered free PCB fab services for the efforts.
• @DassaultSystems — the company behind@SolidWorks have offered software licensing to support the mechanical CAD work.
• Even @Microsoft have jumped in with an offer of licensing support, should we need an OS to run Solid Works on, or supporting software.
• @SethHilbrand/@KiProEDA have spearheaded this effort, and deserve a real shout out.

Want to help?

Of course you do. But where to start?

Engineers of all types are welcome. If anything I've touched on here resonates with you, perhaps through professional experience or training, we'd appreciate your help!

First up, head on over to the GitLab where the current project is hosted — https://gitlab.com/openventilator — and start taking a look at the various projects and efforts.

Current advice would to be to get in touch with Seth, or myself, with a bit of an intro, and we will be sure to point you at the right direction for somewhere to focus your efforts!

(Ed: I'll update this when a more formal process for resource allocation goes ahead.)

We look forward to seeing more solid efforts such as this one, and being able to write more on the way in which everyone is chipping in and contributing.