SiLA 2 Studio ist verfügbar: von OpenAPI zum SiLA-2-Treiber in zwei Minuten

SiLA 2 Studio ist verfügbar: von OpenAPI zum SiLA-2-Treiber in zwei Minuten

SiLA 2 Studio ist unter sila2.qpillars.com verfügbar. Laden Sie eine OpenAPI-3.0- oder -3.1-Spezifikation hoch und erhalten Sie ein ausführbares Python-Grundgerüst für einen SiLA-2-Treiber: Server, gRPC-Servicer, Feature-Definition-Dateien, Dockerfile und Tests. Das Webwerkzeug ist kostenlos. Die zugrunde liegende Transformationsbibliothek openapi-to-sila2 ist Open Source. Keine Registrierung, keine Installation, keine Kreditkarte.

Warum wir es entwickelt haben

Jeder Gerätehersteller, mit dem wir zusammengearbeitet haben, stösst an dieselbe Grenze. Der SiLA-2-Standard und das Python-SDK existieren bereits. Einen SiLA-2-Treiber von Grund auf zu entwickeln, bleibt jedoch ein mehrwöchiges Projekt für einen erfahrenen Softwareentwickler. Sie lernen das XSD-Schema für Feature Definitions, schreiben die FDL-Dateien von Hand, führen den SiLA-Codegenerator aus, binden den gRPC-Servicer an und beheben Unterschiede zwischen dem Datenmodell Ihres Geräts und dem von SiLA. Erst danach beginnt die eigentliche Integrationsarbeit.

Wir haben gesehen, wie Teams einen Monat auf Grundgerüste verwendeten, die sich hätten generieren lassen. Also haben wir diese Generierung umgesetzt.

Was Sie erhalten

Sie laden eine OpenAPI-Spezifikation hoch. Studio liest sie ein, ordnet sie SiLA-2-Konzepten zu und zeigt einen Prüfschritt, in dem Sie Namen anpassen, Operationen ausschliessen und Properties als beobachtbar markieren können. Sie starten die Generierung. Wenige Sekunden später laden Sie eine ZIP-Datei mit dieser Struktur herunter:

<project_slug>/
  features/<Feature>.xml
  <python_package>/
    __init__.py
    __main__.py
    server.py
    feature_implementations/
      <feature>_impl.py   <- you fill these in
    generated/
      client.py
      <feature>/...       <- do not hand-edit; auto-regenerated
  tests/test_driver.py
  Dockerfile
  docker-compose.yml
  pyproject.toml
  README.md

Die Dateien unter feature_implementations/ enthalten bewusst Platzhalter, die NotImplementedError auslösen. Diesen Teil können nur Sie implementieren: den Aufruf Ihres tatsächlichen Geräte-SDKs, HTTP-Clients, seriellen Anschlusses oder einer anderen Hardwareschnittstelle. Alles Weitere ist bereits verbunden: Geräteerkennung, gRPC-Anbindung, Typumwandlung und Server-Einstiegspunkt.

Starten Sie das Grundgerüst lokal:

uv sync
uv run python -m <package> --insecure -p 50051

Ein SiLA-2-Server wartet jetzt auf Port 50051. Jeder SiLA-fähige Client kann ihn erkennen und aufrufen.

Die Zuordnungsregeln

OpenAPI und SiLA 2 lassen sich nicht eins zu eins aufeinander abbilden. Die Transformationsschicht von Studio trifft dafür konkrete Entscheidungen, die wir anhand realer Geräte-APIs geprüft haben:

• Ein OpenAPI-Tag → ein SiLA-2-Feature. Tags bilden die natürliche Gruppierung in OpenAPI, Features die natürliche Gruppierung in SiLA 2.
• GET ohne Parameter → Property. Dieses Muster passt beispielsweise zu einem Sensorwert oder Statuswert.
• POST / PUT / DELETE → Command. Alles, was einen Zustand verändert, wird zu einem aufrufbaren Befehl.
• GET mit Parametern → Command. Parametrisierte Lesezugriffe sind Operationen, keine Properties.
• 2xx-Antwortschemata → Antworttypen für Commands. Die Typisierung erfolgt über XSD.
• 4xx-/5xx-Antwortschemata → Defined Execution Errors. Diese werden als typisierte SiLA-Fehler bereitgestellt.

