SIMATIC PCS 7 validieren: vom Signal zum verlässlichen Prozessnachweis

PCS 7 als Prozessleitsystem mit konkreter Architektur betrachten

SIMATIC PCS 7 ist ein Prozessleitsystem für die Prozessindustrie. Das Konfigurationshandbuch V10.0 SP1 unterscheidet Engineering Station, Operator Station und weitere Komponenten. Die Engineering Station dient der Projektierung; Operator-Systeme stellen Prozessinformationen für Bedienung und Beobachtung bereit. Bei Mehrplatzsystemen werden unter anderem Prozesswerte, Archive und Meldungen vom Server an die Clients geliefert.

Diese Architektur beeinflusst den Prüfumfang. Erfassen Sie, wo eine Funktion projektiert, ausgeführt, bedient und aufgezeichnet wird. Ein Test an einem einzelnen Arbeitsplatz kann eine serverseitige Datenabweichung oder einen Unterschied zwischen ausgelieferten Projektständen übersehen. Ebenso können abhängige Zeit-, Netzwerk- oder Archivdienste für die fachliche Aussage relevant sein.

Der technische Bezug dieses Artikels ist das PCS-7-Handbuch „PC Configuration V10.0 SP1“ vom März 2025. Die aktuelle Produktübersicht nennt V10.0, aber keinen vollständigen Patchstand. SP1 wird hier nicht als neueste Version bezeichnet. SIMATIC BATCH, PCS neo und Opcenter Pharma werden als abgegrenzte Produkte beziehungsweise Komponenten behandelt; ihre Funktionen sind kein stillschweigender PCS-7-Grundumfang.

Quellen: [1] [2]

GMP, funktionale Sicherheit und Anlageneignung sauber abgrenzen

Der regulatorische Beispielsrahmen ist Humanarzneimittel-GMP. Annex 11 behandelt computergestützte Systeme in diesem Bereich als GMP-Leitlinie. Seine Revision Januar 2011 ist im aktuellen EudraLex-Verzeichnis gelistet. Ob zusätzlich FDA-Anforderungen für elektronische Aufzeichnungen relevant sind, wird anhand der zugrunde liegenden Pflichten und der tatsächlichen Nutzung entschieden.

Eine GMP-relevante Temperaturaufzeichnung und eine sicherheitsbezogene Abschaltfunktion können denselben Anlagenbereich betreffen, beantworten aber unterschiedliche Nachweisfragen. Ein Sicherheitsnachweis ersetzt keine Prüfung der für die Produktbewertung genutzten Daten. Umgekehrt bescheinigt eine CSV-Prüfung keine funktionale Sicherheit. Gemeinsame Signale oder Eingriffe müssen trotzdem als Abhängigkeiten verständlich sein.

Auch der physische Messaufbau bleibt eigenständig. Kapitel 3 behandelt geeignete Messausrüstung sowie Kalibrierung und Kontrolle. Ein simulierter Eingang kann die Skalierung der Software prüfen; er belegt nicht die tatsächliche Messrichtigkeit des montierten Fühlers. Annex 15 bildet den Bezug zur Qualifizierung der Anlage. Die beteiligten Nachweise sollten zusammenpassen, ohne dieselbe Arbeit ungezielt zu wiederholen.

Quellen: [3] [4] [5] [9] [8]

Die Prozessfunktion als durchgängige Prüfgrenze wählen

Beginnen Sie mit einer Funktion, deren fehlerhaftes Verhalten die Herstellung oder ihre Bewertung beeinflussen kann. Für eine Temperaturüberwachung sind beispielsweise Messstelle, Einheit, Skalierung, Meldebedingung, Bedienrechte und Datenverwendung relevant. Der Produktname allein ist keine geeignete Grenze. Eine pauschale Softwarekategorie legt weder die konkreten Fehlerfälle noch den notwendigen Nachweis fest.

