Warum REST-APIs und SiLA2 nicht miteinander kommunizieren - und wie Sie sie verbinden

Warum REST-APIs und SiLA2 nicht miteinander kommunizieren - und wie Sie sie verbinden

REST-APIs und SiLA2 können nicht direkt zusammenarbeiten, weil SiLA2 auf gRPC über HTTP/2 mit Protocol Buffers aufbaut, während REST JSON über HTTP/1.1 verwendet - zwei grundlegend verschiedene Übertragungsprotokolle. Der heute in Laboren übliche Behelf besteht darin, für jeden REST-Endpunkt von Hand SiLA2-XML in der Feature Definition Language (FDL) zu verfassen, das den Endpunkt kapselt. Das ist langsam, fehleranfällig und wird selten gepflegt. Das Open-Source-Werkzeug openapi-to-sila2 (im April 2026 von QPillars veröffentlicht) automatisiert diesen Vorgang: Sie übergeben eine OpenAPI-Spezifikation und erhalten validiertes FDL-XML, gRPC-Stubs und Python-Typklassen zurück - mit einem einzigen Befehl.

Die Unvereinbarkeit - zwei Standards, die nicht dieselbe Sprache sprechen

SiLA2 (Standardization in Lab Automation, Version 2) ist der Industriestandard für die Kommunikation mit Laborgeräten. Er wird vom SiLA Consortium verwaltet, einer Non-Profit-Organisation, deren Vorstand Vertreterinnen und Vertreter grosser IVD-Hersteller sowie von Tecan, Novartis, GSK, Takeda, Novo Nordisk, Fraunhofer IPA und Zeiss Digital Innovation umfasst. Wenn Sie Laborgeräte bei einem ernstzunehmenden Pharma- oder Biotech-Unternehmen integrieren, steht SiLA2 auf der Roadmap.

SiLA2 ist jedoch gRPC-nativ. Das Protokoll läuft über HTTP/2, Nutzdaten werden in Protocol Buffers kodiert, und die Fähigkeiten eines Geräts werden in einem XML-Dialekt namens Feature Definition Language (FDL) beschrieben, der gegen ein offizielles XSD-Schema validiert wird.

Gleichzeitig wird fast alles andere im modernen Labor-Stack mit REST/OpenAPI ausgeliefert:

• LIMS- und ELN-Plattformen stellen REST-APIs bereit (Benchling, LabVantage, STARLIMS)
• Cloud-Labor-Dienste (Strateos, Emerald Cloud Lab) werden mit REST ausgeliefert
• Neue Gerätehersteller setzen standardmässig auf REST/OpenAPI, bevor sie SiLA2 überhaupt in Betracht ziehen
• Interne Laborsoftware, die in den letzten fünf Jahren geschrieben wurde, basiert fast durchweg auf FastAPI, Express oder Spring Boot - allesamt REST-first

Das Ergebnis: Ein SiLA2-konformer Orchestrator kann ohne Übersetzungsschicht keinen REST-Endpunkt aufrufen, und ein REST-basiertes LIMS kann ohne gRPC-Client kein SiLA2-Gerät nutzen. Zwei Standards, keine Brücke.

Warum SiLA2 gRPC gewählt hat (und warum diese Wahl wichtig ist)

Die Wahl von gRPC für SiLA2 war nicht willkürlich. Die Steuerung von Laborgeräten stellt Anforderungen, die REST nur schlecht erfüllt:

Lang laufende Befehle mit Fortschritts-Streams. Der Befehl «Protokoll ausführen» eines Liquid Handlers kann 45 Minuten dauern. SiLA2 definiert Observable Commands, die Zwischenzustände - aktueller Schritt, geschätzte Restzeit, Fortschritt von Teilaufgaben - über einen einzigen bidirektionalen gRPC-Stream übertragen. Mit REST erfordert dies Polling, Webhooks oder Server-Sent Events, die allesamt nur zweitrangige Lösungen sind.

