Introducing SiLA 2
SiLA 2 – Cloud Ready
SiLA 2 Version 1.1 introduces a new Connection Method, the Server-Initiated Connection Method. This new enables a few exciting new use cases for SiLA:
- Connect lab instruments to the cloud
- Solve issues of accessing lab instruments, that reside in isolated lab networks, from a corporate network
- Simplify security certificate management for encrypted and secure connections
To learn more, visit: Whatās New in SiLA 2 Version 1.1
History of SiLA 2
Since the release of the SiLA 1.x standards in 2009, SiLAās working groups have been applying nearly a decade of experience towards the development of a state-of-the-art technology base centered around easy-to-implement, outstanding and elegant concepts that can easily grow with help of the community.
The Technical Concept
The SiLA 2 Standard is based on HTTP/2, an Internet Engineering Taskforce (IETF) standard and concentrates on functionality rather than device type. It is representing device behaviour instead of underlying states and communication. Click here for some more details.
There were many thoughts on possible base protocols for SiLA 2.0. The conclusion is that SiLA must map to a base technology & communication standard that will survive for a considerable amount of time. It needs to be accessible, robust and open.
Among many possibilities, a combination of these technologies is our favorite:
-HTTP/2 – as a base communication layer,
-A āRESTā-like communication paradigm,
-ProtocolBuffer data structures and
-An interface description language
In summary, SiLA 2 runs over HTTP/2 and uses Protocol Buffers to serialize payload data. As SiLA does not want to “reinvent the wheel”, it relies on the wire format specified by gRPC.
Find out how SiLA works in detail on our GitLab Code Repository!
Improvements of
SiLA 2
Specification
The SiLA specification is a multi-part specification
Download the latest release here
SiLA Part (A) v1.1 Ā Ā Ā Ā Ā Ā SiLA Part (B) v1.1
Also refer to our GitLab pages
Key Design
Principles
Standardized Status
Clients typically respond to errors in a limited number of ways. The status namespace should be constrained to make these error handling decisions clearer.
Interoperability
The base communication protocol must be capable of surviving traversal over common internet infrastructure.
Message Driven
Provide a taxonomy suitable for message exchange between systems while avoiding the pitfalls of distributed objects and the fallacies of ignoring the network.
Free & Open
SiLA standards are free and open; SiLA enables and supports open-source efforts with licensing that facilitates and does not impede adoption.
Meta Data
Common cross-cutting concerns like authentication should not rely on the exchange of data that is part of the declared interface but transported separately.
Pluggable
A communication protocol is only part of a working infrastructure, extensions should be possible without losing the original spirit and the reason for SiLA as a standard.
Simplicity
The technology stack is available on every popular development platform and easily accessible. It should be viable on CPU and memory limited devices, such as a Raspberry Pi.
Through our partnership with ASTM-AnIML, SiLA has proven that integration can be realized beyond data/file transmission to an automation control software. Instead, it extends all the way to the LIMS- and the ELN-level. AnIML is embedded into SiLA which serves as the vehicle to transport method and result data throughout an integrated lab.
SiLA 2 Core
The Core of the SiLA 2 specification includes an overview of overall design goals, including Feature specification, design rules, development and balloting process, as well as error handling and data types, security and authentication, and SiLA Discovery.
SiLA 2 Features
Features are the capabilities of a SiLA Server that are offered to any lab instrument, device, or system interested in interaction. Each Feature exposes Commands that can be called (with Parameters) and Properties that can be read or registered to.
Working Groups
We have active working groups in the following areas of interest:
DCommand Dictionary Specification
Bernd Papenfuss
Group leader
papenfuss@equicon.de
Process Management System (PMS)
Thomas Frech
Group leader
thomas.frech@sila-standard.org
Pipettor
Holger Saal
Group leader
holger.saal@ipa.fraunhofer.de
Labware Specification
Daniel Juchli
Group leader
daniel.juchli@wega-it.com
SiLA Robotics Working Group
ĆdĆ”m Wolf
Takeda
adam.wolf@sila-standard.org
SiLA 2 Standard
Daniel Juchli
Wega Informatik
daniel.juchli@sila-standard.org
SiLA Robotics
ĆdĆ”m Wolf
Takeda
adam.wolf@sila-standard.org
SiLA Cyber Security
Mark Auty
Unilever
mark.auty@sila-standard.org
SiLA Automation Suite
Tim Meyer
UniversitƤtsmedizin Gƶttingen
tim.meyer@sila-standard.org
High Level Overview
The SiLA 2 specification is separated into three parts; Core, Mapping and Features. The core specification is meant to be an overview of the elements used in SiLA 2 without going into the implementation aspects. These are thoroughly documented in the second part the Mapping. Lastly the Part C is meant to collect all Features to be used in SiLA 2.
The core and mapping specifications are written and maintained by the SiLA 2 Working Group and kept as stable as possible. The flexible evolution and (vendor) specific extensions only happen on a Feature level.
The basic entities in SiLA 2 are the SiLA Client and the SiLA Server.Ā A SiLA Server is comparable to a web server, that is offering resources to a web browser (the SiLA Client). The behaviour of a web server and web browser is comparable to a SiLA Server and SiLA Client to a high extent.
Each SiLA Server has a certain number of Features implemented. A Feature describes a part of the Servers overall behavior. Whenever a Client uses a Server, it happens through a Feature.
SiLA 2 is based on loose and flexible connection principles. Allowing dynamic adding and removing of Features, it supports your changes.
Features are a key component of the SiLA 2 Standard as they define the interaction between the SiLA Client and the SiLA Server. Every single Feature describes a certain aspect of the overall behavior of the Server.
Each Feature imposes a certain number of Commands. Each Command can be called by a Client. A Command is an action that can be executed by a SiLA Server. It contains Parameters and/or Properties that can be read or registered to. When a Command is executed, it will return complete and traceable data describing what happened.
Interface
SiLA connects your different devices in a way every modern lab should. One SiLA Client can access an unlimited number of SiLA Servers once it has connected to them. Through SiLA’s service oriented structure, fully automated proccesses are facilitated enormously.
A basic, but fully automated communication example between the different devices would look like this: The LIMS orders a Plate Handler to put plates into a Plate Reader. The Plate Handler answers with a return value (“finished successfully”). This triggers the LIMS next call to the Plate Reader: Read the plates. The Plate Reader will answer with a description of the data read as a return value. As a next step, the LIMS will call the Plate Handler again and order it to put the plates back into a storage facility.
Connect
How to get started
Get started:
- Check out the SiLA 2 wiki (with links to standard docs, reference implementations, etc.) on https://gitlab.com/SiLA2/sila_base/wikis/home
- Connect with our Slack community, people who are very responsive and helpful.
- Check out our SiLA youtube-channels. We offer free training videos: https://www.youtube.com/watch?v=LkD8YFvV0tY&list=PLO4ahGnuOrhfzq1-lmhHQTG4y81FmaGwG
For further questions, please contact info@sila-standard.org.
Additional interesting infos:
- SiLA 2 Hands-on https://medium.com/@matthieu.croissant/sila-2-hands-on-bringing-automation-to-the-laboratory-dacc12df7152
- Workflow orchestration based on BPMN with Camunda as a component in http://unitelabs.ch/technology/control-software
- Roche’s Camunda-based AutoLab software https://www.youtube.com/watch?v=B-LU1Tq7qYw
- Autonomous lab Robot running on SiLA https://www.linkedin.com/posts/bryn-roberts-685171_labautomation-robotic-autonomous-activity-6582897402808676353-b4TK
Ā
Integrate
With SiLA Discovery,Ā setting up a lab is like a breeze – It just happens on its own.
If the current lab setup is not satisfying or does not fit the needs, change will not be a question. It will be an answer. No project will be postponed for weeks – Instead, using multi-client support, ad-hoc automation different setups can be tested within minutes.
If wanted, a laboratory can be extended and used from everywhere. Simply use a smartphone or computer anywhere in the world and access your laboratory through an established communication channel.
Merge
Sharing data between different laboratories is trivial with SiLA. The vendor independant standard enables worldwide data exchange without any data formatting trouble.
Simply integrate existing systems in another LIMS using simple zero-configuration proccesses provided by SiLA. This way, in bigger lab compounds, a flexible ecosystem can be used to share not only data but also whole lab systems without restricting or changing the original laboratory.
As long as the SiLA Servers are not already busy, they can be used by several LIMS simultaneously, meaning the need for new products is often satisfied by sharing what already exists.