Beschreiben Sie, welche fachliche Entscheidung auf jeder Information beruht. Eine Anzeige zur Orientierung kann anders zu bewerten sein als ein archivierter Wert, der später einen kritischen Prozessschritt belegen soll. Gemeinsame Infrastruktur darf dennoch nicht übersehen werden: Falsche Zeitzuordnung kann beide Aussagen beeinträchtigen.

Die folgende eigene Arbeitshilfe macht Übergänge sichtbar. Verwenden Sie vorhandene Signal-, Funktions- und Anforderungsunterlagen, wenn diese Beziehungen bereits verständlich dokumentiert sind. Für kritische Systeme fordert Annex 11 eine aktuelle detaillierte Systembeschreibung; daraus folgt nicht derselbe Dokumentationsumfang für jede unkritische Hilfsfunktion.

Quellen: [4] [7]

Den geprüften Projektstand bis zur Ausführung verfolgen

Bestimmen Sie, welche Projektierung einer Prüfung zugrunde liegt und wo dieser Stand tatsächlich wirksam ist. Dazu gehören relevante Bibliotheken, eigene Anpassungen, Bedienbilder und Datenkonfigurationen. Das PCS-7-Handbuch beschreibt zentrale Projektierung und verteilte Komponenten; daraus ergibt sich die praktische Frage, ob die zusammengehörenden Teile konsistent bereitgestellt wurden.

Für Änderungen empfiehlt sich eine kurze, konkrete Wirkungsbeschreibung. „Temperaturüberwachung aktualisiert“ ist weniger hilfreich als die Angabe, welcher Grenzwert, welche Rücksetzbedingung und welche Meldung betroffen sind. Ergänzen Sie, welche Aufzeichnung und welcher Empfänger die Änderung ebenfalls kennen müssen. Eine geänderte Bildbeschriftung kann sonst eine unveränderte Berechnung verdecken.

Prüfen Sie den tatsächlich verwendeten Stand nach der Übertragung. Ein dokumentierter Sollstand allein reicht nicht, wenn die Prüfung auf einer anderen Konfiguration lief. Wie dieser Abgleich technisch erfolgt, richtet sich nach Version und Projektwerkzeugen. Der Artikel behauptet dafür keinen bestimmten Transaktionsweg und keine automatisch vollständige Änderungsprotokollierung.

Quellen: [2] [4]

Signalqualität, Alarm und Bedienhandlung getrennt bewerten

Ein numerisch plausibler Wert kann aus einer falschen Quelle stammen oder veraltet sein. Für kritische Funktionen sollten Ihre Prüfungen daher auch den Zustand der Information betrachten. Definieren Sie das Soll bei ungültigem Signal, Verbindungsverlust und Wiederkehr. Welche Anzeige, Folgeentscheidung und Aufzeichnung dann erforderlich ist, hängt vom vorgesehenen Prozess ab.

Unterscheiden Sie außerdem das Entstehen einer Meldung, ihre Quittierung und das Ende der auslösenden Bedingung. Ein Bediener kann eine Meldung zur Kenntnis genommen haben, obwohl der Prozesswert weiterhin außerhalb des erlaubten Bereichs liegt. Ob zusätzliche Eingriffe zulässig sind, ist separat festzulegen und mit passenden Rollen zu prüfen.

Bei der Testplanung hilft eine Rollenfolge: Beobachter sieht den Zustand, Bediener quittiert im erlaubten Umfang, berechtigter Verantwortlicher ändert gegebenenfalls einen Grenzwert. Ein unberechtigter Änderungsversuch muss ebenfalls Teil eines passenden Prüffalls sein. Diese Rollen sind eine methodische Vorlage, keine Behauptung vordefinierter PCS-7-Berechtigungsprofile.

Quellen: [4] [7]

Illustratives Beispiel: Temperaturwert, Meldung und Aufzeichnung

Das Beispiel ist ein konstruiertes Sollmodell für eine Testumgebung, kein durchgeführter PCS-7-Test und keine Vorgabe für eine reale pharmazeutische Temperaturführung. Eingang T-201 bildet 4 bis 20 mA linear auf 0 bis 100 °C ab. Die unabhängig festgelegte Umrechnung lautet T = (I − 4) × 100 / 16. Damit entsprechen 12,00 mA genau 50,00 °C.