Die vollständigen Regeln sind in openapi-to-sila2 dokumentiert, der Open-Source-Bibliothek für die eigentliche Transformation. Studio ist die darauf aufbauende, benutzerfreundliche Weboberfläche. Die Bibliothek nutzen Sie, wenn Sie vollständige Kontrolle benötigen oder die Generierung in Ihre CI-Pipeline einbinden möchten.

Was das Webwerkzeug gegenüber der Bibliothek bietet

Sie können openapi-to-sila2 bereits mit pip installieren und lokal ausführen. Warum gibt es zusätzlich das gehostete Studio?

• Keine Python-Werkzeugkette erforderlich. Datei hochladen, Schaltfläche anklicken. Das ist hilfreich für Evaluatoren, Wissenschaftler und alle, die keine lokale Python-Umgebung eingerichtet haben.
• Visuelle Prüfung der vorgeschlagenen Zuordnung. Die Bibliothek liefert FDL-Dateien. Studio zeigt vor der Generierung die Feature-Struktur sowie die Anzahl von Commands und Properties.
• Anpassungsebene. Umbenennen, ausschliessen und als beobachtbar markieren: alles im Browser und vor der Generierung. Keine Änderungen an Code oder Spezifikation, sondern gezielte Entscheidungen.
• Reproduzierbare Pakete. Dieselbe Spezifikation → derselbe SHA-256-Wert. So können Sie prüfen, ob ein neu generierter Treiber bytegenau der ausgelieferten Version entspricht.
• Iterationsschritte in zwei Minuten. Hochladen, anpassen, erneut generieren. Mit der Bibliothek dauert es durch die Einrichtung lokaler Werkzeuge und die Bedienung der Kommandozeile länger.

Für die einmalige Erzeugung eines Grundgerüsts verwenden Sie Studio. Für die Integration in eine Pipeline verwenden Sie die Bibliothek. Beide nutzen dieselbe Transformationslogik.

Was das Grundgerüst nicht ist

Studio übernimmt 80 % des Weges zu einem funktionsfähigen Treiber. Die verbleibenden 20 % bestehen aus der Integration, die nur Ihr Team schreiben kann, und der Überführung in den Produktionsbetrieb, damit das Ergebnis einem GxP-Audit standhalten kann.

Das Grundgerüst enthält nicht:

• Validierungsnachweise und IQ/OQ-Dokumentation
• Audit Trails oder Hilfsfunktionen für die Einhaltung von 21 CFR Part 11
• Rollenbasierte Zugriffskontrolle über das SiLA-Feature LockController hinaus
• Beobachtbarkeit über grundlegende Protokollierung hinaus
• Hersteller-SDK-Integrationen, da diese gerätespezifisch sind

Diese Lücke schliessen wir in Projekten mit Kunden. Studio ist der Ausgangspunkt; ein produktionsreifer SiLA-2-Treiber ist das Ziel. Wenn Sie an diesem Punkt stehen, vereinbaren Sie ein technisches Gespräch.

Datenschutz und Datenverarbeitung

Spezifikationen werden als Objekte in Google Cloud Storage mit einer Lebensdauer von 24 Stunden gespeichert und der jeweiligen Sitzung zugeordnet, in der sie verarbeitet wurden. Es wird nichts in eine Datenbank geschrieben und der Inhalt der Spezifikation nicht an Dritte weitergegeben. Spezifikationsinhalte erscheinen nicht in Anwendungsprotokollen. E-Mail-Eingaben im Formular zur Kontaktdatenerfassung werden über Resend an sila2@qpillars.com gesendet. Der vollständige Datenfluss ist auf der Datenschutzseite von Studio dokumentiert.

Was wir ausgeliefert haben

SiLA 2 Studio ist eine Anwendung mit Next.js 16, FastAPI und Python auf Google Cloud Run. Sie steht hinter einem Global External HTTPS Load Balancer mit einem verwalteten Zertifikat. Die Objektspeicherung erfolgt über GCS, Downloads verwenden signierte URLs, und Resend übernimmt transaktionale E-Mails. Die Studio-Oberfläche leitet den gesamten Backend-Datenverkehr weiter. Nutzer sehen deshalb nur sila2.qpillars.com; die Backend-URL wird dem Browser nicht offengelegt. Die CD-Pipeline läuft über GitHub Actions: Jeder Push auf main wird in Produktion bereitgestellt.

Wenn Sie die Architektur im Detail kennenlernen möchten, sehen Sie sich das SiLA-2-Studio-Repository an. Es ist öffentlich.

