Time to take a break from talking about instrument support and wax philosophically about a bigger support challenge – integrated systems. A colleague asked me my opinion of the SiLA, a consortium that is creating standards for lab automation instrument interfaces.
As I understand it, the folks behind SiLA have a business model that will define these interface standards and then presumably charge instrument manufactures for the privilege of claiming “SiLA Compliant,” or some such declaration. I have to admit that my knowledge of this model is sketchy at best, and the SiLA website does not really lend much insight.
This seems a bit like putting the cart before the horse to me. That is to say, the instrument interfaces are fairly useless without a higher level scheduling software that manages assay workflow, instrument status and data.
In the 1980’s and 90’s, there were many such products from well established system integrators such as RoboCon (acquired by CRS Robotics), CRS Robotics (acquired by Thermo Electron, who merged with Fisher Scientific), Scitec (acquired by Zymark), Zymark (acquired by Caliper, who merged with Perkin Elmer) and Velocity11 (acquired by Agielnt) — do you sense a theme here? All this M&A activity happened during the HTS and uHTS craze. Once that goldrush ran it’s course, it became clear that system integration is difficult in a public company. It’s hard to take a 16-20 week design/build/install model and cram in into a quarterly revenue model. Systems needed to become smaller, more standardized and less expensive.
Nevertheless, each integration company created their own assay management and scheduling software and wrote their own libraries of instrument interfaces. Hundreds of systems were installed and not a single one required the involvement of SiLA or any other instrument standard. One common thread that enabled each of these software’s to succeed was the widespread adoption of Microsoft’s COM, OLE and eventually ActiveX and .NET frameworks. As long as instrument manufactures included automation “hooks” based on the MS framework, integrators had little trouble creating robust instrument interfaces. It’s really not that complicated, as you really just need to be able to initialize, start, stop and report error status for most instruments. Data (from readers primarily) was generally a secondary consideration and not part of the scheduling paradigm.
So flash forward a few years and there are remarkably fewer pure integration companies left. Caliper/PE and V11/Agilent are still out there, but not perhaps as visible as they once were. Thermo Fisher now has a more limited presence as well. To be sure, companies like Beckman, Tecan and Hamilton still build systems but they are primarily liquid handling companies first, integrators second. Really only HiRes Biosolutions, Process Analysis & Automation Ltd. or PAA and Hudson Robotics still fit the pure integrator definition.
It would seem to me that without an Open Source scheduler software standard, there isn’t much need for an Open Source instrument interface standard. Each of the companies mentioned above already have significant investments in creating their device libraries. What is the incentive for them to abandon those interfaces (many of which they charge for) in favor of the SiLA standard? I’m not saying they wouldn’t but I’d like to hear a good business argument for it, other than fear of someone else doing it. In fact, I would imagine that an Open Source scheduler could exist nicely even without SiLA, much as the proprietary schedulers have existed. As users create interfaces to various instruments, they would put them into the public domain for anyone to use…no SiLA required.
A few years back, a number of folks in the Cambridge, MA community came together and started to discuss an Open Source scheduler. About two years ago, Caliper donated it’s CLARA/iLink source code to the University of Wales, in Aberystwyth which can still be found on Source Forge under the name LABUX. Last fall, two MIT students created a similar effort called Clarity. I have not followed either of these endeavors closely, but it seems to me that they could either solidify SiLA or bury it.
My opinion? When I ran the system business at Caliper, prior to the PE merger, I was not a big fan of Open Source scheduling. I knew the investment we had made in our own software and although I knew it had it’s limitations, it was enabling technology that created significant revenue. Still, I saw the LABUX initiative as a way of testing the waters. If an open source scheduling standard did emerge, better that it be something we were familiar with. Additionally, if we could build systems and not have to maintain the software staff to maintain the scheduling software, we could in theory be more profitable (that public corporation thing again). Now, two years removed from that role, there does not appear to be solid consensus on Open Source scheduling or interfaces. I have no stake in the game anymore, so perhaps I can now be a bit more candid and say. I am a big fan of the pure integration model, so I am rooting for HiRes, PAA and Hudson! I still don’t get the whole SiLA thing. Seems a bit… SiLLY to me.