Die Beispielanforderung aktiviert eine Meldung bei mindestens 60,00 °C. Nach ihrer Aktivierung endet der aktive Zustand erst bei höchstens 58,00 °C. Eine Quittierung verändert diese Temperaturbedingung nicht. Die Projektanforderung verlangt hier gültige Werte im Fünfsekundenraster ohne Verdichtung. Diese Vorgaben müssen in der Testkonfiguration ausdrücklich umgesetzt sein; sie sind keine behaupteten PCS-7-Standardeinstellungen.

Der Anfangszustand um 12:00:00 ist gültig, mit 50,00 °C und ohne aktive Meldung. Um 12:00:05 folgen 59,00 °C, um 12:00:10 genau 60,00 °C. Bei 61,00 °C um 12:00:15 quittiert der Bediener; die Meldung bleibt aktiv. Um 12:00:20 erreicht der Wert 58,00 °C. Die nachstehende Tabelle definiert das erwartete Verhalten und zusätzliche unabhängige Fehlerfälle.

Für jede Fehlerfallvariante wird der bekannte Ausgangszustand wiederhergestellt. Testeingabe, beobachtete Anzeige, Meldungsereignisse und gespeicherte Reihe werden getrennt erfasst. Zeitliche Toleranzen sind vor der Durchführung passend zur Architektur zu bestimmen; die idealisierte Zeitreihe legt keine allgemeine Reaktionszeit fest.

Quellen: [4] [6]

Gespeicherte Daten anhand ihres Verwendungszwecks prüfen

Das Konfigurationshandbuch nennt Prozesswerte, Archive und Meldungen als Bestandteile der Operator-Systeme. Welche Daten davon tatsächlich benötigt, gespeichert und weiterverwendet werden, ist eine Projektentscheidung. Für das Beispiel wird die gespeicherte Reihe mit der unabhängig festgelegten Eingabereihe verglichen. Prüfen Sie auch Einheiten, Zeitbezug und die Kennzeichnung ungültiger beziehungsweise fehlender Werte.

Eine Verdichtung kann für einen bestimmten Zweck geeignet sein und für einen anderen eine relevante kurze Abweichung verdecken. Entscheidend ist die spätere fachliche Bewertung. Ein übersichtlicher Trend ist kein Ersatz für diese Entscheidung. Ebenso kann ein Export eine andere Darstellung liefern als die ursprünglichen Daten; die Bedeutung muss dennoch erhalten bleiben.

Für relevante Änderungen und Bedienhandlungen wird der erforderliche Nachweis festgelegt. Ein Ereignisprotokoll, eine Alarmhistorie und ein Audit Trail können unterschiedliche Fragen beantworten. Prüfen Sie die tatsächliche Abdeckung, statt jedem Protokoll dieselbe Bedeutung zuzuschreiben. Ob elektronische Signaturen erforderlich sind, bestimmen Sie anhand des Prozesses und der anwendbaren Anforderungen. Die konkrete Ausführung benötigt passende Belege; eine Bedienbestätigung allein erfüllt diese Aufgabe nicht automatisch.

Quellen: [2] [6] [4]

FAT, SAT und Softwareprüfungen passend verbinden

Vorhandene Anlagen- und Lieferantentests können Anforderungen bereits abdecken. Ordnen Sie einen Beleg der konkreten Aussage zu: Ein Simulationstest kann eine Rechenregel prüfen, während der reale Signalweg ergänzend an der eingebauten Messstelle untersucht werden muss. Ein Abnahmeprotokoll ohne nachvollziehbare Eingabe und Ergebnislage beantwortet diese Frage nicht ausreichend.

Annex 15 beschreibt im Anlagenkontext, dass geeignete FAT-Prüfungen unter begründeten Bedingungen nicht vor Ort wiederholt werden müssen. Entscheidend ist, ob Transport, Installation oder Einbindung die geprüfte Funktion beeinflussen. Diese Übertragungsentscheidung wird für den jeweiligen Nachweis getroffen; sie ist weder ein pauschaler Freibrief noch eine Pflicht zum Doppeltest.