Ausprobieren

sila2.qpillars.com: Öffnen Sie die Seite, fügen Sie eine OpenAPI-URL ein oder laden Sie eine Datei hoch, gehen Sie die Prüfschritte durch und laden Sie die ZIP-Datei herunter. Falls Ihre erste Generierung länger als zwei Minuten dauert, schreiben Sie uns an sila2@qpillars.com. Wir kümmern uns darum.

Die wichtigsten Erkenntnisse

• Was es ist: Ein Webwerkzeug, das aus einer OpenAPI-Spezifikation ein ausführbares Python-Grundgerüst für einen SiLA-2-Treiber erzeugt.
• Wo es verfügbar ist: sila2.qpillars.com, kostenlos und ohne Registrierung.
• Was es erzeugt: Ein vollständiges Python-Paket mit server.py, __main__.py, Platzhaltern in feature_implementations/, Basisklassen in generated/, Dockerfile, tests/ und pyproject.toml.
• Was Sie noch schreiben: Den Inhalt jeder Methode mit einem NotImplementedError-Platzhalter, also den Aufruf Ihres Geräte-SDKs.
• Open Source: Die Transformationsbibliothek openapi-to-sila2 ist auf GitHub verfügbar.
• Datenschutz: Objektlebensdauer von 24 Stunden in GCS. Keine Datenbank. Spezifikationsinhalte werden nicht protokolliert.

Häufig gestellte Fragen

Was ist SiLA 2, und warum ist es wichtig?

SiLA 2, ausgeschrieben Standardization in Lab Automation, ist der offene Standard für die Kommunikation zwischen Geräten und Software in Life-Science-Laboren. Er definiert einen gRPC-Vertrag zwischen Geräten und der Software, die sie orchestriert: LIMS, Scheduler und KI-Agenten. Ein SiLA-2-Treiber macht Ihr Gerät für jeden SiLA-fähigen Client ansprechbar, ohne dass dieser einen herstellerspezifischen Adapter benötigt.

Funktioniert der generierte Treiber sofort?

Das Grundgerüst ist verbunden: Server, Geräteerkennung, gRPC-Servicer, Typen und Clients. Die Implementierungen der einzelnen Befehle enthalten NotImplementedError-Platzhalter. Das ist beabsichtigt, denn nur Sie wissen, wie Ihr Gerät angesprochen werden muss. Studio übernimmt 80 % des Weges; die verbleibenden 20 % sind die Integration, die nur Ihr Team schreiben kann.

Wie unterscheidet sich Studio vom manuellen Schreiben von FDL-Dateien?

Eine FDL-Datei von Hand zu schreiben, erfordert pro Gerätefamilie zwei bis vier Wochen Arbeit eines erfahrenen Entwicklers: XSD-Schema, Typsystem und Regeln für die gRPC-Zuordnung müssen verstanden und umgesetzt werden. Studio verkürzt dies auf Minuten, indem es die Zuordnung aus Ihrer vorhandenen OpenAPI-Spezifikation ableitet.

Kann ich das für eine regulierte Umgebung verwenden?

Studio erzeugt das Grundgerüst. Für einen produktionsreifen SiLA-2-Treiber in GxP-/FDA-Workflows sind Validierungsnachweise, Audit Trails, rollenbasierte Zugriffe und Beobachtbarkeit erforderlich, die das Grundgerüst nicht enthält. Diese Umsetzung übernehmen wir in Projekten mit Kunden. Studio ist der Ausgangspunkt und nicht das fertige Ergebnis.

Was passiert nach dem Hochladen mit meiner OpenAPI-Spezifikation?

Sie wird als Objekt in Google Cloud Storage mit einer Lebensdauer von 24 Stunden gespeichert und der jeweiligen Sitzung zugeordnet. Es wird nichts in eine Datenbank geschrieben und der Spezifikationsinhalt nicht an Dritte weitergegeben. Spezifikationsinhalte erscheinen nicht in Anwendungsprotokollen.

Weiterführende Artikel

• REST-APIs und die SiLA-2-Brücke: openapi-to-sila2 vorgestellt: vertiefender Einblick in die Transformationsbibliothek.
• KI-Agenten über MCP mit Laborgeräten verbinden: die andere Seite der Integration.
• MCP-Server auf Hersteller-SDKs: Erfahrungen mit LiquidBridge: unsere Erkenntnisse aus der Anbindung von Hersteller-SDKs.