SiLA 2 Studio
OpenAPI to SiLA 2 driver in under two minutes
Drop a Swagger / OpenAPI spec. Get a runnable Python SiLA 2 driver scaffold - server, gRPC, feature definitions, Dockerfile, tests. Free hosted tool by QPillars. Open-source generator under the hood.
The Problem
Writing a SiLA 2 driver from scratch is a multi-week senior-engineer project. You learn the XSD schema, hand-write the Feature Definition, run the SiLA 2 code generator, wire the gRPC servicer, fix the type mismatches, and only then start integrating the instrument. Most teams never get past the FDL.
2-4 wks
typical senior-engineer effort to scaffold a SiLA 2 driver by hand
~2 min
end-to-end with Studio - upload, review, download
CHF 0
hosted version is free; the generator is open source
What Studio gives you
The shortest path from instrument API to addressable SiLA 2 driver.
OpenAPI in, SiLA 2 out
Drop a Swagger / OpenAPI 3.0 or 3.1 spec. Studio parses it, maps tags to SiLA 2 Features, operations to Commands and Properties, and emits XSD-valid Feature Definition (FDL) files - all in the browser flow, no install.
Runnable package, not just files
The downloaded bundle is a complete Python package: server.py, __main__.py, per-feature implementation stubs with NotImplementedError markers, generated SiLA 2 base classes, Dockerfile, docker-compose.yml, tests, and a pyproject.toml. Run uv sync and the driver boots.
Override layer, no code edits
Rename features, exclude operations, mark properties as observable - all in the review screen, before generation. The generated bundle reflects the choices; the original spec stays untouched. Iterate without touching code.
Open generator under the hood
The transformation core is openapi-to-sila2 - the open-source library QPillars maintains. The Studio is the polished, hosted entry point; teams who need full control can use the library directly in their own pipelines or CI.
How it works
Four steps, two minutes, one downloadable Python package.
Upload your OpenAPI spec
Drop a YAML or JSON file (OpenAPI 3.0 / 3.1). Studio parses and validates it in the browser; nothing about the spec is stored on a database. Bundles auto-expire after 24 hours.
Review the proposed SiLA 2 mapping
Studio shows the feature breakdown - one feature per OpenAPI tag, commands and properties listed by operation. Tweak names, exclude what you do not need, mark properties as observable.
Generate and download the bundle
Studio runs the FDL generator and sila2-codegen, packages a runnable Python project, and returns a signed download link. Zip size: typically a few KB.
Fill in the NotImplementedError stubs
Each command lands as a NotImplementedError in feature_implementations/. Replace each body with the call to your instrument SDK or HTTP client. The SiLA 2 plumbing, gRPC servicer, and discovery are already wired.
Generate your first SiLA 2 driver now
No sign-up, no install, no credit card. Drop an OpenAPI spec, download the bundle, read the NotImplementedError stubs. Two minutes from URL to runnable scaffold.
Before we start
A few practical questions.
What is SiLA 2 and why does it matter?
SiLA 2 (Standardization in Lab Automation) is the open standard for laboratory instrument communication. It defines a gRPC-based contract between instruments and the orchestration software that drives them. A SiLA 2 driver makes your instrument addressable from any SiLA-aware LIMS, scheduler, or AI agent without per-vendor adapters.
Does the generated driver work out of the box?
The scaffold is fully wired - server, discovery, gRPC servicer, types, clients - but the per-command method bodies are NotImplementedError stubs. That is intentional: only you know how to talk to your instrument (HTTP, vendor SDK, serial, gRPC). The Studio gets you 80% of the way there in two minutes; the remaining 20% is the integration that only your team can write.
How does Studio differ from writing FDL files by hand?
Hand-writing an FDL takes a senior engineer two to four weeks per instrument family - learning the XSD schema, the type system, the gRPC mapping rules. Studio collapses that to minutes by deriving the mapping from your existing OpenAPI spec. If you do not have an OpenAPI spec, our team can produce one from your instrument SDK as a paid engagement.
Is the generator open source?
Yes. The core transformation library, openapi-to-sila2, is open source on GitHub. The Studio is the hosted, polished entry point - useful for one-off generation, fast iteration, and teams without a Python toolchain set up. Power users can run the library directly in CI to regenerate drivers from spec changes.
What happens to my OpenAPI spec after I upload it?
Specs are stored as objects in Google Cloud Storage with a 24-hour lifecycle, scoped to the session that generated them. Nothing is written to a database, nothing is forwarded to third parties, and the spec contents never appear in application logs. See the Studio's Privacy page for the full data flow.
Can we run this for a regulated environment?
The Studio generates the scaffold; productionising a SiLA 2 driver for GxP/FDA workflows needs validation evidence, audit trails, role-based access, and observability that the scaffold does not bundle. That is the engagement we build with customers - the Studio is the starting point, not the finish line. Book a call to discuss.