Wer ein SPS-Angebot mit einem DCS-Angebot vergleicht, vergleicht möglicherweise zwei verschiedene Projekte. Ein Preis enthält nur Steuerungen und Basisengineering, der andere zusätzlich koordinierte Chargenführung, Bedienplätze, Bibliotheken, Historie und Support. Wird zuerst der günstigere Controller gewählt, ohne die Grenzen abzugleichen, wandern Kosten und Risiken in Integration, Qualifizierung und späteren Betrieb.
Entscheidend ist, welche Architektur den vorgesehenen Prozess ausführt, erforderliche Nachweise erhält und dauerhaft unterstützt werden kann. Weder SPS beziehungsweise PLC noch DCS ist für pharmazeutische Herstellung grundsätzlich überlegen. Moderne Lösungen überschneiden sich stark; die angebotene Konfiguration ist wichtiger als die Produktkategorie.
Das notwendige Prozessverhalten beschreiben
Beginnen Sie mit Prozessbeschreibungen und Ausrüstungsgrenzen. Diskrete Vorgänge betonen häufig Maschinenzustände, Verriegelungen, Bewegung und wiederholbare Sequenzen. Kontinuierliche Prozesse verlangen koordinierte Regelung und dauerhaften Betrieb. Chargenprozesse verbinden Ausrüstung, prozedurale Schritte, Rezepte, Haltezustände und Übergänge. Ein Standort kann alle drei Formen und selbstständig gesteuerte Lieferantenskids enthalten.
Identifizieren Sie lokale Entscheidungen und die erforderliche Koordination zwischen Einheiten. Bewerten Sie unterbrochene Steuerung, ausgefallene Überwachung und fehlende Aufzeichnungen getrennt. Verpackungsmaschine, Wasseranlage und Mehrproduktreaktor erhalten nicht dieselben technischen Anforderungen, nur weil sie unter GMP betrieben werden.
[QRM] Untersuchen Sie Qualität, Patientensicherheit, Datenintegrität und Betriebsfolgen auf Funktionsebene. Die Zahl kritischer Instrumente allein begründet keine Plattformwahl. Beziehungen zwischen Funktionen, gemeinsame Abhängigkeiten und Wiederanlauf können die Entscheidung stärker beeinflussen als die Anzahl einzelner Signale.
Vollständige Lösungen statt historischer Bilder vergleichen
Eine speicherprogrammierbare Steuerung ist eine Technologie, um die eine umfassende Automatisierung aufgebaut werden kann. Ein DCS bietet typischerweise eine integrierte Umgebung für verteilte Prozessführung und Überwachung. SPS-Lösungen können jedoch anspruchsvolle Batch-, Redundanz- und Informationsfunktionen enthalten. Auch ein DCS benötigt gezielte Anwendungstechnik und externe Schnittstellen.
Aussagen wie „SPS kann keine Chargenproduktion“ oder „DCS ist automatisch GMP-konform“ sind ungeeignet. Fragen Sie nach angebotener Version, Modulen und Konfiguration. Innerhalb derselben Produktfamilie können Verfügbarkeit, Sicherheit und Aufzeichnungen sehr unterschiedlich umgesetzt sein. Marketing beschreibt diese Unterschiede selten ausreichend.
Bringen Sie alle Angebote auf denselben Umfang: Controller, Ein- und Ausgänge, Werkzeuge, Bedienung, Chargenausführung, Historian, Identität, Audit, Infrastruktur, Schnittstellen, Lizenzen, Tests, Dokumentation, Schulung und Support. Benennen Sie ausgeschlossene Funktionen und deren Lieferverantwortung. „Durch andere“ ist keine abgeschlossene Zuordnung, solange kein Verantwortlicher feststeht.
Entscheidungskriterien mit Nachweisen verbinden
| Kriterium | Frage an beide Lösungen | Geeigneter Nachweis |
|---|---|---|
| Prozesseignung | Sind Zustände, Regelkreise und Sequenzen verständlich abbildbar? | Repräsentative Vorführung und geprüfter Funktionsentwurf |
| Chargenkoordination | Wer besitzt Rezepte, Ressourcen und Wiederanlauf? | Abläufe mit Halt und abnormalen Übergängen |
| Verfügbarkeit | Welche Fehler werden toleriert, welche Abhängigkeiten bleiben gemeinsam? | Architekturanalyse und kontrollierte Ausfälle |
| Wartbarkeit | Kann das Standortteam diagnostizieren, wiederherstellen und ändern? | Wartungsübung, Quellenzugang und unterstützte Werkzeuge |
| Daten und Integration | Wie bleiben Handlungen und Transaktionen nachvollziehbar? | Rekonstruktion und Abgleich über die Systemgrenzen |
| Lebenszykluskosten | Was muss erneuert, erweitert und unterstützt werden? | Aufgeschlüsselte Annahmen und vertragliche Verantwortung |
Legen Sie Gewichte erst fest, wenn Beteiligte Folgen und Randbedingungen verstanden haben. Eine unverzichtbare Anforderung ist ein Ausschlusskriterium. Ihre Nichterfüllung darf nicht durch attraktive Grafiken oder niedrige Lizenzkosten ausgeglichen werden. Dokumentieren Sie, weshalb die Kriterien je Projekt unterschiedlich gewichtet werden.
Rezeptausführung und Chargenzustand untersuchen
Ein Rezept besteht aus mehr als Sollwerten. Prüfen Sie prozedurale Struktur, Grenzen, Ausrüstungszuordnung und Versionsfreigabe. Trennen Sie freigegebene Masterdefinition und chargenspezifische Instanz. Erhalten Sie die Beziehung zwischen genehmigter Version, erlaubten Anpassungen und tatsächlicher Ausführung.
Besprechen Sie Halt, Stopp, Abbruch und Wiederanlauf mit Prozessfachleuten. Derselbe Begriff kann in verschiedenen Paketen anderes bedeuten. Definieren Sie Ventile, Rührwerk, Heizung und Materialweg je Zustand sowie Bedingungen der Fortsetzung. Der Wiederanlauf darf weder eine Zugabe unbemerkt wiederholen noch eine offene Prüfung überspringen.
[STANDARD] ISA-88 liefert hilfreiche Konzepte. Ein entsprechend benanntes Batch-Modul ist dadurch nicht automatisch für jeden Prozess geeignet. Verlangen Sie Nachweise, dass die konkrete Anwendung Rezepte und Ausnahmezustände einschließlich Skids und manueller Schritte korrekt repräsentiert.
Redundanz auf Ebene des Dienstes verstehen
Was ist doppelt vorhanden: CPU, Versorgung, Ein- und Ausgänge, Netzwerk, Server, Speicher, Bedienplatz oder Dienst? Was bleibt gemeinsam? Zwei Controller mit derselben problematischen Kommunikationskomponente schützen möglicherweise nicht gegen den relevanten Fehler. Zwei Server können von einem einzigen Speicher oder derselben fehlerhaften Identitätskonfiguration abhängen.
Definieren Sie Prozess- und Datenverhalten während der Umschaltung. Betrachten Sie offene Befehle, vorübergehende Anzeigen, Alarmierung, Puffer und Chargenkontext. „Nahtlos“ braucht ein Akzeptanzkriterium: Welche Funktion bleibt bei welchem Fehler mit welchen beobachtbaren Effekten erhalten? Eine undefinierte Lieferantenaussage reicht nicht.
Nicht jedes System braucht doppelte Hardware. Bei einer begrenzten Maschine können kontrollierter Stopp und schnelle Wiederherstellung angemessen sein; ein anderer Prozess benötigt Fortsetzung bei festgelegten Fehlern. Dokumentieren Sie Bewertung, Betriebsreaktion und Grenzen. Die Prüfung selbst darf keine unvertretbaren Gefahren erzeugen.
Engineeringwerkzeuge und Änderungen bewerten
Untersuchen Sie Vergleich von Konfigurationen, Versionsführung, Bibliotheken, Rechtetrennung und Beziehung zwischen Onlinecode und Archiv. Wie erkennt ein autorisierter Ingenieur die laufende Version und unerklärte Unterschiede? Eine Sicherung ohne Zuordnung zur installierten Anwendung ist eine schwache Grundlage für den Wiederanlauf.
Was bewirkt die Änderung eines Anlagenobjekts? Betrifft sie einen Controller, viele Einheiten, gemeinsame Grafiken oder eine Datenbank? Sind Einsatzorte identifizierbar und Änderungen vorab repräsentativ prüfbar? Integrierte Plattformen vereinfachen Konsistenz, können aber die Folgen gemeinsamer Konfigurationsänderungen vergrößern.
[GUTE INGENIEURPRAXIS] Legen Sie Konventionen für Namen, wiederverwendbare Funktionen, Fehler, Diagnose und unzulässige Abkürzungen fest. Ordnen Sie Verantwortung zu und prüfen Sie die Umsetzung. Codeumfang, Dokumentenzahl oder vertraute Programmiersprache ersetzen kein verständliches und beherrschtes Anwendungsverhalten.
Bedienbarkeit in die Auswahl aufnehmen
Die Architektur beeinflusst Navigation, Befehlsautorität und Störungsbewältigung. Zeigen Sie gewöhnliche und schwierige Aufgaben: fehlende Freigabe finden, veralteten Messwert erkennen, ausgeführte mit vorgesehenen Parametern vergleichen und Verantwortung zwischen lokalem und zentralem Betrieb übertragen.
Gemeinsame SCADA-Grafiken garantieren keine gemeinsamen Zustandsbedeutungen in den Skids. Bediener müssen verfügbare Befehle, zuständige Steuerung und Annahme einer Aktion erkennen. Ein Tastendruck darf nicht als abgeschlossene Prozesshandlung erscheinen, bevor der Controller das Ergebnis entsprechend dem vereinbarten Ablauf bestätigt.
Beziehen Sie repräsentative Anwender ein und dokumentieren Sie beobachtete Fehlhandlungen. Der Beitrag zu SCADA und HMI vertieft diese Gestaltung. Überführen Sie Befunde in Anforderungen und Abnahmeszenarien, damit sie die Beschaffung tatsächlich beeinflussen.
GMP-Nachweise von Produktfunktionen unterscheiden
[REGULATORISCHE ANFORDERUNG] Wenden Sie Anforderungen an computergestützte Systeme und Dokumentation auf den Verwendungszweck an. Annex 11 und Kapitel 4 gelten zum Prüftermin weiter in den Fassungen von 2011; Annex 15 bildet den Qualifizierungs- und Validierungsrahmen. Part 11 hängt von den betroffenen Aufzeichnungen und Signaturen ab. Keiner dieser Rahmen schreibt allgemein SPS oder DCS vor.
Bestimmen Sie die Erhaltung zurechenbarer Handlungen, wichtiger Änderungen, Rechte, Zeitinformationen und prüfbarer Aufzeichnungen. Manche Funktionen liegen außerhalb des Controllers. Verifizieren Sie den gesamten Weg vom Ereignis zur gespeicherten Information einschließlich manueller Schritte und möglicher unkontrollierter Exporte.
[LEITLINIE] Die FDA-CSA-Guidance vom Februar 2026 betrifft Medizinprodukteproduktion und Qualitätsmanagementsoftware. Risikobasierte Gedanken ersetzen pharmazeutische GMP-Validierung nicht pauschal. Wählen Sie Assurance nach Anforderungen, Verwendungszweck und Risiko, mit belastbaren Nachweisen für die spezifizierten wichtigen Funktionen.
Kosten über einen transparenten Lebenszyklus vergleichen
Vergleichen Sie Anschaffung, Umsetzung und laufende Kosten über einen vereinbarten Zeitraum. Dazu gehören Lizenzen, Infrastruktur, Engineering, Integration, Qualifizierungsunterstützung, Schulung, Service, Ersatzteile, Cybersicherheit und geplante Updates. Machen Sie Annahmen zu Erweiterung und Support sichtbar statt nur eine Gesamtsumme anzugeben.
Bewerten Sie Abhängigkeiten. Ein günstiger Einstieg kann seltene Spezialisten, proprietäre Bibliotheken oder ungeeignete Fernservicezeiten voraussetzen. Eine integrierte Lösung kann Schnittstellenarbeit reduzieren und zugleich spätere Migration verteuern. Diese Wirkungen lassen sich nicht aus der Plattformbezeichnung allein ableiten.
Modellieren Sie eine weitere Einheit, ein unterstütztes Update, einen veralteten Server und eine größere Wiederherstellung. Trennen Sie verbindliche Preise, Standortschätzungen und unsichere Ausfallannahmen. Eine Spannweite mit erklärten Annahmen kann nützlicher sein als eine scheinbar präzise, unbelegte Renditezahl.
Beispiel: Steuerung für einen Mehrproduktbereich auswählen
Ein illustrativer Standort ergänzt drei Prozesseinheiten und zwei Skids. Ein Angebot nutzt SPS mit gemeinsamer Supervision und Batch-Ebene, das andere DCS mit integrierter Chargenführung. Zuerst werden Historian, Rezeptfreigabe, Identität und langfristiger Support in beiden Angeboten auf denselben Umfang gebracht.
Die entscheidende Vorführung zeigt einen unterbrochenen Transfer zwischen Einheiten mit Wiederanlauf. Beide Anbieter weisen Ausrüstungsautorität, Verhinderung doppelter Zugaben, Chargenkontext und verständliche Anweisungen nach. Zusätzlich diagnostiziert die Standortwartung einen simulierten Kommunikationsfehler mit den vorgeschlagenen Werkzeugen.
Eine Umsetzung zeigt bessere Ressourcenkoordination, die andere bessere Anschlussfähigkeit an Bestand und vorhandene Kompetenzen. Die Entscheidung bewertet konkrete Nachweise gegen vereinbarte Grenzen. Sie erklärt nicht eine Technologie allgemein zum Sieger. Grenzen der verworfenen Option und Restrisiken der gewählten Lösung bleiben dokumentiert.
Vor der Bindung eine repräsentative Vorführung nutzen
Geben Sie jedem Anbieter dieselbe begrenzte Prozessbeschreibung, Startbedingungen und Ergebnisse. Einschließen sollten Sie Normalablauf, ungültigen Befehl, Verlust eines Eingangs und Wiederanlauf. Verlangen Sie Erklärung der Konfiguration und Abhängigkeiten, statt nur einen vorbereiteten Bedienbildschirm zu betrachten.
Beobachten Sie projektspezifischen Aufwand und spätere Wartbarkeit. Welche Funktionen sind Standardprodukt, konfigurierte Bibliothek oder eigener Code? Erfassen Sie die gezeigte Version. Trennen Sie demonstrierte Ergebnisse von versprochener künftiger Entwicklung; eine Zusage braucht vertragliche Lieferung und Abnahmebedingungen.
Prüfen Sie offene Punkte gemeinsam mit Prozess, Betrieb, Wartung, Automatisierung und Qualität. Manche lassen sich mit begründeten Verfahren beherrschen, andere zeigen eine grundlegende Fehlpassung. Dokumentieren Sie den Unterschied. Nicht jede Unvollkommenheit verwirft die Plattform, aber eine überzeugende Präsentation ersetzt keinen kritischen Nachweis.
Die Wartungsfähigkeit praktisch erproben
Lassen Sie eine autorisierte Person die laufende Konfiguration identifizieren und mit der abgelegten Version vergleichen. Anschließend soll sie einen begrenzten Fehler diagnostizieren und die erforderlichen Schritte zur Wiederherstellung erläutern. Damit wird geprüft, ob Werkzeuge, Zugänge, Dokumentation und Fähigkeiten tatsächlich zusammenpassen.
Berücksichtigen Sie die Situation außerhalb der Projektphase. Ein einzelner Entwickler kann eine komplexe Lösung hervorragend bedienen, während der Bereitschaftsdienst keinen geeigneten Zugang hat. Definieren Sie, welche Aufgaben lokal möglich sein müssen und welche eine vertraglich verfügbare Spezialkompetenz benötigen. Prüfen Sie die Erreichbarkeit und Voraussetzungen dieser Unterstützung.
Eine Übung kann außerdem zeigen, welche Änderungen zentrale Komponenten beeinflussen. Wenn eine Bibliothekskorrektur mehrere Einheiten betrifft, muss das Team die betroffenen Installationen erkennen und die Verifikation planen können. Wartbarkeit bedeutet daher mehr als eine übersichtliche Programmoberfläche; sie umfasst kontrollierte Entscheidungen unter realen Betriebsbedingungen.
Eine belastbare Auswahlentscheidung dokumentieren
Gleichen Sie vor Genehmigung technische Bewertung und Bestellumfang ab. Überführen Sie offene Annahmen in Liefergegenstände, Verantwortlichkeiten und Abnahmebedingungen. Stimmen angebotene und vorgeführte Version überein? Wie werden Ersatzkomponenten bewertet? Die Auswahlvorführung ersetzt nicht die Verifikation des ausgelieferten Systems.
Der abschließende Nachweis umfasst vereinbarte Prozesszustände, vergleichbaren Umfang, objektive Kriterien, gemeinsame Abhängigkeiten, Wiederherstellungsgrenzen, lokale Supportfähigkeit und eindeutige Datenverantwortung. Kosten und Ausschlüsse müssen sichtbar bleiben. Auch ein gewählter Anbieter kann begründete Restpunkte haben, die im folgenden Design gezielt geschlossen werden.
Stellen Sie sicher, dass eine unverzichtbare Anforderung im Vertrag erhalten bleibt. Bei der kommerziellen Abstimmung können Schulung, Testumgebung oder Schnittstellenunterstützung gestrichen werden, obwohl die technische Bewertung deren Verfügbarkeit vorausgesetzt hat. Eine abschließende Gegenprüfung verhindert, dass die Bestellung eine andere Lösung beschreibt als die freigegebene Auswahl.
Lesen Sie vor Festlegung der Grenzen die Methode zur GMP-Automatisierungsarchitektur. Relevante Anwendungen sind Water & WFI Systems und Aseptic Fill-Finish & Barrier Systems. Der Hub Automation & Digital Systems verbindet die Entscheidungen.
Ausfälle mit unterschiedlichen Folgen getrennt vergleichen
Untersuchen Sie zunächst den Verlust einer Bedienstation. Die Steuerung kann weiterarbeiten, während Diagnose oder manuelle Eingriffe eingeschränkt sind. Beide Anbieter sollen zeigen, welche Aufgaben auf einer anderen Station verfügbar bleiben und wie Bediener den tatsächlichen Zustand erkennen. Prozesskontinuität allein beweist hier noch keine ausreichende Bedienfähigkeit.
Betrachten Sie anschließend einen ausgefallenen Identitätsdienst. Eine laufende Sitzung kann weiter funktionieren, während eine neue Anmeldung scheitert. Klären Sie, wer während dieser Störung autorisierte Wartungsarbeiten ausführen kann und wie der kontrollierte Notzugriff endet. Diese Abhängigkeit kann beide Plattformen betreffen, obwohl ihre Steuerungstechnik sehr verschieden ist.
Prüfen Sie schließlich eine unterbrochene Aufzeichnung bei intakter Steuerung. Der Anbieter muss erklären, welche Informationen lokal erhalten bleiben, wie die Lücke sichtbar wird und wie der Abgleich nach Rückkehr des Dienstes erfolgt. Erst damit lässt sich beurteilen, ob eine fortgesetzte Produktion unter den festgelegten Bedingungen zulässig und nachvollziehbar bleibt.
Diese getrennten Betrachtungen vermeiden eine pauschale Verfügbarkeitsbewertung. Sie zeigen, ob die vorgeschlagene Lösung genau jene Funktionen erhält oder wiederherstellt, die für den konkreten Standort erforderlich sind. Die Bewertung dokumentiert dabei sowohl nachgewiesene Fähigkeiten als auch verbleibende Grenzen.
Primärquellen und Status
Geprüft am 23. September 2026: EudraLex Band 4; 21 CFR Part 11; ISA-Normenkatalog einschließlich ISA-88; FDA CSA, endgültig Februar 2026. Kriterien und Beispiele sind eigene GuideGxP-Empfehlungen, keine proprietären Standardtabellen oder universellen regulatorischen Vorgaben.
