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

The aim of the project was to collect data from the QIAStatDx production lines validated form in the Azure Cloud to provide. A modular interface architecture was developed for this purpose - divided into core, plugins and a configuration layer.

Related pages: QIAGEN – QIAStatDx Large Scale Line · Manufacturing Radar

Architecture & Topology

QIA.Service topology / modular interface structure

Figure: Modular structure of the interface. Divided into core development, plugin development and a configuration layer to adapt the plugins to local requirements. This means that rollouts that only require configuration can be implemented in a validation-friendly manner.

Requirements Engineering

The requirements work in this project was particularly complex: stakeholders from production, QA and IT sometimes had competing goals - at the same time, all requirements had to be specified in accordance with validation.

Elicitation

  • Stakeholder workshops with production, QA and IT side
  • Requirements gathering for OPC/UA client, cloud connection and plugin architecture
  • Technical concepts: Generic programming, virtualization, Docker deployment

Modelling

  • Interface specification for each plugin (input/output, error cases, configurability)
  • Traceability from requirements to qualification documents
  • Risk Matrix: Prioritization and risk classification

Software

architecture

  • Modulares Plugin-System: Core + Plugins + Configuration Layer
  • Separation of core development and configuration-based rollouts – as a basis for lean validation cycles
  • Windows Service / Docker-Deployment

Development

  • 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

Validability was not a downstream step, but rather an architectural design goal: The configuration layer enables rollouts without re-validation of the core.

Strategy

  • Validation concept: Separation of core and configuration changes as a basis for risk-based qualification
  • ALCOA+ compliant data provision in the cloud

Documents

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

Technical environment

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