SiLA 2 Studio
Von OpenAPI zum SiLA 2-Treiber in weniger als zwei Minuten
Laden Sie eine Swagger- / OpenAPI-Spezifikation hoch. Erhalten Sie ein lauffähiges Python-Gerüst für einen SiLA 2-Treiber – Server, gRPC, Feature-Definitionen, Dockerfile, Tests. Kostenloses gehostetes Tool von QPillars. Open-Source-Generator unter der Haube.
Das Problem
Einen SiLA 2-Treiber von Grund auf zu schreiben, ist ein mehrwöchiges Projekt für Senior Engineers. Sie lernen das XSD-Schema, schreiben die Feature Definition von Hand, führen den SiLA 2-Codegenerator aus, verdrahten den gRPC-Servicer, beheben Typkonflikte – und erst dann beginnt die Integration des Geräts. Die meisten Teams kommen nie über die FDL hinaus.
2–4 Wo.
typischer Aufwand eines Senior Engineers, um ein SiLA 2-Treibergerüst von Hand zu erstellen
~2 Min.
durchgängig mit Studio – hochladen, prüfen, herunterladen
CHF 0
die gehostete Version ist kostenlos; der Generator ist Open Source
Was Studio Ihnen bietet
Der kürzeste Weg von der Geräte-API zum ansprechbaren SiLA 2-Treiber.
OpenAPI rein, SiLA 2 raus
Laden Sie eine Swagger- / OpenAPI-3.0- oder -3.1-Spezifikation hoch. Studio analysiert sie, ordnet Tags SiLA 2-Features sowie Operationen Commands und Properties zu und erzeugt XSD-valide Feature-Definition-Dateien (FDL) – alles im Browser, ohne Installation.
Ein lauffähiges Paket, nicht nur Dateien
Das heruntergeladene Bundle ist ein vollständiges Python-Paket: server.py, __main__.py, Implementierungs-Stubs pro Feature mit NotImplementedError-Markierungen, generierte SiLA 2-Basisklassen, Dockerfile, docker-compose.yml, Tests und eine pyproject.toml. Führen Sie uv sync aus, und der Treiber startet.
Override-Ebene, keine Codeänderungen
Features umbenennen, Operationen ausschliessen, Properties als observable markieren – alles in der Prüfansicht, noch vor der Generierung. Das generierte Bundle spiegelt Ihre Entscheidungen wider; die ursprüngliche Spezifikation bleibt unverändert. Iterieren Sie, ohne Code anzufassen.
Offener Generator unter der Haube
Der Transformationskern ist openapi-to-sila2 – die Open-Source-Bibliothek, die QPillars pflegt. Studio ist der ausgereifte, gehostete Einstiegspunkt; Teams, die volle Kontrolle benötigen, können die Bibliothek direkt in ihren eigenen Pipelines oder in CI einsetzen.
So funktioniert es
Vier Schritte, zwei Minuten, ein herunterladbares Python-Paket.
Laden Sie Ihre OpenAPI-Spezifikation hoch
Laden Sie eine YAML- oder JSON-Datei hoch (OpenAPI 3.0 / 3.1). Studio analysiert und validiert sie im Browser; von der Spezifikation wird nichts in einer Datenbank gespeichert. Bundles verfallen automatisch nach 24 Stunden.
Prüfen Sie die vorgeschlagene SiLA 2-Zuordnung
Studio zeigt die Aufteilung in Features – ein Feature pro OpenAPI-Tag, Commands und Properties nach Operation aufgelistet. Passen Sie Namen an, schliessen Sie aus, was Sie nicht benötigen, und markieren Sie Properties als observable.
Generieren und laden Sie das Bundle herunter
Studio führt den FDL-Generator und sila2-codegen aus, verpackt ein lauffähiges Python-Projekt und liefert einen signierten Download-Link. Zip-Grösse: typischerweise wenige KB.
Füllen Sie die NotImplementedError-Stubs aus
Jeder Command wird als NotImplementedError in feature_implementations/ angelegt. Ersetzen Sie jeden Methodenrumpf durch den Aufruf Ihres Geräte-SDK oder HTTP-Clients. Die SiLA 2-Infrastruktur, der gRPC-Servicer und die Discovery sind bereits verdrahtet.
Generieren Sie jetzt Ihren ersten SiLA 2-Treiber
Keine Registrierung, keine Installation, keine Kreditkarte. Laden Sie eine OpenAPI-Spezifikation hoch, laden Sie das Bundle herunter und sehen Sie sich die NotImplementedError-Stubs an. Zwei Minuten von der URL zum lauffähigen Gerüst.
Bevor wir beginnen
Einige praktische Fragen.
Was ist SiLA 2 und warum ist es wichtig?
SiLA 2 (Standardization in Lab Automation) ist der offene Standard für die Kommunikation von Laborgeräten. Er definiert einen gRPC-basierten Vertrag zwischen Geräten und der Orchestrierungssoftware, die sie steuert. Ein SiLA 2-Treiber macht Ihr Gerät von jedem SiLA-fähigen LIMS, Scheduler oder KI-Agenten aus ansprechbar – ohne herstellerspezifische Adapter.
Funktioniert der generierte Treiber sofort?
Das Gerüst ist vollständig verdrahtet – Server, Discovery, gRPC-Servicer, Typen, Clients –, doch die Methodenrümpfe der einzelnen Commands sind NotImplementedError-Stubs. Das ist beabsichtigt: Nur Sie wissen, wie mit Ihrem Gerät zu kommunizieren ist (HTTP, Hersteller-SDK, seriell, gRPC). Studio bringt Sie in zwei Minuten 80 % des Weges voran; die restlichen 20 % sind die Integration, die nur Ihr Team schreiben kann.
Worin unterscheidet sich Studio vom manuellen Schreiben von FDL-Dateien?
Das manuelle Schreiben einer FDL kostet einen Senior Engineer zwei bis vier Wochen pro Gerätefamilie – für das Erlernen des XSD-Schemas, des Typsystems und der gRPC-Mapping-Regeln. Studio verkürzt dies auf Minuten, indem die Zuordnung aus Ihrer bestehenden OpenAPI-Spezifikation abgeleitet wird. Falls Sie keine OpenAPI-Spezifikation haben, kann unser Team im Rahmen eines kostenpflichtigen Auftrags eine aus Ihrem Geräte-SDK erstellen.
Ist der Generator Open Source?
Ja. Die zentrale Transformationsbibliothek openapi-to-sila2 ist als Open Source auf GitHub verfügbar. Studio ist der gehostete, ausgereifte Einstiegspunkt – nützlich für einmalige Generierungen, schnelle Iterationen und Teams ohne eingerichtete Python-Toolchain. Erfahrene Nutzer können die Bibliothek direkt in CI ausführen, um Treiber bei Spezifikationsänderungen neu zu generieren.
Was geschieht mit meiner OpenAPI-Spezifikation nach dem Hochladen?
Spezifikationen werden als Objekte in Google Cloud Storage mit einem 24-Stunden-Lebenszyklus gespeichert und sind der Sitzung zugeordnet, in der sie generiert wurden. Nichts wird in eine Datenbank geschrieben, nichts an Dritte weitergeleitet, und die Inhalte der Spezifikation erscheinen nie in Anwendungsprotokollen. Den vollständigen Datenfluss finden Sie auf der Datenschutzseite von Studio.
Können wir dies in einer regulierten Umgebung einsetzen?
Studio generiert das Gerüst; einen SiLA 2-Treiber für GxP-/FDA-Workflows produktionsreif zu machen, erfordert Validierungsnachweise, Audit-Trails, rollenbasierten Zugriff und Observability, die das Gerüst nicht mitliefert. Genau das erarbeiten wir gemeinsam mit unseren Kunden – Studio ist der Ausgangspunkt, nicht die Ziellinie. Vereinbaren Sie ein Gespräch, um dies zu besprechen.