Introducing SiLA 2
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
The SiLA specification is a multi-part specification
Key Design Principles
Clients typically respond to errors in a limited number of ways. The status namespace should be constrained to make these error handling decisions clearer.
The base communication protocol must be capable of surviving traversal over common internet infrastructure.
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.
Common cross-cutting concerns like authentication should not rely on the exchange of data that is part of the declared interface but transported separately.
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.
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.
We have active working groups in the following areas of interest:
DCommand Dictionary Specification
Process Management System (PMS)
SiLA 2 Standard
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.
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.
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.
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.