Strenge Typisierung über die Leitung hinweg. SiLA2-Features definieren exakte Datentypen (Real, Integer, String, Timestamp, benutzerdefinierte Structures, Lists). gRPC + Protobuf erzwingt diese Typen bei der Serialisierung. REST/JSON verfügt über keine native Typdurchsetzung - Sie können eine JSON-Schema-Validierung ergänzen, doch diese ist optional und wird häufig ausgelassen.

Erkennung und Selbstbeschreibung. Ein SiLA2-Server veröffentlicht seine FDL-Dateien. Ein Client kann jeden Befehl abfragen, parsen und statisch validieren, bevor er ihn sendet. OpenAPI leistet konzeptionell dasselbe, doch FDL ist eigens für die Semantik von Laborgeräten konzipiert (Commands vs. Properties, observable vs. unobservable, definierte Fehler).

Bidirektionale Kommunikation. Manche Geräte müssen Ereignisse an den Orchestrator übermitteln (Tür geöffnet, Probe geladen, Fehlerzustand). gRPC-Streaming erledigt dies über eine einzige Verbindung. REST benötigt dafür einen zweiten Kanal.

Dies sind echte technische Vorteile für die Gerätesteuerung. Sie erzeugen aber auch echte Reibung mit der REST-first-Welt.

Der Status quo - FDL-XML von Hand verfassen

Wenn ein Labor heute einen REST-Endpunkt als SiLA2-Service bereitstellen muss, geht eine Ingenieurin oder ein Ingenieur typischerweise wie folgt vor:

1. Die OpenAPI-Spezifikation lesen (oder die REST-Dokumentation, falls keine Spezifikation existiert).
2. Ein SiLA2-Feature entwerfen - Bezeichner, Anzeigenamen und Beschreibungen wählen.
3. Jede REST-Operation einem SiLA2-Command oder einer Property zuordnen.
4. Jedes Request-/Response-Schema in SiLA2-Datentypen übersetzen.
5. Das FDL-XML von Hand verfassen und gegen das XSD validieren.
6. sila2-codegen ausführen, um .proto-Dateien und gRPC-Stubs zu generieren.
7. Einen Python- (oder Java-/.NET-)Wrapper schreiben, der SiLA2-Aufrufe in REST-Aufrufe übersetzt.

Die Schritte 2-5 dauern Stunden pro Feature und Tage für ein reales Gerät mit über 20 Endpunkten, und das Ergebnis weicht ab, sobald sich die REST-API ändert. Die meisten Teams pflegen diese Wrapper nur widerwillig. Manche geben auf und schreiben einen eigenen HTTP-zu-gRPC-Adapter, der SiLA2 vollständig umgeht - was den Zweck eines Standards zunichtemacht.

Genau für solch repetitive, mechanische Arbeit ist Codegenerierung gedacht.

Die Brücke - openapi-to-sila2

openapi-to-sila2 ist ein Open-Source-Werkzeug (Apache 2.0) in Python, das die gesamte Pipeline automatisiert. Version 0.1.1 wurde am 8. April 2026 auf PyPI veröffentlicht.

Die Pipeline besteht aus vier Stufen, die durch einen einzigen CLI-Befehl ausgeführt werden:

Jede Stufe ist deterministisch, validiert und reproduzierbar:

1. OpenAPI-Parsing - liest eine JSON- oder YAML-Spezifikation ein und validiert deren Struktur.
2. FDL-Generierung - erzeugt SiLA2-Feature-Definition-XML, validiert gegen das offizielle XSD.
3. gRPC-Codegenerierung - ruft das Upstream-Werkzeug sila2-codegen auf, um .proto-Dateien und gRPC-Stubs zu erzeugen.
4. Python-Typklassen - extrahiert Protobuf-Typen in idiomatische Python-Dataclasses für die clientseitige Nutzung.

Installation und Ausführung

pip install openapi-to-sila2