Planen Sie offene Prüfschritte gemeinsam mit Automatisierung, Verfahrenstechnik und QA. Die technische Umsetzung kann richtig sein, während das fachliche Soll unklar bleibt. Umgekehrt kann ein guter Prozessentwurf an einem nicht repräsentativen Testaufbau scheitern. Dokumentieren Sie deshalb die Grenzen der Umgebung und die verbleibenden Nachweise.

Quellen: [9] [4]

Betrieb, Wiederherstellung und Änderungen mitdenken

Für eine kritische Prozessfunktion zählen auch geplante Updates, Störungen und der Zugriff auf ältere Aufzeichnungen. Legen Sie fest, wer Änderungen bewertet und wann eine fachliche Neubewertung erforderlich wird. Ein Betriebssystem-Update kann andere Auswirkungen haben als ein geänderter Funktionsbaustein oder ein neuer Archivempfänger.

Das PCS-7-Handbuch beschreibt Redundanzmöglichkeiten für Operator-Systeme. Eine vorhandene Redundanzkonfiguration beweist jedoch nicht, dass Ihre relevante Funktion bei Umschaltung korrekt weiterläuft oder alle benötigten Daten vollständig bleiben. Ein passender Test betrachtet die vereinbarte Wirkung auf Bedienung, Verarbeitung und Aufzeichnung.

Ein Wiederherstellungsnachweis sollte die zusammengehörende Projektierung und verwendbaren Daten erfassen. Prüfen Sie nach einem Restore nicht nur die Anmeldung, sondern eine repräsentative Funktion und den Zugriff auf benötigte Informationen. Bei Störungen wird die fachliche Bedeutung bewertet. Ein kritischer Vorfall kann weitergehende Ursachenklärung verlangen; nicht jeder technische Hinweis rechtfertigt denselben Untersuchungsumfang.

Quellen: [2] [4]

Welche Vorbereitung den Aufwand belastbar macht

Für ein kleines Unternehmen ist die wichtigste Vorarbeit ein begrenztes, gemeinsam verstandenes Ziel. Wählen Sie repräsentative kritische Funktionen und benennen Sie deren Nutzer. Verfahrenstechnik liefert Prozessgrenzen, Automatisierung erklärt die Umsetzung, IT den Betrieb, QA die Bewertung der vorgesehenen Nachweise. Bei externen Integratoren sind Zuständigkeiten und verfügbare Unterlagen früh zu klären.

Qualitative Aufwandstreiber sind Sonderlogik, Anzahl unterschiedlicher Signalwege, verteilte Projektstände, Datenübergaben und eingeschränkte Testmöglichkeiten. Auch ein kleines System kann anspruchsvoll sein, wenn relevante Funktionen nur während eines knappen Stillstands geprüft werden können. Eine große, einheitliche Installation kann dagegen wiederverwendbare Belege bieten.

Ein vorbereitetes Paket ermöglicht eine begründete Reihenfolge: zuerst fachliche Regeln und Risiken, dann vorhandene Nachweise, anschließend gezielte Restprüfungen. Der Aufwand folgt dieser Aufgabe. Eine allgemeine Testzahl, feste Projektdauer oder pauschale GAMP-Kategorie ersetzt die Abgrenzung nicht.

• Architektur, installierte Stände und wirksame Projektierung zusammenstellen.
• Kritische Messstellen und ihre Datenverwendung benennen.
• Signal-, Einheiten-, Alarm- und Eingriffsregeln fachlich festlegen.
• Geeignete Simulation, reale Anlagenprüfungen und ihre Grenzen abstimmen.
• Rollen sowie dokumentierte Ausgangs- und Rücksetzzustände vorbereiten.
• FAT-/SAT-Belege, offene Abweichungen und Betriebsverfahren zugänglich machen.

Quellen: [4] [7]