SiLA Love Songs

Time to talogo_silake 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 establishepolarad 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 systemsMicrosoft.Net 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.


This entry was posted in integrated system, Lab Maintenance, Liquid Handlers, robots and tagged , , , , , , , , . Bookmark the permalink.

21 Responses to SiLA Love Songs

  1. Neil Benn says:

    If the SiLA standards were truly open and free then it would be of use and you can then build a scheduler on top of it. I was initially attracted to LECIS when it was about a few years ago but it was overly complicated and fell by the wayside though a Canadian integrator company used LECIS I think. COM/SOAP/REST or any other acronym is just comms technology; what an open standard for driver definition gives you is the open source resources to build a pool of drivers. What happened before in the closed model was that companies boasted that they had a big pool of drivers – this was understandable IP and was marketing to people like me. Certainly when we had a new integrator we said – your driver pool is shallow are you gonna screw me on driver development charges?

    The big problem in open source is that open source works well when the users are computer scientists themselves; in lab automation the users are often biologists who often don’t have the time and/or skills to fiddle with open source the way computer people do. At Ziath we use a lot of open source stuff but that is because we know how to manage it and install it ourselves – without that knowledge the value of open source drops quickly!

    • Kevin Keras says:

      Thanks Neil, I forgot about LEICES. I do believe CRS was looking to adopt it as a standard before I got there (circa,1999). When i went to Zymark we used to charge about $3K for each driver, if they were common and about $7.5K or more for less common, or newly developed. It can be a hard sell, but for integrators who sell a lot of third party hardware it is a common way to increase your overall margins.

  2. As one of the independent integrators mentioned above, paa would be happy to add the SiLA device drivers to the Overlord3 device driver library. There are good business reasons to do it (customers ask for SiLA compatibility) and good business reasons not to do it (customers don’t ask for SiLA compatibility). It isn’t even a big expense for us to write the SiLA drivers (we have written a SiLA interface already), how the key issue here is customers aren’t asking for it. In my experience, if you produce products that the customers don’t ask for, you won’t sell many. So currently the SiLA membership would be an overhead with no commercial benefits to paa.

  3. Hi Kevin,
    Taking the position for deep integration is the business model of software engineers to deepen the dependency between supplier and customer. That’s what we did at infoteam Software too.
    But if you put customer’s requirements first, suddenly that’s changing dramatically. You’ll recognize that they don’t care how “deep” your integration is, if this limits reconfiguration and upgrade to newer instruments and ultimately hinders innovation!
    You recognized, that there has been no successful Open Source scheduling software and you assume that there was no need for something like this. I’m convinced that the missing standards in interfacing a multitude of instruments without implementing hundreds of drivers prohibit this.
    And that’s exactly what SiLA is about to change drastically. Standardizing integration of instruments starts with standard interfaces from connectivity level up to functionality. Programming techniques like .NET, SOAP or many other four letter acronyms are just the ink for the pencil and not the story.
    Businesswise this will by no means reduce the opportunities for software and integrator companies like us. On the contrary, standardization will accelerate innovation and therefore grow the market as a whole to the benefit of all of us.

  4. For Malcom,
    NO there is no fee to implement SiLA compliant devices at all, as the standards are open and available to everybody at:
    However there is a fee for the certification of the product to prove compliance and to use the SiLA logo. And YES we want supporting members and this is NOT for free:-)

    • Neil Benn says:

      So can I clarify – I’ve had customers say; do your instruments support the SiLA interface. There is no SiLA interface for my products so one would have to be written. I’ve been told I need to join and pay and then write the specification, donate it for free (keeping zero rights but transferring them to a private company) and then I can write SiLA compliant drivers. That seems a long long way from open source to me; if I want to contribute to an apache or linux project I start committing and we go from there – my code is under GPL, LGPL or Apache (or something like that). If I’m wrong please let me know as we’d like to contribute but don’t want to hand over a lot of cash to a private company as we cannot really afford it and it doesn’t seem to be a good deal on our side :(.

      • The policy of SiLA changed years ago. Now the specification is ready for download as are the definitions – without any charge:
        If you implemented your driver it’s still yours – there is no obligation to publish your IP. Simple and open isn’t it?

      • Neil Benn says:

        I’m thinking of the standard rather than the driver; to be honest if there was a standard available for my products; I’d write a driver and GPL it; I’m not an integrator and writing a SiLA compliant driver can only increase adoption of my products in the industry.

      • Pefrect Neil, that’s what SiLA is all about. In Ivan words: eliminate the hazzle between the toaster and the power outlet.

  5. Kevin Keras says:

    Thanks Dr. Brendel, I was hoping someone from SiLA would join the conversation. I am unclear what you mean by “deep” integration. Most of the systems I was involved with (Zymark/Caliper) included a variety of plate based devices (readers, washers, liquid handlers, incubators…etc). In most cases, they all included ActiveX controls that enabled us to create ‘drivers’ that allowed our scheduler to communicate with them. This generally involved pretty straightforward commands and software control panels to initialize/start/stop/pause/continue/abort and process errors. Not much else was needed. Also, just to clarify, I did not state that there was not a need for an open source scheduler…I said, without an open source scheduler I did not see the need for an open source interface standard. Integrators (PAA, Hi-Res, Caliper, Thermo…others with scheduling software) have all gotten along fine and created thousands of systems without any open source instrument interface standard. Were an open source scheduler to catch on, I would imagine it could include the SiLA standard or it very well might create an alternative standard to SiLA. In that case, the market would decide which standard has more value.

  6. With SiLA their should be NO integration needed as long as you’re only using standard commands (that’s why it’s a srtandard). Very similar to adding a NAS or printer to your network nowadays. But in lab automation it seems we are still at DOS / P-CPM / etc level.

  7. Ivan Ivanov says:

    Great article! It summarizes previous (unsuccessful unfortunately) attempts to standardize instrument interfaces in lab automation. It somewhat misses the point though – it points out the lack of Open Source scheduling implementations as a possible weak point of the effort. I am not sure SiLA is about open source at all. Open or not open, any source suggests implementation, not a standard. A standard is not about implementation,it is a standard. It should define the interfaces between entities and leave it at that. It is true that integrator companies are on decline, but their very raison d’etre is to integrate – to create shims between incompatible pieces. Of course a standard will eliminate to a large extent the need for most of them, but they are in decline anyway. Imagine an integrator company that will create a shim between the appliance that you design (i.e a toaster) and the power plugs (imagine that each house has different power plugs, designed by its inhabitants) . A very good business model for integrators, until everyone realizes that if they use the same power plug, there is no need to waste huge amounts for integrating. And that will happen in this industry – sooner or later, just a matter of time. Some industries are better than others in that, and the younger the industry, the worse they are, I guess, but they are heading in the same direction – standard interfaces.

    • Ivan brings it to the point: SiLA as a standard will avoid wasting time and money. But I disagree that integrators will decline as we have seen in industrial automation, the software business as a whole increased based on IEC 61131-3. A international standard opens a market for software developers, which has been to fragmented before, to be worthwhile persuing it. So good times ahead for all of us!

  8. Rob Harkness says:

    I have been following this thread for the last couple of days and have found some of the comments quite interesting from both sides. Thought I’d throw in my unbiased opinion!

    I have developed software using the SiLA standard for device control as both an integrator (SiLA consumer) and as a provider of the automation API (SiLA Service). As already pointed out, the documentation is free, you just have to sign up to the website.

    I found it really useful having a standard to work off when developing the API, as it addressed all the questions I would have had if I was doing this from scratch (i.e. should I make this method async/sync, would an integrator need to be able to initialize just one axis of the robot, or would one initialise call do). I also think that setting up the interface via a web service is the right way to as this encourages distributed control. I’d perhaps used JSON instead of SOAP, but with the amount of data moving about, that’s not a major concern and more of a personal preference. This could be something addressed later down the line (SiLA v2.0?)

    As an integrator, I agree it’s pretty easy to create a driver/adaptor to control an instrument. The majority of liquid handlers and plate readers, which are typically controlled through their own native software have at the very least an ActiveX component, but hopefully a .NET assembly which makes integration extremely easy. Although RS232 is still used, ethernet is starting to be used much more. For example, HighRes use this on the MicroServe and their other storage products as do Mitsubishi with their latest robots. This again simplifies the integration process. However, these methods of integration are all different. If you get new developers in to work on your scheduler, there’s quite a learning curve there and different techniques to support.

    Where integration does take time and becomes more difficult is how you handle instrument behaviour. Tracking the states an instrument goes through, the errors reported and how to recover from these. The recovery process on a device may require you to re-initialize and start again from the beginning of the process you are trying to run, whereas on another device, it may resume from where the error occurred. Liquid handlers, in particular, all have their own recovery techniques. It’s very difficult for an integrator to have a standard error recovery within their scheduler package, if each device behaves in a different way. The SiLA standard has made a really good attempt at trying to encapsulate state management and how error recovery should be consistent across devices. This is where the benefit of a standard comes into play in my opinion.

    I’m not quite sure why the term open source is being used when discussing SiLA, since it really has nothing to with open source code. From what I can see, it’s about encouraging vendors to develop their laboratory automation interfaces in a consistent manner. As I have found, this will have benefits for software developers working as an integrator or an API developer. I do not think there is a need right now to go back to existing API interfaces and change to SiLA. But, if you were developing a new software control package or releasing a new instrument into the field, I can’t see a reason why you wouldn’t adopt the SiLA interface. You’d be re-inventing the wheel if you developed your own API.

    As regards to the SiLA business model, the need for certification will only come from the end-users. If they feel a seal of approval has a cost benefit, then it will be requested. It’s not something I’ve been asked to do as of yet. Of course, if no-one requests this, this will become an issue for future development of the standard, which opens up a new topic for discussion!

    • Thanks Rob, your whitness as an applier of the standard makes worth all the effort. May I cite your comment on the SiLA blog ?
      @ Kevin: Yes you’re a visionaire, this “Driver Information Platform” is currently under development and will be hosted at the SiLA website. It is intended for both commercial and non-commercial (potentially open source) offerings. We see availability of SiLA compliant drivers as a mission critical topic and want to make this information available to all. Accelerate Innovation!

  9. Kevin Keras says:

    Thanks Rob, very insightful! The Open-Source tag was perhaps a misnomer on my part, lumping Open-Source schedulers in with SiLA. Your comment about redeveloping existing API’s though, does lead me to believe that a number of such drivers could (likely will) be developed by integrators, end-users or consultants on an ad-hoc basis. That being the case, ‘legacy’ instrument drivers could be developed perhaps using the SiLA framework, but they would not be SiLA certified since it is unlikely (IMO) that someone will pay SiLA for certification of one-offs. That being the case, I imagine an Open-Source library of such drivers could come to being without the involvement of instrument manufacturers or the certification of SiLA. Damn, I’m good…

  10. Pingback: LRIG discusses SiLA and its implications | SiLA Rapid Integration

  11. Erwin Althof says:

    Interesting discussion I’ve read some viewpoints and I would like to share some of my appliers side thoughts.
    I believe that times are over where it was appreciated that scientist where trying to build up automation for a process in the lab on their own. it’s for sure much fun to play with robots but this is for sure not the expectation from a company perspective towards the scientist. So inhouse integration efforts with for instance open source might remain a privilege for a few remaining automation enthousiasts.
    At many occassions we get the same comment that “automation in the laboratory does not deliver”
    I’m sure at one or the other conference you already heard this. There are several aspects that are the foundation for such a statement.
    The easiest one to understand is that it doesn’t work at all but a more difficult one to understand is it doesn’t meet the expectations. What are the expectations ? There you very soon get the comparison with the automation in the car industry. it should be as reliable etc.
    Life is different in pharma. engineers do not belong to the core workforce and numbers in automation are for sure not as signicant.
    I agree that most of the integrations we have are “pretty straight forward using commands and software control panels to initialize/start/stop/pause/continue/abort and process errors” but I do not agree that not much else was or is needed, I think not much more could be offered and many do not know the alternative.
    I lived for many years of my live without mobile phone because it just didn’t exist and I didn’t know the advantages, but now I wouldn’t do without, it makes live much easier.
    We now recognized a whole bunch of other advantages using the SiLA which go far beyond saving some money for creating a device driver. We now recognized opportunities to move innovative solutions forward.
    In car manufacturing and other industries I have the impression they seem to know better if they talk about standards. We are talking about enabling technologies, bottom up solutions for the bigger picture. We can only move forward with innovation if we put the starting threshold for a new development a little bit higher with the know how we gathered in the past. This is what standards are all about. Standards are made by a group of specialist in specific area of expertise agreeing on best practice. Although already a lot of important suppliers participate actively in creating standards through the SiLa consortium it is also the biggest challenge for SiLA to get the specialists around the table. I could come up with a few pages more of ideas and implemented advantages so far but let me finish with one significant advantage.
    One example of I think of a principle of SiLA. Give the instrument supplier the tools to write the device driver for the machine they made. The device supplier understands his machine. My experience is that for an integrator it is a challenge to fully understand the specifics of a machine.
    Are the tools already available ? no perhaps not or not perfect. Not because it’s not possible but just because SiLA just started and needs further expert input and participation. Not many people asked for a mobile phone at the time it didn’t exist but industry didn’t wait for the requests before they started working on mobile phones, Industry started because the technology was available. Most innovative good developments do not really start with the best bussiness case. My hope is that standardization does not wait for request from “non technical people” not realizing the advantages of standards but on suppliers experts selling the advantages to customers like we are.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s