openapi-to-sila2 generate \
  --input plate-reader-api.openapi.json \
  --output ./generated \
  --codegen \
  --types

Das ist alles. Ergebnis: ein vollständig verdrahtetes SiLA2-Feature, bereit zur Einbindung in ein SiLA2-Server-Grundgerüst.

Wie REST-Konzepte auf SiLA2 abgebildet werden

Die Abbildung folgt klaren Festlegungen und ist konsistent:

Dies ist keine perfekte 1:1-Abbildung - die beiden Standards sind tatsächlich unterschiedlich aufgebaut -, aber sie ist genau genug, um für die meisten APIs von Laborgeräten und LIMS direkt verwendet zu werden.

Konkretes Beispiel - ein Plattenlesegerät

Nehmen Sie ein fiktives Plattenlesegerät, das eine kleine REST-API bereitstellt:

# plate-reader-api.openapi.yaml (excerpt)
openapi: 3.0.3
info:
  title: AcmeReader API
  version: 1.2.0
paths:
  /status:
    get:
      tags: [Diagnostics]
      operationId: getStatus
      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/InstrumentStatus'
  /measurements:
    post:
      tags: [Measurement]
      operationId: runMeasurement
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/MeasurementRequest'
      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/MeasurementResult'
components:
  schemas:
    InstrumentStatus:
      type: object
      properties:
        ready: { type: boolean }
        temperature_c: { type: number }
    MeasurementRequest:
      type: object
      required: [wells, wavelength_nm]
      properties:
        wells:
          type: array
          items: { type: string, pattern: '^[A-H](?:[1-9]|1[0-2])$' }
        wavelength_nm: { type: integer, minimum: 200, maximum: 1000 }

Die Ausführung von openapi-to-sila2 generate -i plate-reader-api.openapi.yaml -o ./generated --codegen --types erzeugt neben weiteren Artefakten ein FDL-XML, das wie folgt aussieht (gekürzt):

<?xml version="1.0" encoding="UTF-8"?>
<Feature xmlns="http://www.sila-standard.org"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.sila-standard.org
                             https://gitlab.com/SiLA2/sila_base/raw/master/schema/FeatureDefinition.xsd"
         SiLA2Version="1.0" FeatureVersion="1.0"
         Originator="com.acme" Category="instrument">
  <Identifier>Measurement</Identifier>
  <DisplayName>Measurement</DisplayName>
  <Description>Operations from the Measurement tag of AcmeReader API.</Description>

  <Command>
    <Identifier>RunMeasurement</Identifier>
    <DisplayName>Run Measurement</DisplayName>
    <Description>Trigger a plate read at a specified wavelength.</Description>
    <Observable>No</Observable>
    <Parameter>
      <Identifier>Parameters</Identifier>
      <DisplayName>Parameters</DisplayName>
      <Description>Combined request parameters.</Description>
      <DataType>
        <DataTypeIdentifier>MeasurementRequest</DataTypeIdentifier>
      </DataType>
    </Parameter>
    <Response>
      <Identifier>Result</Identifier>
      <DisplayName>Result</DisplayName>
      <Description>Measurement result payload.</Description>
      <DataType>
        <DataTypeIdentifier>MeasurementResult</DataTypeIdentifier>
      </DataType>
    </Response>
  </Command>
  <!-- DataType definitions follow ... -->
</Feature>

Die zugehörige .proto-Datei (von sila2-codegen aus dem FDL generiert) und die Python-Dataclasses werden im selben Durchlauf erzeugt. Sie implementieren eine Methode - den eigentlichen REST-Aufruf -, der Rest wird generiert.

# Your implementation (the only hand-written part)
import httpx
from generated.measurement_pb2 import MeasurementRequest, MeasurementResult

async def run_measurement(req: MeasurementRequest) -> MeasurementResult:
    async with httpx.AsyncClient(base_url="http://reader.local") as client:
        resp = await client.post("/measurements", json={
            "wells": list(req.wells),
            "wavelength_nm": req.wavelength_nm,
        })
        resp.raise_for_status()
        return MeasurementResult(**resp.json())

