QIA.Service – Modular Digitalization Interface (2020–2024)

Ziel des Projekts war es, Daten der QIAStatDx-Produktionslinien in validierter Form in der Azure Cloud bereitzustellen. Dafür wurde eine modulare Schnittstellen-Architektur entwickelt – unterteilt in Core, Plugins und eine Configuration Layer.

Verwandte Seiten: QIAGEN – QIAStatDx Large Scale Line · Manufacturing Radar

Architektur & Topologie

QIA.Service topology / modular interface structure

Abbildung: Modulare Struktur der Schnittstelle. Aufteilung in Core-Entwicklung, Plugin-Entwicklung und eine Configuration Layer zur Anpassung der Plugins an lokale Anforderungen. Dadurch können Rollouts, die nur Konfiguration benötigen, validierungsfreundlich umgesetzt werden.

Requirements Engineering

Die Anforderungsarbeit war in diesem Projekt besonders vielschichtig: Stakeholder aus Produktion, QA und IT hatten teils konkurrierende Ziele – gleichzeitig mussten alle Anforderungen validierungskonform spezifiziert werden.

Elicitation

  • Stakeholder-Workshops mit Produktion, QA und IT-seitig
  • Anforderungserhebung für OPC/UA-Client, Cloud-Anbindung und Plugin-Architektur
  • Technische Konzepte: Generic Programming, Virtualisierung, Docker-Deployment

Modelling

  • Schnittstellenspezifikation je Plugin (Eingabe/Ausgabe, Fehlerfälle, Konfigurierbarkeit)
  • Traceability von Anforderungen bis in Qualifizierungsdokumente
  • Risk Matrix: Priorisierung und Risikoklassifikation

Software

Architektur

  • Modulares Plugin-System: Core + Plugins + Configuration Layer
  • Trennung von Core-Entwicklung und konfigurationsbasierten Rollouts – als Grundlage für schlanke Validierungszyklen
  • Windows Service / Docker-Deployment

Entwicklung

  • Validiertes Backend „Analytics Interface" (.NET 6 / Azure / Docker)
  • Plugins: DbTransfer (MSSQL/MariaDB), CSV, OPC/UA, Computer Vision, Azure Blob / Event Hub / IoT Hub
  • R&D-Plattform „Manufacturing Radar" (C# / ASP.NET Core / Razor Pages)
  • 3rd Level Support

Validation

Die Validierbarkeit war kein nachgelagerter Schritt, sondern ein architektonisches Designziel: Die Configuration Layer ermöglicht Rollouts ohne erneute Kern-Validierung.

Strategie

  • Validierungskonzept: Trennung von Core- und Konfigurations-Änderungen als Basis für risikobasierte Qualifizierung
  • ALCOA+-konforme Datenbereitstellung in der Cloud

Dokumente

  • URS – User Requirements Specification
  • SDS – Software Design Specification
  • FDS – Functional Design Specification
  • DQ / IQ / OQ / PQ – Qualifizierungsdokumente
  • Risk Matrix

Technisches Umfeld

  • .NET 6.0
  • Windows Service / Docker
  • Azure DevOps
  • Azure Cloud (IoT Hub, Event Hub, Blob Storage)
  • MSSQL / MariaDB
  • OPC/UA