Our goal at Opentrons has always been to democratize lab automation. To do that, we’ve worked hard to:
So far, we’ve focused on point 1. Now, we’re laser focused on point 2.
Enter the Opentrons Protocol Designer. We wanted to give our users an easy way to design scientific protocols without having to write any code. The barrier of entry to use lab automation is already high enough; why should you also need to know how to program?
It all started with a vision to model scientific protocols as mathematical functions, no different than the ones we were taught back in elementary school math class. When we see a mathematical function being described like this:
y = x + 1
We know that given an input x, all we have to do is add one in order to get y. We have an explicit mapping of input to output, which makes solving for our output (y) very clear.
At Opentrons, we see scientific protocols the same way. Protocols take in some input (e.g. nasal swab sample), combine it with reagents using labware through a series of actions (transfer, heat, mix), and produce an output.
This really excites us, because it presents a framework to view scientific protocols as clear, reproducible, and shareable. That framework is clearly illustrated in these graphics, which we developed at the beginning of the Protocol Designer project and still demonstrate our high-level goals with the tool.
Using this protocol model, we created Protocol Designer to be a web application where users can:
Protocol Designer allows you to visualize the state of a protocol before and after each action. You can see where on the deck each of your liquids are, which pipette tips and labware are being used, and the status of each of your hardware modules.
In order to do this, we continually generate a “timeline” of your protocol. The timeline represents how the state of the OT-2 changes over time. Each snapshot of the timeline captures things like your liquid volumes, number of tips left, and labware locations. Whenever a user adds a new action or modifies an existing action, the timeline will get recomputed in order to reflect the change.
Let’s say you wanted to create a protocol that heats some liquid, and then transfers it into another test tube. What would happen is something like this:
Because the timeline is continually being recomputed, Protocol Designer is intelligent enough to spot errors during protocol creation. For example, you can’t heat a liquid if you don’t have the right equipment, and you can’t transfer more liquid volume than your pipette can handle. Guiding users with validation during protocol creation is much more efficient and cost-effective than a trial-and-error approach.
Protocol Designer constructs a timeline so users can visually track the progression of their protocols, but eventually it needs to tell the OT-2 what to actually do.
Protocol Designer does this by iterating through each action and spitting out a list of commands that the OT-2 will recognize. Think of it like a shared language that both Protocol Designer and the OT-2 can speak. It follows a strict contract enforced by a JSON schema, which you can think of as the shared language’s Oxford dictionary.
In the simple protocol example earlier, the list of commands that Protocol Designer would generate for the OT-2 would look something like this:
When you export your protocol in Protocol Designer, it will generate a JSON file including a list of commands like this example.
At this point, we need the OT-2 to be able to read and execute the commands. This is the job of the protocol API executor. When you upload a JSON protocol, it will parse the commands and call the Opentrons Python API with the parameters associated with each command. This results in the OT-2 executing the protocol!
Since Opentrons started building Protocol Designer in 2017, it’s come a long way. It started as a tool to automate common qPCR prep protocols, and grew into a bottom-up approach to design any protocol with pipette liquid transfers. We then added hardware module support and the ability to upload custom labware. We’re now well into 2020 and Protocol Designer has grown into a full fledged solution for scientists to design protocols that tackle some of the toughest problems they face, including COVID-19 testing. Roughly 40% of protocols being run on our OT-2s are designed using Protocol Designer – and that number is steadily growing.
As we continue our journey to democratize lab automation, we see Protocol Designer as a critical entry point for our users. In order to truly make lab automation accessible to every life scientist, we have to continue to make our system as easy for non-coders – meaning, the majority of life scientists – to use as possible. Looking ahead, we’d like to improve the experience of fine tuning a protocol (protocol optimization), and, eventually, the protocol sharing experience. Even further down the road we’d like to enable scientists to design protocols in a more declarative, top-down way (explaining what to do, instead of how), so they don’t have to worry about the implementation details of a protocol. Rather than having a user explicitly build all of the individual actions that comprise a standard qPCR prep protocol, we’re building Protocol Designer to already know what those actions are and guide users through entering them.
But let’s not get ahead of ourselves! We’ve got a long way to go before we get there, and the problems we have to solve along the way will not be easy. It’s a delicate art to both build for the future while staying flexible. As we continue our journey to empower scientists to move faster, and to solve the problems that we desperately need them to, our team is committed to remaining humble, listening closely to our users, and taking it one step at a time.