Ein Gerät mit 20 Endpunkten, dessen Kapselung in SiLA2 bisher zwei Entwicklungstage erforderte, ist nun eine Aufgabe von 30 Minuten: Generator ausführen, die schlanken REST-Adapterfunktionen schreiben, ausliefern.

Bekannte Einschränkungen

Das Werkzeug legt offen, was es nicht leistet:

• Komplexe Unions (allOf, oneOf, anyOf) werden auf den SiLA2-Typ Any reduziert. Das Typsystem von SiLA2 kennt keine nativen Summentypen.
• Mehrere Fehlerschemas werden auf einen einzigen ExecutionError pro Feature abgebildet - eine Einschränkung von SiLA2, nicht des Werkzeugs.
• Streaming-Endpunkte (Server-Sent Events, WebSocket-Upgrades) werden nicht als SiLA2-Observable-Commands dargestellt. Generieren Sie die statische Oberfläche und ergänzen Sie die Beobachtbarkeit für die wenigen Endpunkte, die sie benötigen, von Hand.
• Dynamische Objekte ohne deklarierte Properties werden standardmässig auf Any abgebildet.

Dies sind Einschränkungen des zugrunde liegenden SiLA2-Standards, keine Fehler. Das Werkzeug generiert, was abbildbar ist, und hält sich beim Rest heraus.

Wo dies in den modernen Labor-Stack passt

Ein Labor im Jahr 2026 ist in Schichten aufgebaut. Jede Schicht hat ihr eigenes Protokoll, das für ihre jeweilige Aufgabe optimiert ist:

• MCP (Model Context Protocol) ist die Schicht der KI-Agenten. Darüber erkennen und rufen Sprachmodelle Werkzeuge auf, einschliesslich Laborgeräten. Wir haben MCP ausführlich in unserem Leitfaden zum Verbinden von KI-Agenten mit Laborgeräten über MCP behandelt.
• SiLA2 ist die Schicht der Geräte-Interoperabilität. Darauf einigen sich grosse IVD-Hersteller, Tecan und Mitglieder des SiLA Consortium für herstellerübergreifende Orchestrierung.
• REST/OpenAPI ist die Schicht für alles Übrige - LIMS, ELN, Terminplanung, Probenverfolgung, interne Dienste, Cloud-Labor-APIs.

openapi-to-sila2 ist an der Grenze zwischen den beiden unteren Schichten angesiedelt. Es ermöglicht einem REST-nativen Gerät oder Dienst, ohne handgeschriebenen Adapter an einer SiLA2-Orchestrierung teilzunehmen. In Kombination mit einem darüberliegenden MCP-Wrapper ist dasselbe Gerät sowohl von klassischen Orchestratoren (SiLA2-fähigen Schedulern wie dem SiLA2 Manager) als auch von modernen KI-Agenten aus erreichbar.

Dies ist die Architektur, die wir bei QPillars in echten Kundenprojekten einsetzen - um Gerätehersteller, die vor Jahren REST ausgeliefert haben, mit SiLA2-nativen LIMS-Implementierungen bei Pharmakunden zu verbinden. Weitere Informationen finden Sie bei unseren Services AI for Instruments und LiquidBridge.

Häufig gestellte Fragen

Warum unterstützt SiLA2 REST nicht einfach nativ?

Weil sich die Designziele des Protokolls - lang laufende beobachtbare Befehle mit Fortschritts-Streams, strenge sprachübergreifende Typisierung, bidirektionale Kommunikation und ein selbstbeschreibendes Schema - mit gRPC allesamt leichter umsetzen lassen als mit REST. SiLA2 hat die Grundlage gewählt, die zum Problem der Laborgeräte passt; die Brücke zu REST ist ein separates, lösbares Problem.

Was genau generiert openapi-to-sila2?

Eine vollständige SiLA2-Feature-Pipeline: eine gegen das XSD validierte FDL-XML-Datei, die das Feature beschreibt, .proto-Dateien (über das Upstream-Werkzeug sila2-codegen), gRPC-Stubs sowie idiomatische Python-Dataclasses für die Request- und Response-Typen. Sie schreiben die schlanken Funktionsrümpfe, die die REST-API aufrufen; alles andere wird generiert.

Kann ich dies heute schon produktiv einsetzen?

Das Werkzeug liegt in Version 0.1.1 vor (veröffentlicht im April 2026), steht unter der Apache-2.0-Lizenz und verfügt über eine funktionierende Testsuite. Es eignet sich heute für interne Projekte, Prototypen und nicht regulierte Umgebungen. Behandeln Sie den generierten Code in GxP-Umgebungen wie jede Drittanbieter-Bibliothek - validieren, Version fixieren und dokumentieren.

Worin unterscheidet sich dies davon, die REST-API einfach direkt aus Python aufzurufen?

Ein direkter REST-Aufruf funktioniert innerhalb einer einzelnen Anwendung. Wenn Ihr Orchestrator, Ihr LIMS oder Ihr Scheduler jedoch SiLA2-nativ ist (was bei den meisten grossen Pharma-Implementierungen der Fall ist), kommuniziert er über gRPC und erwartet einen SiLA2-Server-Endpunkt, keine HTTP-URL. openapi-to-sila2 erzeugt diese SiLA2-Oberfläche, sodass das REST-Gerät oder der REST-Dienst ohne Codeänderungen auf Seite des Konsumenten Teil des SiLA2-Ökosystems wird.

Wie hängt dies mit der MCP-basierten Integration von KI-Agenten zusammen?

Beides ergänzt sich. MCP ist das Protokoll, über das KI-Agenten Werkzeuge erkennen und aufrufen. SiLA2 ist das Protokoll, mit dem klassische Labor-Orchestratoren Geräte steuern. Ein einzelnes Gerät kann auf Basis einer einzigen zugrunde liegenden REST-API sowohl einen MCP-Server (für KI-Agenten) als auch einen SiLA2-Server (für Orchestratoren) haben. openapi-to-sila2 generiert die SiLA2-Seite; ein MCP-Wrapper übernimmt die Agentenseite.

Die wichtigsten Erkenntnisse

• REST und SiLA2 können nicht direkt zusammenarbeiten - SiLA2 ist gRPC über HTTP/2 mit Protobuf, REST ist JSON über HTTP/1.1.
• SiLA2 hat gRPC aus guten Gründen gewählt: beobachtbare Befehle, strenge Typisierung, bidirektionale Streams, native Erkennung - all das ist mit REST schwierig.
• Der übliche Behelf - FDL-XML pro Endpunkt von Hand zu verfassen - kostet Stunden pro Feature und veraltet, sobald sich die REST-API ändert.
• openapi-to-sila2 (v0.1.1, April 2026) automatisiert die gesamte Pipeline: von der OpenAPI-Spezifikation über validiertes FDL-XML und gRPC-Stubs bis zu Python-Typen, mit einem einzigen Befehl.
• Im Labor-Stack von 2026 dient MCP den KI-Agenten, SiLA2 der Orchestrierung von Geräten und REST allem Übrigen - openapi-to-sila2 verbindet die beiden unteren Schichten, sodass REST-Geräte und -Dienste ohne handgeschriebene Adapter an SiLA2-Implementierungen teilnehmen können.

Das Werkzeug ist Open Source. Probieren Sie es mit einer Ihrer Geräte-APIs aus, melden Sie Issues und senden Sie Pull Requests: github.com/qpillars/openapi-to-sila2.

---

Verfasst von Iacob Marian, Technischer Leiter und Mitgründer bei QPillars. Veröffentlicht am 2026-04-17.