Einleitung Automatisierten Systemen SIMATIC STEP 7 V5 · PDF fileEinleitung Leitfaden zur Durchführung von Automatisierungsprojekten im GMP Umfeld iv A5E01100598-01 Gültigkeitsbereich

s Einleitung Inhaltsverzeichnis Voraussetzung für die Projektierung von Automatisierten Systemen im GMP-Umfeld

1

Anforderungen an Automatisierte Systeme im GMP-Umfeld

2 Systemspezifikation 3 Leitfaden für die Implementierung von im GMP-Umfeld mit Standard SIMATIC STEP 7 Software

4

Ergänzende Hard- / Software Komponenten 5 Unterstützende Funktionen bei der Qualifizierung 6 Index

SIMATIC STEP 7 V5.4

GMP-Engineering Handbuch Leitfaden zur Durchführung von Automatisierungsprojekten im GMP Umfeld

04/2007 A5E01100598-01

Siemens AG Bereich Automation and Drives Competence Center Pharma (A&D CC P)

D- 76181 KARLSRUHE DEUTSCHLAND

A5E01100598-01 04/2007

Copyright © Siemens AG 2007 Änderungen vorbehalten

Sicherheitshinweise Hinweise, die Sie zu Ihrer persönlichen Sicherheit sowie zur Vermeidung von Sachschäden beachten müssen sind in den jeweiligen technische Handbücher zu finden. Die im Fokus des Pharmazeuten liegende Sicherheit der pharmazeutischen Produkte muss durch das Pharmaunternehmen selbst bewertet werden. Das vorliegende Dokument gibt hierfür Hinweise.

Qualifiziertes Personal Inbetriebsetzung und Betrieb eines Gerätes dürfen nur von qualifiziertem Personal vorgenommen werden. Qualifiziertes Personal im Sinne der sicherheitstechnischen Hinweise dieses Handbuchs sind Personen, die Berechtigung haben, Geräte, Systeme und Stromkreise gemäß den Standards der Sicherheitstechnik in Betrieb zu nehmen, zu erden und zu kennzeichnen.

Leitfaden zur Durchführung von Automatisierungsprojekten im GMP Umfeld A5E01100598-01 iii

Einleitung

Zielsetzung des Handbuchs Das vorliegende Handbuch beschreibt die Anforderungen aus pharmazeutisch regulatorischer Sicht (kurz: GMP-Sicht) (GMP – Good Manufacturing Practice) an ein automatisiertes System, die Software, sowie die Vorgehensweise für die Projektierung von SIMATIC STEP 7. Der Zusammenhang zwischen Anforderungen und der Umsetzung wird anhand von praktischen Beispielen erläutert.

Zielgruppen Das Handbuch richtet sich an alle Anlagenbetreiber, Verantwortliche für branchenspezifische Leitsystemkonzepte, Projektleiter und Programmierer, Wartungs- und Instandsetzungspersonal, die Prozessleittechnik im GMP-Umfeld einsetzten. Es zeigt Lösungswege für die Umsetzung von Automatisierungsvorhaben mit SIMATIC STEP 7 im GMP-pflichtigen Umfeld auf.

Erforderliche Grundkenntnisse Zum Verständnis dieses Handbuches sind Grundkenntnisse von SIMATIC STEP 7 SIMATIC S7 erforderlich. Ebenfalls von Vorteil sind GMP-Kenntnisse aus dem Bereich der pharmazeutischen Industrie.

Haftungsausschluss

Dieses Handbuch ist eine Anleitung für Systembetreiber und Programmierer zur Integration von SIMATIC S7 speicherprogrammierbaren Steuerungen (SPS) und Programmiergeräten in das GMP-Umfeld in Bezug auf die Validierung auch unter Berücksichtigung besonderer Aspekte wie der des 21 CFR Part 11 (CFR – Code of Federal Regulations).

Wir haben den Inhalt der Druckschrift auf Übereinstimmung mit der beschriebenen Hard- und Software geprüft. Dennoch können Abweichungen nicht ausgeschlossen werden, so dass wir für die vollständige Übereinstimmung keine Gewähr übernehmen. Die Angaben in dieser Druckschrift werden regelmäßig auf Systemänderungen bzw. Änderungen regulatorischer Grundlagen der verschiedenen Behörden und Organisationen überprüft, und notwendige Korrekturen werden in Neuauflagen integriert. Für Verbesserungsvorschläge, die an das Competence Center Pharma in Karlsruhe (Deutschland) gerichtet werden können, sind wir dankbar.

Einleitung

Leitfaden zur Durchführung von Automatisierungsprojekten im GMP Umfeld iv A5E01100598-01

Gültigkeitsbereich des Handbuchs Die Informationen die in diesem Handbuch beschrieben sind, sind für die Hardware SIMATIC S7 300/400 und die Engineering Software SIMATIC STEP 7 V5.4 + SP1gültig. Die untersuchten Komponenten sind SIMATIC STEP 7 in Kombination mit den Optionen SIMATIC Logon, SIMATIC Version Trail, und SIMATIC Version Cross Checker. Informationen bzgl. der genauen Kompatibilität zwischen den einzelnen Komponenten mit SIMATIC STEP 7 V5.4 sind in der STEP 7 - Verträglichkeitsliste dokumentiert und wird bei der Installation von STEP7 im Verzeichnis x:\...Files\Siemens\Information\Deutsch abgelegt bzw. unter http://support.automation.siemens.com/ unter der Beitrags-ID 18734363 zu entnehmen. Der CD-ROM Katalog ist im Internet unter www.siemens.com/automation/ca01 bestellbar. Der Online-Katalog ist im Internet unter https://mall.automation.siemens.com/ zu finden.

Einordnung in die Informationslandschaft Die Systemdokumentation der speicherprogrammierbaren Steuerungen und die Engineering Software SIMATIC STEP sind integrale Bestandteile einer SIMATIC STEP 7 Systemsoftware. Sie steht jedem Anwender als Online-Hilfe (HTML Help) bzw. als elektronische Dokumentation im Acrobat Reader Format (PDF) zur Verfügung:

• Elektronische Handbücher SIMATIC S7/STEP 7 V5.4

Die Elektronischen Handbücher zu SIMATIC finden Sie im Internet unter https://support.automation.siemens.com/ oder auf der „SIMATIC MANUAL COLLECTION“ AUF DVD MLFB 6ES7998-8XC01-8YE0.

Aufbau des Leitfadens Das vorliegende Handbuch ist eine Ergänzung zu den bestehenden SIMATIC S7/STEP 7 Handbüchern. Der Leitfaden hilft nicht nur bei der Projektierung, vielmehr soll er einen Überblick über Voraussetzungen für die Projektierung sowie die Anforderungen an Automatisierungssysteme im GMP-Umfeld geben.

Es werden Gesetze und Richtlinien, Empfehlungen sowie notwendige Spezifikationen erläutert, die die Grundlagen für die Projektierung von Automatisierungssystemen darstellen.

Zusätzlich werden alle notwendigen Funktionen und Anforderungen an Hardware- und Softwarekomponenten beschrieben, wodurch die Auswahl an einzusetzenden Komponenten erleichtert werden soll.

Beispielhaft wird erläutert wie Hardware und Software in Bezug auf die Anforderungen angewandt und konfiguriert bzw. programmiert werden. Darüber hinausgehende Erläuterungen können der Standarddokumentation entnommen werden.

Im Anhang des Handbuches finden Sie ein Indexverzeichnis.

Konventionen Folgende Festlegungen wurden in diesem Handbuch getroffen.

Handlungsanweisungen, die mehrere Schritte mit einer bestimmten Reihenfolge umfassen, sind nummeriert.

Handlungsanweisungen, die wenige Schritte umfassen, sind mit einem Punkt (•) dargestellt.

Verweise auf weiterführende Handbücher sind kursiv und fett dargestellt.

Menübefehle sind fett dargestellt

Einleitung

Leitfaden zur Durchführung von Automatisierungsprojekten im GMP Umfeld A5E01100598-01 v

Weitere Unterstützung Bei Fragen zur Nutzung der im Handbuch beschriebenen Produkte, die Sie hier nicht beantwortet finden, wenden Sie sich bitte an Ihren Siemens-Ansprechpartner in den für Sie zuständigen Vertretungen und Geschäftsstellen.

Ihren Ansprechpartner finden Sie unter:

http://www.siemens.com/automation/partner

Den Wegweiser zum Angebot an technischen Dokumentationen für die einzelnen SIMATIC Produkte und Systeme finden Sie unter:

http://www.siemens.de/simatic-tech-doku-portal

Den Online-Katalog und das Online-Bestellsystem finden Sie unter:

http://mall.automation.siemens.com/

Bei Fragen zum Handbuch, wenden Sie sich bitte an das Competence Center Pharma:

Email: [email protected]

Fax: +49 721 595 6390

Weitere Information über das Angebot von Siemens für die Pharmaindustrie, finden Sie unter:

http://www.siemens.com/pharma

Trainingscenter Um Ihnen den Einstieg in das Bedien- und Beobachtungssystem SIMATIC S7 und SIMATIC STEP 7 zu erleichtern, bieten wir entsprechende Kurse an. Wenden Sie sich bitte an Ihr regionales Trainingscenter oder an das zentrale Trainingscenter in D 90327 Nürnberg. Telefon: +49 (911) 895-3200. Internet: http://www.sitrain.com

Technical Support Sie erreichen den Technical Support für alle A&D-Produkte

• Über das Web-Formular für den Support Request http://www.siemens.de/automation/support-request

• Telefon: + 49 180 5050 222

• Fax: + 49 180 5050 223

Weitere Informationen zu unserem Technical Support finden Sie im Internet unter http://www.siemens.de/automation/service

Einleitung

Leitfaden zur Durchführung von Automatisierungsprojekten im GMP Umfeld vi A5E01100598-01

Service & Support im Internet Zusätzlich zu unserem Dokumentations-Angebot bieten wir Ihnen im Internet unser Know-how an. http://www.siemens.com/automation/service&support

Dort finden Sie:

• den Newsletter, der Sie ständig mit den aktuellsten Informationen zu Ihren Produkten versorgt.

• die für Sie richtigen Dokumente über unsere Suche in Service & Support.

• ein Forum, in welchem Anwender und Spezialisten weltweit Erfahrungen austauschen.

• Ihren Ansprechpartner für Automation & Drives vor Ort.

• Informationen über Vor-Ort Service, Reparaturen, Ersatzteile. Vieles mehr steht für Sie unter dem Begriff "Leistungen“ bereit.

Leitfaden zur Durchführung von Automatisierungsprojekten im GMP Umfeld A5E01100598-01 vii

Inhaltsverzeichnis

Einleitung 1 Inhaltsverzeichnis vii 1 Voraussetzung für die Projektierung von Automatisierte Systemen im GMP-Umfeld 1-1

1.1 Lebenszyklusmodell ...............................................................................................1-1 1.2 Gesetze und Richtlinien..........................................................................................1-7 1.3 Verantwortlichkeiten................................................................................................1-9 1.4 Genehmigung und Änderungsverfahren ................................................................1-9 1.5 Software-Kategorisierung von Leitsystemen ........................................................1-10

2 Anforderungen an automatisierte Systeme im GMP-Umfeld 2-1 2.1 Hardware-Kategorisierung......................................................................................2-2 2.2 Software-Kategorisierung .......................................................................................2-3 2.3 Konfigurationsmanagement....................................................................................2-5 2.3.1 Konfigurationskennzeichnung.................................................................................2-6 2.3.2 Konfigurationskontrolle ...........................................................................................2-6 2.3.2.1 Versionskontrolle ....................................................................................................2-6 2.3.2.2 Änderungslenkung (Change control) ......................................................................2-6 2.4 Software-Erstellung.................................................................................................2-7 2.4.1 Verwendung von Typicals zur Programmierung.....................................................2-7 2.4.2 Kennung von Software-Modulen / Typicals ............................................................2-7 2.4.3 Änderung von Software-Modulen / Typicals...........................................................2-7 2.5 Zugriffsschutz und Benutzerverwaltung .................................................................2-8 2.5.1 Anwendung des Zugriffsschutzes auf ein System..................................................2-8 2.5.2 Anforderungen an die Benutzer-ID und Passwort ..................................................2-9 2.5.3 Chipkarten und biometrische Systeme...................................................................2-9 2.6 Elektronische Unterschriften.................................................................................2-10 2.6.1 Konventionelle elektronische Unterschriften ........................................................2-10 2.6.2 Elektronische Unterschriften auf biometrischer Basis ..........................................2-11 2.6.3 Sicherheitsmassnahmen zu Benutzer-IDs/Passwörtern ......................................2-11 2.7 Audit-Trail..............................................................................................................2-12 2.8 Uhrzeitsynchronisation .........................................................................................2-13 2.9 Datensicherung (Backup) .....................................................................................2-14 2.9.1 Anwendersoftware ................................................................................................2-15 2.9.2 Prozessdaten ........................................................................................................2-16 2.10 Rücklesen von ausgelagerten Daten....................................................................2-17 2.11 Einsatz von Fremdkomponenten..........................................................................2-17

3 Systemspezifikation 3-1 3.1 Dimensionierung der Hardware ..............................................................................3-2 3.2 Auswahlkriterien an Hardware................................................................................3-3 3.3 Erforderliche / optionale Software-Pakete ..............................................................3-5 3.3.1 Basis Software Engineering....................................................................................3-5 3.3.2 Zusatz Software Engineering..................................................................................3-5 3.3.3 Zusatzsoftware-Pakete zur Unterstützung der GMP-Konformität ..........................3-8 3.3.3.1 Zugriffschutz ...........................................................................................................3-8 3.3.3.2 Versionierung, Änderungslenkung (Change Control) , Audit Trail .........................3-9

Inhaltsverzeichnis

Leitfaden zur Durchführung von Automatisierungsprojekten im GMP Umfeld viii A5E01100598-01

4 Leitfaden für die Implementierung von SIMATIC S7 im GMP Umfeld 4-1 4.1 Einleitung ................................................................................................................4-1 4.2 Software-Kategorisierung von STEP 7...................................................................4-2 4.3 Software-Installation ...............................................................................................4-3 4.4 Grundlagen zur Projektierung.................................................................................4-4 4.4.1 Software-Erstellung.................................................................................................4-4 4.4.1.1 Vorgehensweise bei der Programmierung .............................................................4-5 4.4.1.2 Regeln und Konventionen ......................................................................................4-9 4.4.1.3 Software-Verriegelungen/Sicherheit .....................................................................4-10 4.4.2 Integriertes HMI-System .......................................................................................4-11 4.4.3 Software-Dokumentation ......................................................................................4-13 4.5 Konfigurationsmanagement..................................................................................4-18 4.5.1 Änderung der Systemsoftware .............................................................................4-18 4.5.2 Austausch / Änderung der Hardware / Firmware .................................................4-20 4.5.3 Versionierung der Anwendersoftware ..................................................................4-22 4.5.4 Änderungslenkung (Change Control) ...................................................................4-26 4.6 Zugriffsschutz........................................................................................................4-30 4.6.1 Zugriffsschutz auf die CPU ...................................................................................4-30 4.6.2 Zugriffsschutz auf STEP 7-Projekt........................................................................4-31 4.6.3 Schutzmaßnahmen in der Software .....................................................................4-33 4.7 Audit Trail..............................................................................................................4-36 4.8 Uhrzeitsynchronisation .........................................................................................4-37 4.9 Zeitstempelung .....................................................................................................4-39 4.10 CPU Speicherung .................................................................................................4-41 4.10.1 Speicherkonzept bei S7-300 CPUs ......................................................................4-41 4.10.2 Speicherkonzept bei S7-400 CPUs ......................................................................4-42 4.11 Sicherung / Wiederherstellung der System/Anwendersoftware ...........................4-43

5 Ergänzende Software-Komponenten 5-1 5.1 Diagnostic Tools .....................................................................................................5-1 5.2 Simulationstools......................................................................................................5-5 5.3 Simulationssoftware SIMIT .....................................................................................5-6 5.4 Umverdrahtung von S7-Programmen.....................................................................5-7

6 Unterstützende Funktionen bei der Qualifizierung 6-1 6.1 Einleitung ................................................................................................................6-1 6.2 Qualifizierung von Automatisierungshardware .......................................................6-2 6.3 Qualifizierung von Automatisierungssoftware ........................................................6-4 6.3.1 Qualifizierung von Standard Software ....................................................................6-4 6.3.2 Installierte SIMATIC-Software STEP 7...................................................................6-4 6.3.3 Installierte Lizenzen von SIMATIC STEP 7 ............................................................6-5 6.3.4 Qualifizierung der Anwendersoftware.....................................................................6-6

Index Index-1

Leitfaden zur Durchführung von Automatisierungsprojekten im GMP Umfeld A5E01100598-01 1-1

1 Voraussetzung für die Projektierung von Automatisierte Systemen im GMP-Umfeld

Als Voraussetzungen für die Projektierung von Automatisierte Systemen im GMP-Umfeld müssen genehmigte Spezifikationen wie Lasten- und Pflichtenheft vorliegen. Bei der Erstellung dieser Spezifikationen sollten Vorgaben aus Normen, Empfehlungen und Richtlinien beachtet werden. In diesem Kapitel werden die wichtigsten dieser Regularien sowie verschiedene Spezifikationen (URS, FS, DS) aufgeführt.

1.1 Lebenszyklusmodell Die Good Engineering Practice (GEP) ist definiert als die Anwendung einer anerkannten Engineeringmethodik im Rahmen eines definierten Lebenszyklus. Das Ziel liegt in der Bereitstellung einer den Anforderungen angemessenen sowie kostengünstigen Lösung.

Die folgende Abbildung zeigt das im vorliegenden Handbuch verwendete Lebenszyklusmodell. Es orientiert sich an den Empfehlungen des aktuellen GAMP®-Leitfadens zur Validierung computergestützter Systeme. Es beginnt mit der Planungsphase eines Projektes und endet mit der Aufnahme der pharmazeutischen Produktion nach Abschluss von Qualifizierung und Validierung

Voraussetzung für die Projektierung von Automatisierte Systemen im GMP-Umfeld

Leitfaden zur Durchführung von Automatisierungsprojekten im GMP Umfeld 1-2 A5E01100598-01

Legende für das Lebenszyklusmodell

Abkürzung Beschreibung

VP Validierungsplan (Validation Plan1)

QP Qualifizierungsplan (Qualification Plan)

QPP Qualitäts- und Projektplan (Quality and Project Plan)

URS 2 / Anwender-Lastenheft (User Requirement Specification; auch: Anwender-Anforderungsspezifikation)

FS Pflichtenheft (Functional Specification; auch: Anwendungsspezifikation)

DS Designspezifikation / Entwurfsspezifikation (Design Specification)

FAT Factory Acceptance Test

SAT Site Acceptance Test

IQ Installation Qualification

OQ Operational Qualification

PQ Performance Qualification

VR Validierungsbericht (Validation Report)

QR Qualifizierungsbericht (Qualification Report)

1 Im Sinne einer verbesserten Lesbarkeit und Wiedererkennung geprägter Begriffe

wurde in der deutschen Ausgabe auf die konsequente Übersetzung aller Begriffe und Abkürzungen ins Deutsche teilweise verzichtet.

2 Die in GAMP ® 4 verwendeten Begriffe "User Requirement Specification / Anwender-Lastenheft" bzw. "Functional Specification / Pflichtenheft“ entsprechen in Ihrer Begriffdefinition nicht der Bedeutung der deutschsprachigen Begriffe "Lastenheft" bzw. "Pflichtenheft" wie sie z.B. VDI 3694 und VDI 2519 verwendet werden.



Validierungsplan Im Validierungsplan (Validation Plan – VP) werden die übergeordnete Strategie sowie die für die Validierung eines Systems in seiner betrieblichen Umgebung verantwortlichen Parteien festgelegt [PDA, GAMP®4].

• Im Falle komplexer Anlagen (bspw. Produktionslinie mit mehreren verfahrens-technischen Anlagen und Automatisierungssystemen) kann zusätzlich zwischen einem übergeordneten Masterdokument (Validierungsmasterplan, auch VMP oder MVP) und einem für Einzelanlagen und –Systeme gültigen VP unterschieden werden.

• Siehe auch GAMP®4, Anhang M1 "Richtlinie für Validierungsplanung".

Qualitäts- und Projektplan Der Qualitäts- und Projektplan (Quality and Project Plan – QPP) definiert den Rahmen und Vorgehensweisen für das Projekt- und Qualitätsmanagement. Es werden z.B. Verfahren zur Dokumentenkontrolle, Änderungskontrollverfahren etc. festgelegt. Im QPP wird der Lebenszyklus dergestalt definiert, dass er nicht nur validierungsrelevante Projektphasen sondern auch andere organisatorische Zusammenhänge (bspw. unterschiedliche Zeitpläne der verschiedenen Gewerke) integriert.

Eine Kombination des QPP mit dem QP ist wegen der ähnlichen Struktur und Inhalte möglich.

• Siehe auch GAMP®4, Anhang M6 "Richtlinie für Qualitäts- und Projektplanung".

Qualifizierungsplan Ein Qualifizierungsplan (Qualification Plan – QP) beschreibt im Gegensatz zum Validierungsplan die durchzuführenden Qualifizierungsmaßnahmen im Detail. Er definiert die durchzuführenden Tests und zeigt Abhängigkeiten auf.

Der Qualifizierungsplan ist einem Validierungsplan nachgeschaltet. Auf Grund der ähnlichen Inhalte beider Dokumente ist die Kombination von QP mit dem QPP möglich.

Spezifikation: Die Spezifikationsphase beginnt mit der Erstellung des Anwender-Lastenheftes. Das Anwender-Lastenheft wird in der Regel vom Betreiber erstellt und beschreibt die Anforderungen, die das System erfüllen soll. Im Anschluss an das Anwender-Lastenheft wird ein Pflichtenheft, im Regelfall durch den Lieferanten, erstellt. Im Pflichtenheft (auch Funktionsspezifikation – FS) werden die durch die URS definierten Anforderungen auf funktionaler Ebene präzisiert. Anschließend erfolgt in der Designspezifikation (DS) die detaillierte Vorgabe für die Implementierung.



Die Funktions - und Designspezifikationen bilden gleichzeitig die Grundlage für spätere Tests im Rahmen der Qualifizierung bzw. Validierung. In den Funktions- und Designspezifikationsphasen müssen auch folgende Punkte festgelegt werden:

• Softwarestruktur

• Programmierstandards

• Namenskonvention

• Dateibenennungskonvention

Anwender-Lastenheft (URS) Das Anwender-Lastenheft beschreibt die Anforderungen die das System aus Sicht des Betreibers erfüllen soll. Das Anwender-Lastenheft wird in der Regel vom Systembetreiber erstellt, die Erstellung kann allerdings auch durch den Systemlieferanten unterstützt werden. Es stellt die Grundlage für alle folgenden Spezifikationen dar.

• Siehe auch GAMP®4, Anhang D1 "Beispiel-Vorgehensweise für die Erstellung eines Anwender-Lastenheftes (Anwender-Anforderungsspezifikation) ".

Pflichtenheft (FS) Das Pflichtenheft wird in der Regel vom Systemlieferanten, teilweise in Kooperation mit dem Endkunden, erstellt. Es beschreibt in Anlehnung an das Anwender-Lastenheft detailliert die Funktionen des Systems. Das genehmigte Pflichtenheft ist als Basis für die Erstellung der Detailspezifikationen.

• Siehe auch GAMP®4, Anhang D2 "Beispiel-Vorgehensweise für die Erstellung eines Pflichtenhefts (Anwendungsspezifikation)".

Entwurfsspezifikation (DS) Die Entwurfspezifikation (Design Specification – DS) wird i.d.R. vom Systemlieferanten erstellt. Sie basiert auf dem Pflichtenheft und ergänzt dieses durch detaillierte Beschreibungen von z.B. einzusetzender Hardware, einzusetzender Software, Messstellenlisten usw.

• Siehe auch GAMP®4, Anhang D3 "Beispiel-Vorgehensweise für die Erstellung einer Hardware-Entwurfsspezifikation" und GAMP®4, Anhang D4 "Beispiel-Vorgehensweise für die Erstellung von Software-Entwurfsspezifikationen und Softwaremodul-Entwurfsspezifikationen".



Implementierung In der Implementierungsphase wird das System entsprechend der Designspezifikation realisiert. Neben den im QPP definierten Vorgehensweisen und zusätzlichen Richtlinen (bspw. Coding Standards, Naming Conventions, Backup von Daten) nimmt das Änderungsmanagement mit dem Ziel Änderungen und Abweichungen von ursprünglichen Spezifikationen nachvollziehbar zu machen, einen großen Stellenwert ein.

Siehe auch GAMP®4, Anhang M8 "Richtlinie für Projekt-Änderungslenkung (Projekt-Change-Control) "; GAMP®4, Anhang M10 "Richtlinie für Dokumenten-Management".

FAT Nach Beendigung der Implementierungsmaßnahmen wird häufig ein Factory Acceptance Test (FAT) bei dem Lieferanten dokumentiert durchgeführt. Dadurch können eventuelle Fehler in der Programmierung noch vor der Auslieferung entdeckt und behoben werden.

Ziel des FAT ist die Freigabe (Akzeptanz) des Kunden zur Systemauslieferung im jeweils getesteten Zustand.

SAT Der Site Acceptance Test (SAT) zeigt, dass ein automatisiertes System innerhalb seiner Ziel-Betriebsumgebung mit Schnittstellen zu Instrumentierung und Anlagen spezifikationsgerecht arbeitet. Der SAT kann projektspezifisch mit der Inbetriebnahme (und damit der IQ bzw. OQ kombiniert werden.

Testphase / Qualifizierung Nach dem FAT folgt die technische Inbetriebnahme (Inbetriebsetzungsphase). Hier wird das System mit dem erstellten Anwenderprogramm beim Systembetreiber installiert, technisch in Betrieb genommen, getestet und qualifiziert.

Inbetriebnahmephase und Qualifizierungsphasen können nacheinander oder kombiniert erfolgen. Um Zeit und Kosten zu sparen ist es empfehlenswert, die Aktivitäten der Inbetriebnahme und der Qualifizierung aufeinander abzustimmen.

So sollte die Testplanung frühzeitig erstellt werden, um prüfen zu können, ob im Verlauf der Qualifizierung auf die Wiederholung von Tests, die bereits im FAT oder SAT durchgeführt wurden, verzichtet werden kann. In diesem Fall sind werden die dokumentierten FAT / SAT-Tests zu Bestandteilen der Qualifizierungsdokumentation.

Beim Erstellen der Testunterlagen sind Tests und Akzeptanzkriterien verständlich zu beschreiben.

Qualifizierungsbericht Der Qualifizierungsbericht (Qualification Report – QR) fasst in Anlehnung an den Qualifizierungsplan die Testergebnisse der durchgeführten Tests zusammen und bestätigt den erfolgreichen Ablauf der Qualifizierungsphasen.



Validierungsbericht Der Validierungsbericht (Validation Report – VR) fasst die Ergebnisse der einzelnen Validierungsschritte zusammen und bestätigt den validierten Zustand des Systems. Die Erstellung sowohl des Validierungsplans als auch des –Berichts liegt in der Verantwortung des Kunden.

Betrieb • Nach der erfolgreichen Qualifizierung und dem anschließenden Betrieb

(Beginn der Produktion) des Systems ist die Anlage vom Betreiber instand zu halten bzw. zu warten. Dabei sind die Wartungs- und Instandhaltungszyklen sowie die Verfahren zum Betrieblichen Change Control zu definieren und einzuhalten.



1.2 Gesetze und Richtlinien Zur Projektierung von validierungspflichtigen Automatisierten Systemen im GMP-Umfeld sollten die Empfehlungen und Richtlinien verschiedener Organisationen beachtet werden. Diese basieren in der Regel auf allgemeinen Richtlinien wie z.B. dem Title 21 Code of Federal Regulations (21 CFR) der amerikanischen Food and Drug Administration (FDA) oder dem EU-GMP-Leitfaden Annex 11.

Gesetz / Richtlinie

Ersteller / Organisation

Titel Gesetz / Empfehlung

Geltungsbereich

21 CFR Part 11 US FDA Electronic records, electronic signature

21 CFR Part 210 US FDA Current good manufacturing practice in manufacturing, processing, packing, or holding of drugs; General

21 CFR Part 211 US FDA Current good manufacturing practice for finished pharmaceuticals

Gesetz

Hersteller und Importeure von Arzneimitteln für den US-amerikansichen Markt

Annex 11 zum EU-GMP-Leitfaden

European Commission Directorate General III

Computer-aided systems Richtlinie Europa

Annex 18 zum EU-GMP-Leitfaden

European Commission Directorate General III

Good Manufacturing Practice for Active Pharmaceutical Ingredients

Richtlinie Europa

GAMP ® 4 ISPE GAMP ® 4 Leitfaden zur Validierung automatisierter Systeme

Richtlinie Weltweit

NAMUR Empfehlung NE 58

NAMUR Abwicklung von qualifizierungspflichtigen PLT-Projekten

Empfehlung Europa


NAMUR Betreiben und Betreuen validierter Anlagen

Empfehlung Europa


NAMUR Validierungsunterstützung bei Einsatz von Leitsystemen

Empfehlung Europa

Hinweis

Basis für die Grundlage dieses Handbuches sind die Anforderung der GAMP ® 4 und US 21 CFR Part 11.



Code of Federal Regulations Title 21 (21 CFR), Food and Drugs Zu dem Code of Federal Regulations, Title 21 gehören Artikel (Parts), wie z.B. die Parts 11, 210 und 211. Von besonders großer Bedeutung für die Computerisierte Systeme ist Part 11 (kurz: 21 CFR Part 11). Er beschäftigt sich mit elektronischen Aufzeichnungen (Electronic Records) und elektronischen Unterschriften (Electronic Signatures).

Annex 11 zum EU-GMP-Leitfaden Der Annex 11 zum EU-GMP-Leitfaden beschreibt in 19 Punkten die Anforderungen an die Projektierung, den Betrieb bis hin zu Änderungskontrollen von Computersystemen im GMP-Umfeld. Eine Interpretation des Annex 11 ist in Form einer APV-Richtlinie im GAMP ® 4-Leitfaden zur Validierung automatisierter Systeme zu finden.

Annex 18 zum EU-GMP-Leitfaden Der Annex 18 zum EU-GMP-Leitfaden beschäftigt sich mit der guten Herstellungspraxis (GMP) für Wirkstoffe. Er soll als GMP-Anleitung bei der Herstellung von Wirkstoffen im Rahmen eines geeigneten Qualitätsmanagementsystems dienen. Kapitel 5 des Annexes 18 beschäftigt sich mit der Prozessausrüstung und deren Einsatz.

GAMP ®-Leitfaden zur Validierung automatisierter Systeme "GAMP ® 4" Der GAMP ® (Good Automated Manufacturing Practice) Leitfaden zur Validierung automatisierter Systeme wurde als eine Empfehlung für die Lieferanten sowie Anleitungen für die Betreiber automatisierter Systeme in der produzierenden pharmazeutischen Industrie zusammengestellt. Die aktuelle Version "GAMP ® 4“ wurde im Dezember 2001 veröffentlicht.

NAMUR Empfehlungen Die NAMUR Empfehlungen sind Erfahrungsberichte, die von der “Interessenge-meinschaft Prozessleittechnik der chemischen und pharmazeutischen Industrie“ für ihre Mitglieder zur wahlfreien Benutzung erarbeitet wurden. Sie sind nicht als Normen oder Richtlinien anzusehen. Folgende NAMUR Empfehlungen sind für die Projektierung und den Einsatz von Automatisierte Systeme im GMP-Umfeld besonders interessant:

• NE 58 "Abwicklung von qualifizierungspflichtigen PLT-Projekten"

• NE 71 "Betreiben und Betreuen validierter Anlagen"

• NE 72 "Validierungsunterstützung bei Einsatz von Leitsystemen"



1.3 Verantwortlichkeiten Beim Projektieren von Automatisierten Systemen im GMP-Umfeld und der Erstellung der entsprechenden Spezifikationen sind die Verantwortlichkeiten für die Aktivitäten der einzelnen Lebenszyklusphasen festzulegen. Da diese Festlegung meist kunden- und projektspezifisch erfolgt und der vertraglichen Vereinbarung bedarf, wird deren Festlegung im Qualitäts- und Projektplan empfohlen. Siehe auch GAMP®4, Anhang M2.

1.4 Genehmigung und Änderungsverfahren Bei der Errichtung neuer validierungspflichtiger Systeme oder der Änderung von im Betrieb befindlichen validierungspflichtigen Systemen gilt oberste Priorität der Erreichung bzw. dem Erhalt des validierten Zustands.

Neuerrichtung von Systemen Im Fall der Neuerrichtung eines Systems wird die Genehmigung von Dokumenten sowie der Übergang zwischen Lebenszyklusphasen vor Projektbeginn festgelegt. Dies geschieht meist gemeinsam mit der Definition der Verantwortlichkeiten im Qualitäts- und Projektplan. Es wird ein Lebenszyklus angewendet wie in Kapitel 1.1 "Lebenszyklusmodell" beschrieben angewendet.

Veränderung validierter Systeme Veränderungen eines existierenden und im validierten Status befindlichen Systems sind durch das betriebliche Change Control geregelt. Änderungen sind vor der Durchführung zu beschreiben, potentielle Auswirkungen zu identifizieren und begleitende Maßnahmen (bspw. Durchführung von Tests, Aktualisierung der As-Built-Dokumentation) zu definieren. Nach anschließender Genehmigung werden sowohl die geplante Änderung als auch die definierten Maßnahmen durchgeführt.

Bei umfangreichen Änderungen kann bei Bedarf auch ein Lebenszyklus analog dem in diesem Handbuch gezeigten, angewendet werden.



1.5 Software-Kategorisierung von Leitsystemen Wie in Kapitel 2.2 "Software-Kategorisierung" und Kapitel 4.2 "Software-Kategorisierung von STEP 7" beschrieben kann die Software eines Systems nach dem GAMP ® 4-Leitfaden zur Validierung automatisierter Systeme in fünf Software-Kategorien eingestuft werden. Die Software-Kategorien beeinflussen den Aufwand während der Test und Qualifizierungsphase erheblich und sollten während der Spezifikationsphase für die eingesetzte Software ermittelt werden.


2 Anforderungen an automatisierte Systeme im GMP-Umfeld

In Bezug auf den Einsatz von automatisierten Systemen in diesem Kaptitel sind die wesentlichen Anforderungen, die ein automatisiertes System im GMP-Umfeld erfüllen muss, aufgeführt. Diese Anforderungen sind in der Spezifikation festzuhalten und während der Projektierung umzusetzen. Im Allgemeinen ist immer festzuhalten, dass zu jeder Zeit der sichere Nachweis erbracht werden muss, wer, zu welchem Zeitpunkt, was geändert bzw. durchgeführt hat (das "Warum" ist optional). Die Anforderungen an diese Aufgabe werden in verschiedenen Funktionen umgesetzt und sind in den nachfolgenden Kapiteln beschrieben.

Die folgende Grafik zeigt das Lebenszyklusmodell. Die Anforderungen, die in diesem Kapitel im Fokus stehen, werden dem Bereich Spezifikation in der Grafik zugeordnet.

Anforderungen an automatisierte Systeme im GMP-Umfeld


2.1 Hardware-Kategorisierung Nach dem GAMP ® 4 Leitfaden, Anhang M4, werden Hardware-Komponenten eines Systems in zwei Hardware-Kategorien unterschieden. Nachfolgend werden die Hardware-Kategorien aufgeführt:

Kategorie 1, Standard-Hardware Unter die Kategorie 1 Standard-Hardware fallen etablierte, kommerziell verfügbare Hardware-Komponenten. Auch diese Hardware muss einschlägigen Qualitäts- und Prüfungsmechanismen unterliegen.

Die Hardware wird durch IQ-Test aufgenommen und dokumentiert.

Kategorie 2, Anwendungsspezifische (zugeschnittene) Hardware Ihre Funktionalität muss spezifiziert und im Einzelnen durch geeignete, dokumentierte Tests überprüft und dokumentiert werden.



2.2 Software-Kategorisierung Nach dem GAMP ®-Leitfaden zur Validierung automatisierter Systeme werden die Software-Komponenten eines Systems in 5 Software-Kategorien eingestuft. Nachfolgend aufgeführt sind die fünf GAMP ®-Software-Kategorien:

Kategorie 1, Betriebssysteme Unter die Kategorie 1 Betriebssysteme fallen etablierte, kommerziell verfügbare Betriebssysteme. Diese unterliegen selber keiner eigenen Validierung, der Name und die Version des Betriebssystems sind allerdings zu dokumentieren und im Rahmen der Installationsqualifizierung (IQ) zu überprüfen.

Kategorie 2, Firmware Zur Kategorie 2 zählt die Firmware in bspw. Fedlinstrumenten oder Kompaktsteuerungen, deren Konfiguration z.B. den Vorortbedingungen angepasst wurde. Auch hier ist wieder der Name und die Version der Firmware sowie deren Konfiguration zu dokumentieren und im Rahmen einer Installationsqualifizierung (IQ) zu überprüfen. Die Funktionalität des Gerätes ist in einer Funktionsqualifizierung (OQ) zu überprüfen.

Kategorie 3, Standard-Softwarepakete Zur Kategorie 3 gehören kommerziell verfügbare Standard-Softwarepakete, sowie Standardlösungen für bestimmte Prozesse. Die Konfiguration dieser Softwarepakete sollte auf die Anpassung der Laufzeitumgebung (z.B. Netz- und Druckeranbindungen) sowie die Konfiguration der Prozessparameter beschränkt werden. Es ist der Name und die Version des Standard-Softwarepaketes zu dokumentieren und in einer Installationsqualifizierung (IQ) zu überprüfen. Anwenderanforderungen (wie z.B. Zugriffsschutz, Alarme, Meldungen oder Berechnungen) sind zu dokumentieren und im Rahmen der Funktionsqualifizierung (OQ) zu überprüfen.

Kategorie 4, Konfigurierbare Softwarepakete Zur Kategorie 4 gehören konfigurierbare Softwarepakete, die spezielle Geschäfts- und Herstellungsprozesse ermöglichen. Hierzu sind vorkonfektionierte Software-Module zu konfigurieren. Diese Softwarepakete sollten nur als Kategorie 4 betrachtet werden, wenn sie gut bekannt und ausgereift sind, ansonsten ist Kategorie 5 besser geeignet. Im Falle kritischer und / oder komplexer Anwendungen ist ein Lieferantenaudit üblich

Der Name, die Version und die Konfiguration sind zu dokumentieren und in einer Installationsqualifizierung (IQ) zu überprüfen. Die Funktionen der Softwarepakete sind gegen die Anwenderanforderungen in einer Funktionsqualifizierung (OQ) zu überprüfen. Der Validierungsplan sollte das Lebenszyklus-Modell sowie eine Bewertung von Lieferanten und Softwarepaketen berücksichtigen.



Kategorie 5 Anwenderspezifische (zugeschnittene) Software Zur Kategorie 5 zählt anwenderspezifische Software, die für spezielle Bedürfnisse der Anwenderfirma entwickelt wurde.

Als Nachweis geeigneter Qualitätssysteme zur Kontrolle der Entwicklung und der nachfolgenden Pflege ist normalerweise ein Lieferantenaudit erforderlich. Anderenfalls sollten die Lieferanten den GAMP ® 4 Leitfaden als Grundlage für einen eigenen Entwicklungslebenszyklus verwenden.

Wiederum sind der Name, die Version und die Konfiguration zu dokumentieren und in einer Installationsqualifizierung (IQ) zu überprüfen. Es ist eine detaillierte Software-Spezifikation zu erstellen und die Funktion der Software ist in einer Funktionsqualifizierung (OQ) zu überprüfen. Der Validierungsplan sollte einen vollständigen Lebenszyklusansatz für die Validierung festlegen.

Der Testaufwand ist bei Einsatz von Software hoher Kategorien wesentlich höher als bei Software niederer Kategorien.

Den Aufwand für die Validierung und das Testen kann durch möglichst umfangreichen Einsatz standardisierter Software reduziert werden.

SoftwareKategorie1 2 3 4 5



2.3 Konfigurationsmanagement Nach dem GAMP ® 4-Leitfaden, ist das Konfigurationsmanagement definiert als die Tätigkeit, die notwendig ist, um ein automatisiertes System an jedem Punkt seines Lebenszyklus, von den ersten Schritten der Entwicklung bis zur Außerbetriebsetzung exakt zu definieren.

Das Konfigurationsmanagement besteht aus der Anwendung administrativer und technischer Vorgehensweisen um:

• Systemkomponenten zu kennzeichnen, zu definieren und grundsätzlich zu spezifizieren

• Änderungen und Freigaben von Elementen zu kontrollieren

• Den Status und Modifikationen der Elemente aufzuzeichnen und zu berichten

• Vollständigkeit, Konsistenz und Korrektheit der Elemente sicherzustellen

• Lagerung, Behandlung und Lieferung der Elemente zu kontrollieren“.

Das Konfigurationsmanagement besteht aus folgenden Tätigkeiten:

• Konfigurationskennzeichnung (WAS unter Kontrolle zu halten ist)

• Konfigurationskontrolle (wie die Kontrolle durchgeführt wird)

• Konfigurationsstatusbericht (wie die Kontrolle dokumentiert wird)

• Konfigurationsbeurteilung (wie die Kontrolle verifiziert wird).

In diesem Kapitel, werden die Tätigkeiten Konfigurationskennzeichnung und Konfigurationskontrolle behandelt.



2.3.1 Konfigurationskennzeichnung Versions- und Änderungsmanagement ist nur mit einer angemessenen Projektierungsumgebung sinnvoll. Jedes Software- und Hardware-Paket ist deshalb mit einer eindeutigen Produktbezeichnung (MLFB-Nummer) und einer Versionsnummer gekennzeichnet. Für die Anwendersoftware sollte eindeutig festgelegt werden welche Teile eines automatisierten Systems dem Konfigurationsmanagement unterliegen. Zu diesem Zweck sollte das System in Konfigurationselemente untergliedert werden. Diese sollten in einer frühen Phase der Implementierung so definiert werden, dass eine komplette Liste von Konfigurationselementen erstellt und gepflegt werden kann. Die applikationsspezifischen Elemente sollen eine eindeutige Kennzeichnung (Name oder Identifizierungsnummer) haben. Die Detailtiefe für die Festlegung der Elemente sollte durch den Bedarf des Systems und des Lieferanten, der die Applikation entwickelt, bestimmt werden.

2.3.2 Konfigurationskontrolle Die Pflege der Konfigurationselemente ist in regelmäßigen Abständen z.B. durch Reviews zu überprüfen. Hierbei ist insbesondere die Änderungskontrolle und damit verbunden die Versionskontrolle zu beachten. Des Weiteren sollte die Archivierung sowie die Freigabe der einzelnen Konfigurationselemente beachtet werden.

2.3.2.1 Versionskontrolle Zur Gewährleistung eines korrekten Änderungsmanagements sind die Konfigurationselemente zu versionieren. Die Version ist bei jeder Änderung zu aktualisieren.

2.3.2.2 Änderungslenkung (Change control) Während der Projektierung müssen geeignete Kontrollmechanismen greifen, die Änderungen dokumentieren um Transparenz herzustellen. Die Kontrollmechanismen können durch SOPs beschrieben werden und sollten im Einzelnen folgende Punkte beinhalten.

• Software-Versionierung

• Vorgaben wie Programmierrichtlinien, Namenskonventionen etc.

• Gewährleistung der Nachvollziehbarkeit von Programmcode-Änderungen

• Eindeutige Kennzeichnung der Software und aller darin enthaltenen Komponenten



2.4 Software-Erstellung Im Rahmen der Software-Erstellung sollten Richtlinien eingehalten werden, die im Qualitäts- und Projektplan zu dokumentieren sind (GEP-Gedanke). Richtlinien zur Software-Erstellung können dem GAMP ® 4-Leitfaden zur Validierung automatisierter Systeme und einschlägigen Normen und Empfehlungen entnommen werden.

2.4.1 Verwendung von Typicals zur Programmierung Wie in Kapitel 2.2 "Software-Kategorisierung" zu sehen ist, steigt der Validierungsaufwand mit den einzelnen GAMP ®-Software-Kategorien enorm an. Während sich der Validierungsaufwand bei Software der Kategorie 1 lediglich auf die Überprüfung von Software-Namen und Version beschränkt, beläuft sich der Aufwand für die Validierung von Software der Kategorie 5 auf die Überprüfung des kompletten Funktionsumfanges sowie ein Lieferantenaudit.

Um den Validierungsaufwand so gering wie möglich zu halten, sind aus diesem Grund bei der Projektierung standardisierte Funktionsbausteine zu verwenden (Produkte, Hausstandards, Projektstandards). Aus Standardfunktionsbausteinen werden anwendergerechte Typicals nach Designvorgaben erstellt und getestet.

2.4.2 Kennung von Software-Modulen / Typicals Bei der Software-Erstellung sollten die einzelnen Software-Module eindeutig mit Name, Version und einer Kurzbeschreibung des entsprechenden Bausteins versehen werden. Die Änderung von Software-Modulen sollte bei der Kennung berücksichtigt werden.

2.4.3 Änderung von Software-Modulen / Typicals Die Änderungen an Software-Modulen sollte in der Kennung des entsprechenden Moduls vermerkt werden. Neben der Erhöhung der Versionskennung sollten auch das Datum und der Name des Ändernden in die Kennung der Software-Module mit aufgenommen werden. Die zu ändernden Softwaremodulen sind ggf. durch Kommentare mit Verweis auf den zugehörigen Änderungsantrag / -auftrag kenntlich zu machen. Siehe hierzu auch Kapitel 4.5.4 "Änderungslenkung (Change Control)".



2.5 Zugriffsschutz und Benutzerverwaltung Um die Sicherheit automatisierter Systeme im GMP-Umfeld gewährleisten zu können, sollten diese Systeme mit einem Zugriffskontrollsystem ausgestattet sein. Zugriffskontrollsysteme bieten zusätzlich zur räumlichen Zugangskontrolle die Möglichkeit Systeme vor unberechtigtem Zugriff zu schützen. Die Benutzer sollten hierbei in Benutzergruppen zusammengefasst werden, über die die Verwaltung der Benutzerrechte erfolgt. Die Zugriffsberechtigung der einzelnen Benutzer kann über verschiedene Möglichkeiten realisiert werden:

• Kombination aus eindeutiger Benutzer-ID und Passwort Projektierungsbeschreibung ist im Kapitel 4.6 "Zugriffsschutz“ beschrieben.

• Chipkarten gemeinsam mit Passwort

• Biometrische Systeme

Um den Zugriffsschutz gewährleisten zu können, ist die Vergabe und Verwaltung der Zugriffsrechte von dem Systemeigner bzw. von einem durch den Betreiber benannten Mitarbeiter (Administrator) zu kontrollieren.

2.5.1 Anwendung des Zugriffsschutzes auf ein System Generell sollten Aktionen, die an einem automatisierten System ausgeführt werden können, geschützt werden. Je nach Aufgabenbereich können dem Benutzer verschiedene Rechte zugewiesen werden. Der Zugriff auf die Benutzeradministration sollte nur dem Systemeigner bzw. einem von ihm bestimmten Mitarbeiter gewährt werden. Weiterhin ist der Zugriff Unberechtigter auf die Aufzeichnung elektronischer Daten unbedingt zu schützen.

Am System sollte eine automatische Logout-Funktion installiert sein. Die Logout-Zeit sollte in Abstimmung mit dem Betreiber definiert und im Pflichtenheft festgehalten werden.

! Hinweis Es ist darauf zu achten, dass der Zugang zu PCs nur für berechtigte Personen möglich ist. Dies kann durch geeignete Mechanismen wie Remote-Kits erzielt werden.



2.5.2 Anforderungen an die Benutzer-ID und Passwort Benutzer-ID:

Die Benutzer-ID eines Systems sollte eine mit dem Kunden festgelegte Mindestlänge besitzen und für das System eindeutig sein.

Passwort:

Ein Passwort sollte generell aus einer Kombination von numerischen und alphanumerischen Zeichen bestehen. Beim Anlegen von Passwörtern sollte eine Mindestanzahl von Zeichen sowie ein Zeitraum bis zum Ablaufen eines Passwortes festgelegt werden. Der Aufbau des Passwortes wird in der Regel kundenspezifisch festgelegt. Projektierungsbeschreibungen werden unter Kapitel 4.6 "Zugriffsschutz" beschrieben.

Kriterien beim Aufbau eines Passwortes sind:

• Mindestlänge des Passwortes

• Verwendung von numerischen und alphanumerischen Zeichen

• Verwendung von Groß- und Kleinbuchstaben

2.5.3 Chipkarten und biometrische Systeme Neben der herkömmlichen Methode der Identifikation über Benutzer-ID und Passwort können sich Benutzer auch mit Chipkarten oder über biometrische Systeme, wie z.B. dem Scannen des Fingerabdruckes, identifizieren.



2.6 Elektronische Unterschriften Elektronische Unterschriften sind computergenerierte Zeichenfolgen, die als rechtlich verbindliches Äquivalent zur handschriftlichen Unterschrift gelten.

Die Vorschriften zum Einsatz von elektronischen Unterschriften sind im 21 CFR Part 11 der FDA festgehalten.

Jede elektronische Unterschrift muss einer Person eindeutig zugeordnet sein und darf von keiner anderen Person verwendet werden.

Einer Behörde muss bestätigt werden können, dass eine elektronische Unterschrift das rechtlich verbindliche Äquivalent zur handschriftlichen Unterschrift des Unterschreibenden darstellt.

Elektronische Unterschriften können sowohl auf biometrischer Basis, als auch ohne biometrische Merkmale aufgebaut sein.

! Hinweis Beim Export von Pharmazeutika in die USA müssen die Vorschriften gemäß 21 CFR Part 11 der FDA beachtet werden.

2.6.1 Konventionelle elektronische Unterschriften Werden elektronische Unterschriften eingesetzt, die nicht auf Biometrie basieren, so sind diese so anzulegen, dass sich der Unterschreibende über mindestens zwei Identifikationskomponenten identifizieren muss. Dies gilt ebenfalls in all den Fällen, in denen eine Chipkarte eine der beiden Identifikationskomponenten ersetzt. Diese Identifikationskomponenten können z.B. aus einer Benutzer-ID und einem Passwort bestehen. Die Identifikationskomponenten sind eindeutig zu vergeben und dürfen nur vom eigentlichen Benutzer verwendet werden.

Wendet der Unterschreibende die elektronische Unterschrift an, so muss er sich mindestens über zwei Identifikationskomponenten identifizieren. Eine Ausnahme ist die mehrfache elektronische Unterschrift während einer ununterbrochenen Sitzung. In diesem Fall muss sich der Unterschreibende nur bei der ersten Unterschrift mit beiden Identifikationskomponenten identifizieren. Ab der zweiten Unterschrift ist es dann ausreichend sich mit mindestens einer eindeutigen Identifikationskomponente (Passwort) zu identifizieren.



2.6.2 Elektronische Unterschriften auf biometrischer Basis Eine auf Biometrie basierende elektronische Unterschrift muss so angelegt sein, dass sie nur von einem Benutzer verwendet werden kann. Wendet der Unterschreibende die elektronische Unterschrift auf biometrischer Basis an, so reicht eine Identifikationskomponente aus.

Mögliche biometrische Erkennungssysteme sind Systeme zur Abtastung eines Fingerabdruckes oder der Iris des Auges.

Hinweis

Der Einsatz von biometrischen Systemen gilt derzeit als sichere Identifikationsmethode. Dennoch stehen dem Einsatz biometrischer Identifikationsmerkmale in der pharmazeutischen Industrie auch Hemmnisse entgegen (bspw. schlechte Gesichtserkennung bedingt durch gesichtsverhüllende Reinraumkleidung, keine Fingerabdruckscans mit Handschuhen, Aufwand und Reaktionszeit von Iris- oder Retinascans).

2.6.3 Sicherheitsmassnahmen zu Benutzer-IDs/Passwörtern Um die Sicherheit der elektronischen Unterschrift bei Verwendung von Benutzer-ID und Passwort gewährleisten zu können, sollten folgende Punkte beachtet werden:

• Einzigartigkeit von Benutzer-ID und Passwort

• Kontrollierte Ausgabe von Benutzer-IDs

• Berechtigungsentzug bei Verlust bzw. bei unsicheren Benutzer-IDs oder kompromittierten Passwörtern

• Über Sicherheitsvorkehrungen den unbefugten Einsatz von Benutzer-IDs / Passwörtern verhindern bzw. diesen bei Missbrauch melden

• Schulungen des Personals mit dokumentiertem Schulungsnachweis



2.7 Audit-Trail Das Audit-Trail ist ein systemseitiger Kontrollmechanismus, der die Nachvoll-ziehbarkeit von Dateneingaben bzw. Datenänderungen sicherstellt. Ein sicheres Audit-Trail ist besonders in Zusammenhang mit der Erstellung, Änderung oder Löschung von GMP-relevanten Electronic Records erforderlich.

Das Audit-Trail muss in diesem Fall sämtliche vorgenommenen Änderungen bzw. Aktionen mit Datum und Uhrzeit archivieren bzw. dokumentieren. Typische Inhalte eines Audit-Trails müssen festgehalten werden und beschreiben die Vorgänge Wer, hat Wann, Was geändert (alter Wert/neuer Wert).

Der Archivierungszeitraum muss dem in der Spezifikation festgelegten entsprechen.

Es ist ausreichende Festplattenkapazität einzurichten, um das komplette Audit-Trail bis zur nächsten Auslagerung auf einen externen Datenträger speichern zu können.

Es sind Systeme einzusetzen, die eine ausreichende Datensicherheit gewährleisten (z. B. redundante Systeme, Standby-Systeme, RAID5).



2.8 Uhrzeitsynchronisation Innerhalb eines Systems muss eine einheitliche Zeitreferenz gewährleistet sein, um die Archivierung von Meldungen, Alarmen etc. mit eindeutigen Zeitstempeln versehen zu können. Eine Uhrzeitsynchronisation auf ein Zeitnormal ist zwar wünschenswert, jedoch nicht zwingend erforderlich. Besonders empfehlenswert ist eine Zeitsynchronisation bei der Archivierung von Daten und die Analyse von Störungen einer Anlage.



2.9 Datensicherung (Backup) Im Gegensatz zur Archivierung von elektronischen Daten dienen Datensicherungen der Erstellung von Sicherungskopien, welche die Wiederherstellung des Systems im Falle eines Verlusts der Originaldaten oder des ganzen Systems sicherstellen.3

Das Backup Verfahren muss die periodische Sicherung von nicht beständiger Information abdecken, um den Totalverlust der Daten durch Defekt von Systemkomponenten oder versehentliches Löschen der Daten zu vermeiden. Backup Verfahren müssen geprüft werden, um die ordnungsgemäße Speicherung der Daten sicherzustellen. Backup Aufzeichnungen sollten klar und verständlich bezeichnet und mit Datum versehen werden.4

Datensicherungen werden auf externen Datenträgern erstellt. Hierbei sollten Datenträger verwendet werden, die den Empfehlungen der Gerätehersteller entsprechen.

Bei der Sicherung von elektronischen Daten wird unterschieden in Software-Sicherungen (z. B. Anwendersoftware, Partitionsimage) und Archiv-datensicherungen.

Ein besonderes Augenmerk liegt hierbei auch auf der Aufbewahrung von Datensicherungsmedien (räumliche Trennung der Kopie vom Original, Schutz vor Magnetfeldern und Elementarschäden).

3 "Good Practice and Compliance for Electronic Records and Signatures. Part 1, Good electronic records management". ISPE/PDA 2001. 4 "Electronic records and electronic signatures assessment". Chris Ride & Barbara Mullendore, PDA 2001.



2.9.1 Anwendersoftware Software-Sicherungen sollten nach jeder Software-Änderung an einem System erstellt werden. Sie müssen den zuletzt gültigen Software-Stand eines Systems dokumentieren. Bei der Modifikation von Software-Teilen ist es ausreichend, wenn der geänderte Teil der Anwendersoftware gesichert wird. Es sollten jedoch in regelmäßigem Abstand komplette Software-Sicherungen erstellt werden. Sind Software-Sicherungen im Zuge einer Software-Änderung an einem vorhandenen System bzw. einer Neuinstallation eines Systems zu erzeugen, so sind diese nach der Installation zu erstellen. Im Projektverlauf sollte der Software-Stand in Verbindung mit definierten Meilensteinen gesichert und dokumentiert werden, so z.B. am Ende des FAT (d.h. vor Auslieferung des Systems), nach Beendigung der Installationsqualifizierung (IQ), als Grundlage für die Tests der Funktionsqualifizierung (OQ) und natürlich bei Übergabe des Systems an den Betreiber.

Software-Stände sollten auch während der Erstellung neuer Software-Versionen in regelmäßigen Abständen in Form von Software-Sicherungen festgehalten werden.

Software-Sicherungen sind von der Applikationssoftware sowie von Konfigurationsparametern zu erstellen.

Beschriftung von Software-Sicherungen Nach dem GAMP ® 4-Leitfaden zur Validierung automatisierter Systeme sollten Software-Sicherungen sowohl auf dem Etikett des Sicherungsmediums, als auch in einem separaten Protokoll mit folgenden Informationen dokumentiert sein:

• Erstelldatum

• Systembezeichnung

• Software-Bezeichnung

• Software- oder Versionsbezeichnung

• Laufende Nummer der Sicherung

• Grund für die Software-Sicherung

• Datum der Erstnutzung

• Datum der Sicherung

• Datum und Unterschrift des Ausführenden

• Identität des Bedieners

Aufbewahrung von Software-Sicherungen Es sollten mindestens die letzten beiden Software-Sicherungen archiviert werden. Diese sollte aus Sicherheitsgründen räumlich vom System getrennt (entsprechend der Empfehlungen des BSI bspw. in einem vom System getrennten Brandabschnitt) aufbewahrt werden.

Eine geeignete Sicherungsstrategie ist abhängig von der Häufigkeit von Änderungen zu definieren.

Der Haltbarkeitszeitraum des Datenträgers sollte definiert werden (bspw. aus Herstellerangaben oder den Schriften des Bundesamt für Sicherheit in der Informationstechnologie, BSI) und vor dessen Ablauf ist die Software-Sicherung in geeigneter Weise zu migrieren, bspw. auf einen neuen Datenträger zu kopieren.



2.9.2 Prozessdaten Die im System gespeicherten Daten, wie z.B. Trends, Messwerte oder Alarme, sollen in periodischen Abständen auf externen Datenträgern gesichert werden. Durch diese Maßnahme kann ein möglicher Datenverlust bei eventuellen Störungen minimiert werden.

Beschriftung von Datensicherungen Nach dem GAMP ® 4-Leitfaden zur Validierung automatisierter Systeme sollten Datensicherungen entweder auf dem Etikett der Sicherung oder in einem separaten Protokoll mit folgenden Informationen dokumentiert sein:

• Systembezeichnungen

• Software-/ Datenbezeichnung

• Version und / oder Software-/ Firmware-Generierungsnummer, falls verfügbar

• Erstelldatum

• Datum der Erstbenutzung

• Laufende Nummer

• Datum der Datensicherung

• Grund der Datensicherung

• Identität des Bedieners

Aufbewahrung von Datensicherungen Es gelten die gleichen Richtlinien wie im gleichnamigen Abschnitt des Kapitels 2.9.1 "Anwendersoftware".

Da Prozessdaten im Gegensatz zu Software üblicherweise nicht überlappend gespeichert werden ist auf geeignete Maßnahmen zur Sicherstellung der Datenintegrität zu achten.



2.10 Rücklesen von ausgelagerten Daten Es muss gewährleistet werden, dass die archivierten Daten zu jedem Zeitpunkt rücklesbar sind. Nach Systemaktualisierungen ist auf eine Kompatibilität der vor der Aktualisierung ausgelagerten Daten zu achten.

2.11 Einsatz von Fremdkomponenten Bei dem Einsatz von zugeschnittenen Fremdkomponenten (Hardware und Software) sollte auf jeden Fall ein Lieferantenaudit durchgeführt werden um den Lieferanten und dessen Qualitätsmanagementsystem zu überprüfen. Die Kompatibilität der Hardware-Komponenten muss bestätigt werden.

Auch beim Einsatz von Standard Hardware- und Softwarekomponenten anderer Hersteller muss die Kompatibilität bestätigt werden.

Hinweis

Hinsichtlich der Auditierung eines Produktlieferanten bietet die NAMUR Empfehlung 72 zahlreiche Hinweise. Ansätze zur Auditierung eines Dienstleisters bzw. Lösungsanbieters finden sich u.a. auch im GAMP ® 4-Leitfaden, Anhang M2.




3 Systemspezifikation

In diesem Kapitel stehen die Auswahlkriterien für Hardware und Software im Fokus. Die Aktivitäten zur Auswahl von Produkten, Produktvarianten und Systemkonstellationen finden in der Spezifikationsphase eines automatisierten Systems statt. Dies wird im nachfolgend dargestellten Lebenszyklusmodell durch die Markierung im linken Bereich veranschaulicht.

Neben technischen Aspekten gelten im GMP-pflichtigen Umfeld zusätzliche Auswahlkriterien für Hard- und Software:

• Unterstützung des Konfigurationsmanagement für Hard- und Software (Versionskontrolle, Änderungslenkung)

• Modularität und

• Skalierbarkeit um den Validierungsaufwand zu minimieren.

Mit dem Konzept Totally Integrated Automation (TIA ) wird angeboten:

• eine gemeinsame Engineering Umgebung auf Kompatibilität getestete Software-Pakete (Versionsverträglichkeit von Windows Betriebssystemen, SIMATIC STEP 7, WinCC, WinCC flexible, Utilities wie z.B. Virenscanner, etc.)

• vorgefertigte Software-Module entsprechen der Software-Kategorie 3

Systemspezifikation


• eine gemeinsame, systemweite Datenhaltung und –basis Variablenabgleich zwischen Steuerung und HMI bei integriertem Betrieb durch das System

• Service und Support über alle Phasen des Anlagen-Lebenszyklus um den validierten Zustand zu erhalten

3.1 Dimensionierung der Hardware Bei der Dimensionierung der Hardware sind sowohl Arbeitsspeichergröße als auch Software-Grenzen wie Alarm-Ressourcen und Laufzeit zu berücksichtigen.

Für die Arbeitsspeichergröße sollte eine Reserve von mindestens 25% nach Abschluss der Inbetriebnahme vorgesehen werden.

Für den Hardware-Ausbau sind Reserven auf den Baugruppenträgern, auf den digitalen und analogen Ein- / Ausgabebaugruppen, ggf. auf weiteren Signalbaugruppen von mindestens 10% einzukalkulieren.

Das Zusammenlegen technologisch zusammengehörender Signale führt zu einer übersichtlichen Hardware-Belegung. Reserven sollten sinnvoll vorgesehen werden.

Systemspezifikation


3.2 Auswahlkriterien an Hardware Für die Automatisierung in prozess- und fertigungstechnischen Branchen werden mit SIMATIC S7 speicherprogrammierbare Steuerungssysteme (SPS) mit einem abgestuften Leistungsspektrum angeboten. Die Auswahl der SPS richtet sich nach den Anforderungen der Automatisierungsaufgabe und den Umgebungsbedingungen.

Zum Anschluss an Netzwerke auf Basis MPI, Profibus DP, PROFINET oder Industrial Ethernet sind die speicherprogrammierbaren Steuerungen SIMATIC S7-300 / S7-400 geeignet. Daher werden nur diese beiden Serien in dem Handbuch betrachtet.

Automatisierungslösungen im unteren und mittleren Leistungsbereich werden mit der modular erweiterbaren SPS SIMATIC S7-300 realisiert. Die leistungsgestuften CPUs reichen von der einfachen Standard-CPU bis hin zur Hochleistungs-CPU mit einer effizienten Verarbeitungsgeschwindigkeit. Aus einem breiten Spektrum an Digital-, Analog-, Funktions- und Kommunikationsbaugruppen wird die erforderliche Hardware ausgewählt. Die kompakte Bauweise eignet sich besonders bei beengten Platzverhältnissen. Das S7-300 Spektrum umfasst auch die Kompaktgeräte C7 (z. B. C7-636 = CPU315-2DP + OP270 / TP270) und die ET200 mit IM-CPU parametriert als S7-300 für kleinste Aufgaben oder als I-Slave mit Back-up Funktionalität. Die Serie SIPLUS S7-300 wurde speziell für den Einsatz unter anspruchsvollen Umgebungsbedingungen z.B. niedrige Umgebungstemperatur (-25°C), aggressive Dämpfe (Chlor / Schwefel) entwickelt.

Für anspruchsvolle, rechenintensive Automatisierungslösungen im mittleren und oberen Leistungsbereich kommt die modular erweiterbare SPS SIMATIC S7-400 mit einer extrem hohen Performance und sehr kurzen Befehlszeiten zum Einsatz. Zusätzlich zu den leistungsgestuften CPUs stehen neben Digital- und Analogbaugruppen auch Funktions- und Kommunikationsbaugruppen für spezielle technologische Aufgaben zur Verfügung. Zur Programmierung können auch Hochsprachen, z. B. SCL, und grafische Engineering Tools verwendet werden.

Weitere Kriterien zur Auswahl des Automatisierungssystems S7-300 oder S7-400 sind Unterschiede in den Funktionalitäten wie z.B.

• Alarmfähigkeit (siehe Kapitel 4.9 „Zeitstempelung“)

• Ziehen / Stecken von Baugruppen während des Betriebs (PROFINET I/O bei S7-300/400 und PROFIBUS DP nur bei S7-400 )

• Redundante Peripheriebaugruppen zum doppelten Auflegen kritischer Signale, nur in Verbindung mit einer H-CPU

• CIR (Configuration change in Run), Erweiterung der HW Konfiguration während Runtime mit S7-400

• Redundante Stromversorgung (nur bei S7-400)

• Taktsynchrone Peripheriebusse gewährleisten Erfassung, Verarbeitung und Datenausgabe zum selben Zeitpunkt, damit Regelungen (z. B. Motoren) genau funktionieren (S7-300 mit CPU319-3 PN/DP, CPU317T, S7-400 ohne CPU41x-4H, PC-based Automation WinAC Slot 412 / 416 und WinAC RTX. Details sind im Handbuch SIMATIC Taktsynchronität dokumentiert.)

• Redundante CPUs

• Peripherie für EX-Bereiche (Gas- und Staub)

Systemspezifikation


• Fehlersichere Baugruppen (CPUs und Peripherie)

• Anzeige und Pflege von I&M-Daten (Identification and Maintenance), siehe Kapitel 4.5.2 „Austausch / Änderung der Hardware / Firmware“

• Uhrzeitsynchronisation / Uhrzeit stellen

• Bei einer Ausdehnung der Automatisierungsaufgabe auf zusätzliche Aspekte wie Datenverarbeitung, Kommunikation und Visualisierung wird der Einsatz eines SIMATIC PCs empfohlen. Ob direkt vor Ort oder zum Einbau in Schaltschränke erfüllen SIMATIC PCs die hohen Anforderungen für eine industrietaugliche Bauweise. SIMATIC PCs sind die ideale Plattform für PC-based Automation in Verbindung mit PC-Technologie. Eine besonders robuste Plattform zur Visualisierung im maschinennahen Bereich bietet das Multipanel SIMATIC MP370 in Verbindung mit SIMATIC Embedded Control, eine Erweiterung zum SIMATIC PC-based Control .

Hinweis

Technische Einzelheiten zu den speicherprogrammierbaren Steuerungssystemen SIMATIC S7-300 / S7-400 und dem Peripheriespektrum sowie zu SIMATIC PCs befinden sich im aktuellen SIMATIC Katalog ST 70.

Systemspezifikation


3.3 Erforderliche / optionale Software-Pakete Als Engineering-Software für die speicherprogrammierbaren Steuerungssysteme SIMATIC S7-300 / S7-400 wird die Basissoftware STEP 7 eingesetzt, für PC-basierte Steuerungen die Software SIMATIC WinAC

3.3.1 Basis Software Engineering Mit der Basissoftware STEP 7 wird die komplette Automatisierungslösung angefangen von der Hardware-Konfiguration, der Kommunikations- und Netzwerkverbindungen bis hin zum Anwenderprogramm durchgeführt. Das Anwenderprogramm wird wahlweise in den Programmiersprachen KOP (Kontaktplan), FUP (Funktionsplan) oder AWL (Anweisungsliste) erstellt. Die integrierte komfortable Syntaxprüfung kontrolliert direkt beim Programmieren den eingegebenen Programmcode. Standardfunktionen, die in Form von Standardfunktionsbausteinen / -funktionen (SFB / SFC) bereits mit der Zentralbaugruppe geliefert werden, vereinfachen und beschleunigen die Programmerstellung. Zusätzlich steht mit der AWL-Quelle die Möglichkeit, das Programm bzw. Teile davon, als AWL-Quelle einzugeben und diese anschließend in Bausteine zu übersetzen. Die Quelle kann den Code für mehrere Bausteine enthalten, die anschließend in einem Lauf als Bausteine übersetzt werden. Die AWL-Quelle ist für die Vergabe des KNOW-HOW-Schutzes erforderlich.

Während der Test- und Inbetriebnahmephase unterstützt die Basissoftware STEP 7 mit komfortablen Beobachtungs-, Steuerungs- und Diagnosefunktionen.

Die Basissoftware STEP 7 wird in den Oberflächensprachen deutsch, englisch, französisch, italienisch und spanisch geliefert.

3.3.2 Zusatz Software Engineering Zur Erweiterung der Basissoftware STEP 7 werden verschiedene Optionen angeboten. Jede der nachfolgend aufgeführten Optionen ist lizenzpflichtig.

• S7-GRAPH: zur Projektierung und Programmierung von sequentiellen Prozessen mit Ablaufketten. Bei Verwendung der Option ProAgent (siehe unten) zur Visualisierung werden für manuelle Bedienungen keine Meldungen erzeugt, die in einem Audit Trail aufgezeichnet werden können. Das Schrittkettenbild sollte nur zur Behebung von Störungen bei S7-GRAPH Ablaufketten eingesetzt werden.

• S7-SCL zur Programmerstellung in einer PASCAL-artigen Hochsprache

• S7-PLCSIM für den funktionellen Test der erstellten Anwenderbausteine unabhängig von der verfügbaren Zielhardware auf dem Engineeringssystem

Systemspezifikation


Die Systemsoftware STEP 7 Professional ist eine Kombination aus der Basissoftware STEP 7 und den Optionen S7-GRAPH, S7-SCL und S7-PLCSIM.

• S7-HiGraph zur grafischen Beschreibung asynchroner Prozesse mit Zustandsgrafen

• CFC umfangreiche Bibliothek vorgefertigter Bausteine die Programmerstellung erfolgt durch Zeichnen eines Technologieplans. CFC (Continuous Function Chart) ist ein grafischer Editor, der auf der Basissoftware STEP 7 aufsetzt. Er dient dazu, aus vorgefertigten Bausteinen eine Gesamt-Software-Struktur für eine CPU zu erstellen. Hierzu werden Bausteine auf Funktionspläne platziert, parametriert und verschaltet. Verschalten bedeutet, dass für die Kommunikation zwischen Bausteinen die Verbindungen hergestellt werden, damit Werte von einem Ausgang zu einem oder mehreren Eingängen übertragen werden können. Prinzipielle Arbeitsweise Im Lieferumfang von CFC ist eine Bausteinbibliothek enthalten. Diese Bausteine können mit eigenen, anwenderspezifisch erstellten Bausteinen erweitert werden. Der CFC-Editor arbeitet mit grafischen Mitteln. Aus dem Bausteinvorrat wird ein Baustein ausgewählt und im Plan, eine Art "Zeichenblatt", platziert. Technologiefunktionen werden durch Verbinden von Funktionsbausteinen (UND, ODER, PID-Regler) nur noch parametriert. Die zeitaufwendige Programmierung ist nicht mehr erforderlich. Details wie Algorithmen oder die Zuteilung von Maschinenressourcen treten in den Hintergrund, dagegen die technologischen Aspekte der Projektierung in den Vordergrund. Beim Transfer der Projektierungsdaten in das Zielsystem werden die Pläne übersetzt und anschließend geladen. Dabei gewährleistet die Option CFC die Konsistenz der Projektierungsdaten beim Änderungsladen. Falls bereits Daten auf dem Automatisierungssystem vorhanden sind, können nur die Änderungen übertragen werden (bei CPU 400). Auch dabei wird die Datenkonsistenz der Projektdaten garantiert. Im Vergleich dazu überträgt die STEP 7 Basissoftware Änderungen bausteinweise in das Zielsystem, die in Runtime sofort aktiv werden. Dadurch entsteht meistens eine Inkonsistenz zwischen FB und seine Instanzen, die beim Laden während Runtime zum Betriebszustand Stopp der CPU führen kann.

• S7-PDIAG zur Projektierung der Prozessdiagnose, erhöht die Verfügbarkeit von Maschinen und Produktionsanlagen

- SIMATIC ProAgent Das Optionspaket SIMATIC ProAgent stellt auf seiten von SIMATIC HMI (WinCC Flex und WinCC) die Anzeige- und Bedienbilder auf Basis einer standardisierten Benutzeroberfläche (für S7-PDIAG und S7-GRAPH einheitlich) zur Verfügung.

Hinweis SIMATIC ProAgent kann nicht mit redundanten WinCC-Servern verwendet werden.

Systemspezifikation


• DOCPRO Mit DOCPRO steht ein Werkzeug zum Erstellen und Verwalten von Anlagendokumentation zur Verfügung. DOCPRO ermöglicht die Strukturierung der Projektdaten, die Aufbereitung in Form von Schaltbüchern und den Ausdruck in einem einheitlichen Druckbild.

• Distributed Safety Zur Erstellung sicherheitsgerichteter Automatisierungsanwendungen mit SIMATIC S7 in F-KOP oder F-FUP mit CPU31xF und CPU416F

• F-Systems (F/FH) Zur Konfiguration eines F-Systems (F/FH) ist das im SIMATIC Manager integrierte Engineeringwerkzeug S7 F Systems verwendbar. Mit diesem Tool lassen sich CPU und F-Signalbaugruppen parametrieren, und fehlersichere Applikationen im CFC erstellen. Hierfür stehen vorgefertigte, vom TÜV abgenommene Bausteine zur Verfügung. Die fehlersicheren Bausteine nehmen dem Anwender die diversitäre Programmierung zur Fehlererkennung und Fehlerreaktion ab. (Einsetzbar mit CPU41x-4H)

- SIMATIC Safety Matrix Die Safety Matrix basiert auf dem bewährten Prinzip einer Causes & Effects-Matrix, mit der man im Verlauf eines Prozesses auftretenden Ereignissen (Causes) exakt definierte Reaktionen (Effects) zuordnen kann. Dies ist Bestandteil der Risikoanalyse einer Anlage. Die Spezifikation des Sicherheitsprogramms entspricht dabei zugleich den Eingabeparametern für die Safety Matrix. Die Safety Matrix generiert anhand dieser Parameter automatisch komplexe fehlersichere CFC-Programme. Gegenüber der herkömmlichen Programmierung lässt sich die Sicherheitslogik so deutlich schneller und mit wesentlich geringerem Aufwand projektieren. Der Programmierer benötigt keine speziellen Programmierkenntnisse und kann sich voll auf die Sicherheitsanforderungen seiner Anlage konzentrieren. Bei Bedarf können auch mehrere Matrizes miteinander verknüpft werden. SIMATIC Safety Matrix Tool für die Projektierung von Sicherheitsfunktionen als CFC-Programm

- SIMATIC Safety Matrix Editor für das Anlegen und Überprüfen der Safety Matrix Logik in einem externen Rechner, unabhängig vom Engineering System; (wahlweise additiv zum SIMATIC Safety Matrix Tool einsetzbar)

- SIMATIC Safety Matrix Viewer zum Bedienen und Beobachten der Safety Matrix über WinCC

• Parametriersoftware für FM-/ CP-Baugruppen (z. Teil lizenzpflichtig)

Systemspezifikation


• Runtime Software

- Standard PID Control Das Softwarepaket Standard PID Control ermöglicht die Integration von kontinuierlichen PID-Reglern, Impulsreglern und Schrittreglern in das Anwenderprogramm. CFC kann nicht für die Verschaltung verwendet werden.

- Modular PID Control Modular PID Control wird bevorzugt bei regelungstechnischen Anwendungen des mittleren und oberen Leistungsbereichs und der Verfahrenstechnik eingesetzt. Modular PID Control ist immer dann gut geeignet, wenn minimaler Speicherplatzbedarf und kürzeste Laufzeiten bei optimaler Anpassung an die Regelungsaufgabe gefordert sind. CFC kann für die Verschaltung verwendet werden.

- PID Self-Tuner Das Softwarepaket „PID Self-Tuner" erweitert vorhandene PID-Regler zu selbsteinstellenden PI- oder PID-Reglern. PID Self-Tuner ist flexibel kombinierbar mit PID Control (in STEP 7 integriert), Standard PID Control, Modular PID Control, FM 355, FM 455, sowie jedem beliebigen PID-Algorithmus

• Software Redundance Mit dem Softwarepaket "Software Redundanz" können hochverfügbare Steuerungen mit Standard-Hardwarekomponenten der S7-300 und S7-400 kostengünstig aufgebaut werden. ALARM_x-Meldungen können nicht verwendet werden.

• SIMATIC iMap Mit der lizenzpflichtigen Applikation SIMATIC iMap wird die Kommunikation einzelner Komponenten (Component based Automation CBA) in verteilten Automatisierungs-lösungen projektiert. In Form einer grafischen Darstellung wird jeder Busteilnehmer mit seinen Kommunikationsdaten wie z.B. die IP-Adresse abgebildet. Die Applikation basiert auf dem PROFINET-Standard, alle Ethernet-Teilnehmer benötigen die PROFINET Kommunikationsmechanismen. Ausführliche Informationen sind im Katalog SIMATIC ST 70 dokumentiert.

3.3.3 Zusatzsoftware-Pakete zur Unterstützung der GMP-Konformität

3.3.3.1 Zugriffschutz

SIMATIC Logon Für die Benutzerverwaltung in STEP 7 ist die lizenzpflichtige Software SIMATIC Logon erforderlich. Über den Dialog SIMATIC Logon Service meldet sich der Benutzer mit Benutzer-ID und Passwort an. Nur eingerichtete Benutzer haben einen Zugriff auf das STEP 7-Projekt (siehe Kapitel 4.6 „Zugriffsschutz“).

Systemspezifikation


3.3.3.2 Versionierung, Änderungslenkung (Change Control) , Audit Trail

Version Trail Die lizenzpflichtige Software Version Trail wird zur Versionierung der STEP 7-Projekte eingesetzt. Für die Versionierung können vom Anwender Hauptversionen und Nebenversionen festgelegt werden. Die Entscheidungskriterien, die eine Versionierung des STEP 7-Projekts als Hauptversion oder als Nebenversion bestimmen, sind im Konfigurationsmanagement festzulegen sowie die Konfigurationselemente, die zu versionieren sind. Zur Nachvollziehbarkeit der Versionierung sind die einzelnen Versionsstände mit Versionsnamen und einem aussagekräftigen Kommentar zu versehen.

Hinweis

Die Versionierung durch Version Trail bezieht sich auf komplette STEP 7-Projekte. Falls in das STEP 7-Projekt ein HMI-System wie SIMATIC WinCC oder SIMATIC WinCC flexible integriert ist, wird auch das HMI-System in die Versionierung einbezogen.

Online / Offline-Vergleich (STEP 7) In der Basissoftware STEP 7 ist ein Bausteinvergleich für KOP/FUP/AWL integriert. Dieser Bausteinvergleich kann sowohl zum Vergleich verschiedener Projekte, als auch zum Online / Offline Vergleich zwischen Zielsystem und Engineering System angewandt werden (siehe auch Kapitel 4.5.4 „Änderungslenkung (Change Control)“)

SCL-Quellen, die nicht in Bausteine integriert sind, können nicht mit STEP 7 verglichen werden. Zum Vergleich zweier SCL-Quelle können z.B. Hilfsmittel des Betriebssystems verwendet werden.

Version Cross Checker Unterschiedliche Versionsstände von Anwenderprogrammen, die mit der optionalen Software CFC (siehe auch Kapitel 4.5 „Konfigurationsmanagement“) in Form eines Technologieplans erstellt wurden, können mit der lizenzpflichtigen Applikation Version Cross Checker (VXC) geprüft und verglichen werden. Das Ergebnis wird in einer Kombination aus Baumstruktur und Tabelle dargestellt und kann in einer Textdatei gespeichert werden.

Änderungsprotokoll für Online-Aktionen an der CPU In Verbindung mit der Software SIMATIC Logon kann in der Basissoftware STEP 7 V5.4 ein Änderungsprotokoll aktiviert werden. In dem Änderungsprotokoll werden Online-Änderungen mit Aktion, Zeitstempel und Benutzer-ID des angemeldeten Benutzers aufgezeichnet.

Systemspezifikation



4 Leitfaden für die Implementierung von SIMATIC S7 im GMP Umfeld

4.1 Einleitung Dieses Kapitel erläutert beispielhaft die Projektierung der Automatisierungssysteme mit der Systemsoftware STEP 7 im GMP-pflichtigen Umfeld. Auf die Projektierung von HMI-Systemen im GMP-pflichtigen Umfeld wird in diesem Kapitel nicht eingegangen. Weitere Informationen dazu sind im SIMATIC WinCC und im SIMATIC WinCC flexible GMP-Engineering Handbuch zu finden.

Die nachfolgende Grafik zeigt das Lebenszyklusmodell. Der Fokus dieses Kapitels, die Implementierung, ist durch die Markierung im unteren Bereich gekennzeichnet.

Leitfaden für die Implementierung von SIMATIC S7 im GMP Umfeld


4.2 Software-Kategorisierung von STEP 7 Nach dem GAMP ® 4 Leitfaden werden zur Validierung automatisierter System die Software-Komponenten eines Systems in fünf Software-Kategorien eingeteilt. Nachfolgend wird exemplarisch dargestellt wie diese Kategorisierung in Bezug auf STEP7 zu übertragen ist.

Kategorie 1: Betriebssysteme Kategorie 2: Firmware Kategorie 3: Standardsoftware Kategorie 4: konfigurierbare Softwarepakete Kategorie 5: anwenderspezifische Software



4.3 Software-Installation Die Basissoftware STEP 7 ist auf einem Programmiergerät wie dem Field PG bereits vorinstalliert. Zur Projektierung des Automatisierungssystems auf einem Standard-PC wird die Basissoftware STEP 7 auf dem PC installiert. Hardwarevoraussetzungen und zulässige Betriebssysteme sind in der Liesmich-Datei unter Start > SIMATIC > Produkt-Hinweise auf der Produkt-CD dokumentiert.

Der Anschluss an das Automatisierungssystem erfolgt entweder über die MPI-Schnittstelle, die in den Programmiergeräten bereits integriert ist, über Profibus DP oder über Industrial Ethernet. Entsprechende Steckkarten zum Einbau in den Standard-PC stehen zur Verfügung.

Detaillierte Informationen zur Hardware enthält der aktuelle SIMATIC Katalog ST70.



4.4 Grundlagen zur Projektierung Die Automatisierungsaufgabe ist in der Anwenderspezifikation (URS), Funktionsspezifikation (FS) und in der Designspezifikation (DS) detailliert beschrieben. Auf Grundlage dieser Dokumentation wird die Hardware-Planung des Automatisierungssystems durchgeführt und die anwenderspezifische Software ausgearbeitet. Die Causes & Effects-Matrix während der Risikoanalyse wird optimal durch die Option SIMATIC Safety Matrix unterstützt.

4.4.1 Software-Erstellung Die zentrale Bedienoberfläche der Basissoftware STEP 7 ist der SIMATIC Manager. Im SIMATIC Manager wird das STEP 7-Projekt angelegt und verwaltet. Eine übersichtliche Baumstruktur zeigt alle Objekte des Projekts. Zur Konfiguration und Programmerstellung werden unterschiedliche Editoren z. B. HW Konfig, Symbol-Editor, KOP/AWL/FUP-Editor u. a geöffnet.

Mit der Basissoftware STEP 7 wird ein Programm in modularer Art und Weise erstellt. Unterschiedliche Bausteintypen unterstützen bei der Strukturierung der Software.

Ein STEP 7-Projekt oder Multiprojekt umfasst die Hardware-Konfiguration von einem oder mehreren Automatisierungsgeräten, die Symboltabelle, die Anwendersoftware zu den einzelnen Automatisierungsgeräten, die Konfiguration der Netzwerkverbindungen und die Dokumentation. Falls HMI-Systeme in das Projekt integriert sind, sind auch deren Projektdaten im STEP 7-Projekt eingebunden.

Als Multiprojekt wird der Ordner für alle Projekte und Bibliotheken einer Automatisierungslösung bezeichnet, der ein oder mehrere STEP 7-Projekte und optional auch Bibliotheken enthält. Die Projekte innerhalb des Multiprojekts können Objekte mit projektübergreifenden Beziehungen (z. B. projektübergreifende S7-Verbindungen) enthalten.

Nutzen des Multiprojekts

• Wenn Projekte Bestandteil eines Multiprojekts sind, können sie vom Umfang kleiner und überschaubarer angelegt werden.

• Mit Hilfe des Multiprojekts kann z. B. für die dezentrale Bearbeitung pro Bearbeiter ein Projekt angelegt und die Stationen gemäß ihrer Bearbeiter auf die Projekte aufteilt werden.

• Projektübergreifende Funktionen sorgen dafür, dass ein Multiprojekt nahezu wie ein einziges Projekt hantiert werden kann.

Weitere Informationen sind in der STEP 7 Hilfe > Arbeiten mit Projekten im Multiprojekt und im Handbuch SIMATIC Hardware konfigurieren und Verbindungen projektieren mit STEP 7 > Kapitel 16 dokumentiert.



4.4.1.1 Vorgehensweise bei der Programmierung Vor Beginn der Programmierung wird eine Gliederung der Automatisierungsaufgabe in kleinere Funktionsbereiche empfohlen. Einzelne Aggregate wie Ventile, Motoren etc. werden in ihrer Funktion erfasst und beschrieben. Die Bedienphilosophie der Produktionsanlage in den Betriebsarten Hand / Automatik / Vor Ort wird festgelegt. Ein Meldungskonzept sowie ein Sicherheitskonzept erarbeitet.

Vorschläge zur Vorgehensweise sind in der STEP 7 Hilfe > Konzeption der Automatisierungslösung aufgeführt.

Hinweis

Wenn sämtliche Funktionalitäten erfasst sind, sollte geprüft werden, in wieweit bereits vorhandene Standards (SFB /SFC / FB / FC) eingesetzt werden können. Der Einsatz von Standards vermindert erheblich den Validierungsaufwand, da hier keine Softwareerstellung, sondern nur Aufruf- und Parametrierungstätigkeiten durchgeführt werden. Auflistung und Beschreibungen der Standards sind in der STEP 7 Hilfe unter Aufruf von Referenzhilfen > Sprachbeschreibungen, Baustein-Hilfen, Systemattribute dokumentiert.

Zur Softwareerstellung stehen in der Basissoftware STEP 7 die Programmiersprachen Kontaktplan (KOP), Funktionsplan (FUP) und Anweisungsliste (AWL) nach der Norm DIN EN 6.1131-3 / IEC 1131-3 zur Verfügung. Weitere Programmiersprachen können als Option ergänzt werden. (siehe auch Kapitel 3.3.2 „Zusatz Software Engineering“).

Sowohl in KOP, als auch in FUP wird die Software in grafischer Form erstellt. KOP wird wie ein Stromlaufplan gelesen, FUP benutzt die grafischen Symbole der Boolschen Algebra. Bei der Eingabe erfolgt direkt eine Syntax-Prüfung. Zur Darstellung des Programms kann zwischen KOP und FUP direkt umgeschaltet werden. Diese Darstellungsweisen geben einen raschen Überblick über die programmierten Funktionen. Daher werden diese Programmiersprachen für die Programmerstellung bevorzugt.

Die Programmiersprache Anweisungsliste (AWL) listet den Programm-Code zeilenweise auf. KOP und FUP können immer auch in AWL dargestellt werden. Da nicht alle Operationen z.B. mathematische Berechnungen mit KOP oder FUP realisiert werden können, wird in diesen Fällen die Programmiersprache AWL verwendet.

Das Programm wird im KOP/AWL/FUP-Editor in Form von Bausteinen erstellt. Funktionen, die mehrfach im Programm benötigt werden, werden separat in eigenen Funktionsbausteinen (FB) oder Funktionen (FC) programmiert, als anwenderspezifischer Standard getestet und entsprechend aufgerufen. Die Festlegung einer Variablenschnittstelle bei FBs gestattet einen wiederholten Aufruf der Funktion mit unterschiedlicher Parametrierung (z.B. Motorbaustein). FBs ist ein Instanz-DB zugeordnet.



Eigenschaften Baustein-Container In den Objekteigenschaften zum Baustein-Container werden generell Einstellungen zur Programmierung vorgenommen. Unter Objekteigenschaften > Operandenvorrang wird empfohlen die symbolische Darstellung für E, A, M, T, Z, und DB einzustellen. Die Zuordnung von Absolutparametern zu den Symbolparametern wird in der Symboltabelle (siehe auch Kapitel 4.4.2 „Integriertes HMI-System“) eingegeben. Symbolparameter sind wesentlich aussagekräftiger als Absolutparameter.

Die Art und Weise der Meldenummervergabe wird im Baustein-Container unter Spezielle Objekteigenschaften eingestellt.



Bausteineigenschaften Beim Anlegen eines neuen Bausteins im SIMATIC Manager werden zuerst die Baustein-Eigenschaften konfiguriert. Beim Anlegen eines Bausteins im KOP/AWL/FUP-Editor sollten die Bausteineigenschaften nachträglich im SIMATIC Manager bearbeitet werden.

Der Dialog zur Konfiguration der Eigenschaften wird automatisch nach Auswahl des Bausteintyps geöffnet.

In den Eigenschaften werden Baustein-Nummer, -Name, Erstellsprache etc. definiert. Die Zeitstempel für Erstellt am und Zuletzt geändert am werden automatisch von der Basissoftware STEP 7 entsprechend der lokalen Rechnerzeit vergeben. Das Feld Kommentar zeigt die Kommentierung zum Baustein, die vor dem ersten Netzwerk im Baustein eingegeben wurde.



Im Register Allgemein – Teil 2 werden zusätzlich Baustein-Header, Versionsnummer, Autor etc. angegeben.

Zur Versionsverfolgung unterschiedlicher Bausteinversionen kann hier manuell eine Versionsnummer eingegeben werden.

Im Register Aufrufe wird aufgelistet, welche Bausteine dieser Baustein selbst aufruft. In dem Register Attribute werden spezielle Baustein-Attribute vergeben, z. B. das Attribut S7_m_c, das für das Mappen der Schnittstelle zum Bedien- und Beobachtungssystem SIMATIC WinCC für einen integrierten Betrieb erforderlich ist. (siehe auch Kapitel 4.4.2 „Integriertes HMI-System“)

Weitere Bausteineigenschaften wie z.B. KNOW HOW Schutz werden hier nur angezeigt.

Nach Angabe der Bausteineigenschaften wird der Baustein als Objekt im Ordner Bausteine angelegt. Ein Doppelklick auf den Baustein öffnet den KOP/AWL/FUP-Editor für die Programmerstellung.



4.4.1.2 Regeln und Konventionen • Die Software sollte gut strukturiert und in möglichst einfacher Form erstellt

werden. Dies erleichtert die Nachvollziehbarkeit der programmierten Funktionen.

• Funktionen, die öfters verwendet werden, werden einmal in einem FB (parametierbar mit Instanz-DB) bzw. Typical erstellt und getestet. Der Baustein / Typical wird im Programm instanziiert.

• Die programmierten Netzwerke in KOP / FUP / AWL sollten auf einer Bildschirmseite darstellbar sein, damit die programmierte Funktion auf einmal überblickt werden kann.

• Ausgänge sollten im Anwenderprogramm nur einmal angesprochen werden.

• Bei der Berechnung von Laufzeiten in SPS-Programmen sollte man mit der erforderlichen Sorgfalt vorgehen. Beispiel: Man sollte bei der Berechnung einer Zeitdauer für einen Reinigungsvorgang nicht die abgelaufene Zeit dadurch ermitteln, dass die aktuelle absolute Zeit von dem Startzeitpunkt abgezogen wird. Dies kann zu ernsthaften Problemen führen, wenn die Zeit während des Reinigungsvorgangs geändert wird, z.B. durch Synchronisation oder durch Sommer-/Winterzeitumstellung. Dies könnte zu einer verkürzten Reinigungszeit führen. -> Dies bedeutet eine Abweichung von der Spezifikation. -> Das kann den Verlust einer kompletten Charge bedeuten, etc.

• Bei der Programmerstellung sollten Standards, die bereits auf der CPU vorhanden sind, verwendet werden. (z.B. zum Einlesen von Analogwerten (FC105, FC106), für die Alarmbearbeitung (Alarm_S etc.)

• In die anwenderspezifisch erstellten FBs sollten Routinen für die zyklische Bearbeitung, Neustart, Wiederanlauf sowie Fehlerbehandlung und Meldungen eingearbeitet werden. Zur Bearbeitung wird derselbe FB in den entsprechenden OBs aufgerufen.

• Das anwenderspezifisch erstellte Programm sollte mit Diagnosemeldungen wie z. B. Laufzeit- , Endlagen- , Grenzwertüberwachung programmiert werden. Die Diagnosemeldungen sollten am angeschlossenen Bedien- und Beobachtungssystem angezeigt werden.

• Indirekte Adressierung sollte vermieden werden, da die Lesbarkeit des Programms erheblich erschwert wird. Falls eine indirekte Adressierung auf Grund der zu realisierenden Funktion unerlässlich ist, sollte eine Plausibilitätsprüfung der Pointer-Berechnung eingearbeitet werden. Als Programmiersprache wird für die indirekte Adressierung SCL empfohlen. Die Software ist ausführlich zu kommentieren.

• Für die Meldungsverarbeitung sollten die Standardfunktionsbausteine eingesetzt werden (z. B. ALARM_S/D, ALARM_8/8P). Die Standardfunktionsbausteine für die Alarmbearbeitung sind in der STEP 7 Hilfe > Aufruf von Referenzhilfen > Bausteinbeschreibungen, Baustein-hilfen… > Hilfe zu SFBs / SFCs > Kapitel Erzeugung bausteinbezogener Meldungen. Die Auswahl des Bausteins richtet sich nach dem Automatisierungssystem (S7-300 nur ALARM_S und S7-400 ALARM_S/D und ALARM_8/8P) und dem angeschlossenen Bedien- und Beobachtungssystem (SIMATIC WinCC flexible nur mit ALARM_S/D).

• Organisationsbausteine, die im Fehlerfall aufgerufen werden, sollten in das Programm zu Diagnosezwecken eingefügt werden. In den OBs sollte zumindest eine Meldung erzeugt werden.



• Für ein Code-Review sind folgende Aktivitäten durchzuführen:

- Prüfung, ob die zuvor festgelegte „Tag name Konvention“ in der Software durchgängig verwendet wurde,

- Prüfung, ob die zuvor festgelegte Versionierung (SOP Konfigurations-Management) durchgeführt wurde,

- Prüfung, ob für alle Operanden ein eindeutiger Symbolname vergeben wurde,

- Prüfung, ob jeder Operand im Anwenderprogramm verwendet wird,

- Prüfung, ob alle Ein- / Ausgänge eindeutig in der Symboltabelle enthalten sind,

- Prüfung, ob die Software ausreichend kommentiert ist,

- Prüfung auf nicht aufgerufene Bausteine, Netzwerke ohne Programm (dead code),

- Prüfung der Programmstruktur,

- Prüfung, ob alle verwendeten Operanden in der Software nur einmal gesetzt / zurückgesetzt / zugewiesen werden,

- Entwicklungshilfscode muss erkennbar sein,

4.4.1.3 Software-Verriegelungen/Sicherheit Es liegt in der Verantwortung des Programmierers, dass das Anwenderprogramm unter allen Umständen in einer sicheren Art und Weise funktioniert. Vor der Software-Erstellung sind Ereignisse zu berücksichtigen, die zu einer gefährlichen Reaktion führen können und entsprechende Verriegelungen sind zu erstellen.

Derartige Ereignisse sind z. B.:

• Wiederanlauf nach Netzspannungsausfall

• Öffnen / Schließen von Ventilen oder ähnlichem ohne Bedienereingriff und akustischem Signal

• Starten von Motoren ohne Bedienereingriff und akustischem Signal

• Fehlerhafte Eingabe von externen Bediengeräten dürfen keine fehlerhaften Reaktionen hervorrufen

• Reaktion auf ein unerwartetes Fehlen eines Analogeingangsignals

• Ausgabewerte der Analogausgangssignale, wenn die CPU unerwarteter Weise in STOP geht.

• Not-Aus Funktionen dürfen aus gesetzlichen Gründen nicht mit Standard-SPS realisiert werden. Hierfür stehen die fehlersicheren Systeme zur Verfügung. Es wird die SIMATIC Safety Matrix empfohlen. Es kann auch ohne SPS mit Not-Aus geeigneten Geräten die Sicherheit gewährleistet werden.

Hinweis

Zur Gewährleistung der richtigen Logic-Entscheidungen in einer Produktionsanlage trägt auch die Auswahl der richtigen Hardware bei (DI = 0 bedeutet Sensor offen oder Drahtbruch). Eine Drahtbruchüberwachung kann z. B. über Signalbaugruppen mit Namur-Technologie erfolgen.



4.4.2 Integriertes HMI-System In Rahmen des Konzepts Totally Integrated Automation (TIA) kann das WinCC flexible Projekt oder das WinCC-Projekt in ein STEP 7-Projekt integriert werden.

Vorteile der Integration:

• Zentrale Übersicht in der Baumstruktur des SIMATIC Managers

• Zentrales Variablenmanagement in der Symboltabelle des SIMATIC Managers

• Zentrale Verbindungsübersicht zu allen beteiligten Komponenten über NetPro

SIMATIC WinCC flexible Die Systemsoftware WinCC flexible kann auf Grund der Installationsreihenfolge (dazu sind die Hinweise in der Installations-CD zu beachten) direkt in den SIMATIC Manager integriert werden um eines neues Projekt direkt im Zusammenhang mit dem STEP 7-Projekt zu konfigurieren. Die nachträgliche Integration eines bereits bestehenden Projekts wird ebenso vom SIMATIC Manager unterstützt.

Nach einer Integration des WinCC flexible Projekts wird für die Anbindung der Variablen in WinCC flexible auf den Symboleditor des SIMATIC Managers zugegriffen.

• Die Integration von WinCC flexible ist im SIMATIC WinCC flexible GMP-Handbuch näher ausgeführt.

SIMATIC WinCC Für die Integration von SIMATIC WinCC wird für jede Bedien- und Beobachtungsstation ein Objekt OS in der Baumstruktur des SIMATIC Managers angelegt. Allen Variablen, die zum Bedienen und Beobachten in WinCC erforderlich sind, wird das BuB-Attribut S7_m_c zugewiesen.

Das BuB-Attribut kann für folgende Variablen projektiert werden:

• Ein- / Ausgangs- und Durchgangsparameter von Funktionsbausteinen, die mit S7_m_c für das Mappen angemedet sind.

• Merker und E/A Signale nur bei S7-400

Das Attribut wird den Funktionsbausteinen / Datenbausteinen in den Objekteigenschaften, den einzelnen Parametern in den Funktionsbausteinen oder den Symbolen in der Symboltabelle zugewiesen.



Die Abbildung oben zeigt die Symboltabelle mit den Spalten für die Attributeinstellung. In der Spalte B wird das Attribut zum Bedienen und Beobachten aktiviert.

Die Abbildung oben zeigt die Attributvergabe für einen Bausteinparameter.

Namenskonvention

Damit die Projektierungsdaten für WinCC gespeichert und transferiert werden können, werden sie unter einem vom STEP 7 automatisch vergebenen, eindeutigen Namen abgelegt. Die Namen der bedien- und beobachtbaren Variablen, der CFC-Pläne und der S7-Programme bilden Bestandteile dieses Namens und unterliegen aus diesem Grund bestimmten Konventionen:

• Die Namen der S7-Programme in einem S7-Projekt müssen eindeutig sein.

• Die Namen der Variablen, S7-Programme und CFC-Pläne sollen keine Leerzeichen oder Sonderzeichen enthalten.

AS-OS Engineering

Die Daten, die zur Anzeige in WinCC vorbereitet wurden, werden mit dem Transfersystem AS-OS Engineering in den Datenbestand von WinCC transferiert. Die Applikation AS-OS Engineering ist im Lieferumfang der WinCC Systemsoftware enthalten und muss separat installiert werden. Bei der Installation wird das S7-Projekt eines Automatisierungssystems einem Objekt OS zugeordnet. Auch die Varianten mehrere Automatisierungssysteme auf einer OS visualisieren oder mehrere OS zur Visualisierung eines Automatisierungssystems sind konfigurierbar.



4.4.3 Software-Dokumentation Für eine gute Lesbarkeit des Anwenderprogramms ist eine ausführliche Kommentierung (unablässig) erforderlich. In der Basissoftware STEP 7 stehen folgende Kommentare zur Verfügung:

Bausteintitel und Bausteinkommentar

Im Bausteinkommentar wird allgemein die Funktion des Bausteins beschrieben. Außerdem eignet sich der Bausteinkommentar zur manuellen Pflege einer Änderungshistorie. Der Bausteinkommentar wird auch im Dialog Eigenschaften zum Baustein, der im SIMATIC Manager über das Kontextmenü Objekteigenschaften zum Baustein geöffnet wird, angezeigt.

Netzwerktitel und Netzwerkkommentar Jedes Netzwerk wird mit einem aussagekräftigen Titel versehen. Eine ausführliche Beschreibung der programmierten Funktion wird im Netzwerk-Kommentarfeld eingegeben.



Zeilenkommentar Das Anwenderprogramm wird zusätzlich zeilenweise kommentiert, wenn zur Programmierung die Sprache AWL bzw. die optionale Sprache SCL verwendet wurde.

Symbolischer Name In der Symboltabelle werden für alle Operanden wie digitale und analoge Ein- und Ausgänge, Zähler, Zeiten, Merker je nach Verwendung mit Bit, Byte, Wort oder Doppelwort und die programmierten Bausteine (FB, FC, UDT, DB) ein symbolischer Name eingetragen. Dieser symbolische Name sollte so gewählt werden, dass z.B. der Bezug auf ein Aggregat oder eine Funktion erkennbar ist. Für den Symbolnamen sind max. 24 Zeichen erlaubt, Groß- / Kleinschreibung wird nicht unterschieden. Zusätzlich kann ein ausführlicher Kommentar eingetragen werden.

STEP 7 bietet die Möglichkeit, Texte, die in einem Projekt einsprachig abgelegt sind, zu exportieren, übersetzen zu lassen, wieder zu importieren und in der übersetzten Sprache anzeigen zu lassen. Dazu gehören Titel und Kommentare sowie Anzeigetexte. Weitere Informationen stehen in der STEP 7 Hilfe unter Einrichten und Bearbeiten des Projekts > Bearbeiten eines Projekts > Texte mehrsprachig verwalten.



DOCPRO Mit der lizenzpflichtigen Option DOCPRO kann ein Anlagenbuch komfortabel und konsistent einschließlich Versionierung erstellt werden.



Defaultmäßig werden Schriftfelder nach DIN 6771 angeboten. Das Layout kann in weiten Bereich den Bedürfnissen angepasst werden, Die Skizze zeigt die prinzipielle Aufteilung eines Schriftfeldes nach DIN 6771. Die Aufteilung der einzelnen Schriftfelder ist nicht maßstabsgerecht.

Bedeutung der einzelnen Schriftfelder:

Nr Bedeutung Nr Bedeutung

1 Kennzeichnungsblock nach Anlage 10 Zeichnungsnummer desBestellers

2 Kennzeichnungsblock nach Ort 11 Blatt-Nr.

3 Besteller, Betreiber, Anlage 12 Zustand: Änderungsindex

4 Benennung 13 Mitteilung der Änderung

5 Unterlagenart 14 Datum der Änderung

6 Bearbeiter, Geprüft, Norm 15 Name des Bearbeiters der Änderung

7 Datum der Erstellung 16 Nr. des Ursprungsplans

8 Sondervermerk 17 Erstellerfirma

9 Unterlagennummer 18 Firma, Jahr



Alle Daten, die mit einem Projektierungswerkzeug erstellt wurden, können in eine DOCPRO Dokumentation eingefügt werden. Die Daten sind somit in klar strukturierter Form verfügbar und können zentral verwaltet und für die Qualifizierung verwendet werden. In einer Dokumentation können z. B. folgende Daten enthalten sein:

• Bausteine (Programmcode, erstellt mit KOP, FUP, AWL etc.)

• Symboltabellen mit den symbolischen Namen für absolute Adressen

• Referenzdaten, wie z. B. Querverweislisten, Belegungspläne,Programmstruktur

• Hardware-Konfigurationstabellen mit der Anordnung der Baugruppen im Automatisierungssystem und Angabe der Baugruppenparameter

• Variablentabellen mit Status-Formaten sowie Status- und Steuerwerten

• Globaldatentabellen

• Verbindungstabellen

• CFC- Pläne

Hinweis

Durch den Eintrag eines Objektes in eine Dokumentation wird ein Druckobjekt erstellt. DOCPRO legt das Objekt nicht in einer eigenen Datenhaltung ab, sondern fordert es im Moment des Ausdruckens direkt bei der jeweiligen Applikation an. Die Ausdrucke enthalten immer die aktuellen Daten.



4.5 Konfigurationsmanagement STEP 7 ist das Basispaket zur Konfigurierung und Programmierung von SIMATIC-Automatisierungssystemen. Die in STEP 7 integrierten SIMATIC-Programmiersprachen erfüllen die Norm DIN EN 6.1131-3 / IEC 1131-3. Standards sind in Form von Bibliotheken im Basispaket enthalten. Dies sind z.B. Funktionsbausteine für PID-Regler, Zeitstempelung, Alarmbearbeitung, Systemfunktionen, Systemfunktionsbausteine etc.

Die Konfiguration und Programmerstellung erfolgt anwenderspezifisch, ausgerichtet auf die Anforderungen der Automatisierungsaufgabe. Ohne Versions- und Änderungsmanagement ist die Softwareerstellung nur schwer nachvollziehbar. Daher ist bereits zu Beginn der Softwareerstellung ein professionelles Konfigurationsmanagement einzusetzen.

Das Konfigurationsmanagement sollte in einer SOP beschrieben werden. Alle am Projekt beteiligten Personen müssen in der Anwendung dieser SOP geschult werden, hierdurch wird eine gemeinsame Basis zur Konfiguration geschaffen.

Hinweis

Die nachfolgenden Kapitel liefern ein Beispiel zur Software-Versionierung und zur Änderungslenkung (Change Control). Die Vorgehensweise im Falle von Änderungen an einer in Betrieb befindlichen Anlage sollte grundsätzlich mit dem Anlagenbetreiber abgestimmt werden.

4.5.1 Änderung der Systemsoftware

Updates, Service Packs und Hotfixes Updates, Service Packs und Hotfixes werden zur Funktionserweiterung bzw. Fehlerbeseitigung in der Basissoftware STEP 7 bereitgestellt.

• Ein Update ist eine Aktualisierung innerhalb einer STEP 7-Version.

• Ein Hardware-Katalog Update enthält Dateien für die neue Hardware

• Ein Service Pack ist eine Fehlerbeseitigung die mehrere Hotfixes beinhaltet.

• Ein Hotfix ist eine kurzfristige Fehlerbeseitigung. Hotfixes werden nur in speziellen Fällen bereitgestellt.

Der Validierungsaufwand bezüglich Änderungen wird im Rahmen einer Risikobewertung festgelegt.



Upgrades (Migration) Mit einem Upgrade wird die Basissoftware STEP 7 hochgerüstet. Die Hochrüstung kann neben der Erweiterung des Funktionsumfangs auch eine Ergänzung des integrierten Hardware-Katalogs bedeuten. Anpassungen im Editor HW-Konfig oder bei den Verbindungseinstellungen im Editor NetPro können erforderlich sein.

Im Hilfesystem zu STEP 7 unter Bearbeiten von Projekten mit unterschiedlichen STEP 7 Versionen sind entsprechende Vorgehensweisen dokumentiert.

Die genaue Software-Version mit der das STEP 7-Projekt erstellt wurde, sowie verwendete Optionspakete werden über das Kontextmenü Objekteigenschaften > Notwendige Softwarepakete zum obersten Knoten in der Projektstruktur ausgelesen.

Die Schaltfläche Ausführen prüft das aktuelle Projekt bzw. die aktuelle Bibliothek nach Softwarepaketen, die zum Bearbeiten bestimmter Objekte notwendig sind. Diese Funktion wird verwendet, wenn erstmalig mit einer älteren STEP 7 Version ein Projekt bzw. eine Bibliothek bearbeitet wird.

Hinweis

Bei Updates und Migration sollten die eingesetzten Tools aus Validierungssicht geprüft werden. Standard-Tools können ohne zusätzlichen Validierungsaufwand verwendet werden.



Vorgehensweise bei der Aktualisierung der System-Software Bei der Aktualisierung der STEP 7 Basissoftware sind bestimmte Maßnahmen erforderlich, um den validierten Zustand der Anlage zu erhalten:

• Grundlage für eine Änderung ist stets der Änderungsantrag des Betreibers

• Beschreibung der Ursachen für die Aktualisierung der System-Software

• Beschreibung der neuen Funktionen

• Angaben zur Kompatibilität der Vorgängerversion

• Aktualisierung der technischen Dokumentation

• Installation nach Herstellerangaben (z.B. Standard Dokumentation, Projekt Migrator)

• Es wird empfohlen im Vorfeld eine Risikobewertung durchzuführen und die Prüfschwerpunkte für die Qualifizierung festzulegen.

• Qualifizierung

4.5.2 Austausch / Änderung der Hardware / Firmware Bei der Aktualisierung der Hardware / Firmware sind bestimmte Maßnahmen erforderlich, um den validierten Zustand der Anlage zu erhalten:

• Grundlage für eine Änderung ist stets der Änderungsantrag des Betreibers

• Beschreibung der Ursachen für die Aktualisierung der Hardware

• Beschreibung der neuen, verbesserten Funktionen

• Angaben zur Kompatibilität der Vorgängerversion

• Aktualisierung der technischen Dokumentation

• Installation nach Herstellerangaben (z.B. Standard Dokumentation)

• Es wird empfohlen im Vorfeld eine Risikobewertung durchzuführen und die Prüfschwerpunkte für die Qualifizierung festzulegen.

• Qualifizierung

Aktualisierung der Firmware Um ein Firmware-Update für Baugruppen durchzuführen, sind die Anweisungen in der STEP 7 Hilfe unter Laden > Laden aus dem PG ins Zielsystem > Aktualisieren von Baugruppen und Modulen oder unter Einstellen des Betriebsverhaltens > Aktualisieren des Betriebssystems auf dem Zielsystem zu befolgen.



Austausch von Baugruppen Vor dem Tausch der Baugruppen ist der Baugruppentyp zu prüfen. Die I&M-Daten (Identification und Maintenance) unterstützen dabei. I&M-Funktionen definieren Auskunftsfunktionen, mit denen Informationen über Geräte abgerufen werden können, z. B. Hersteller, Ausgabestand, Bestelldaten etc. Mit Hilfe von I&M-Funktionen können Informationen über das jeweilige Gerät in den Phasen Projektierung, Inbetriebnahme, Parametrierung, Diagnose und Reparatur ausgewertet werden. I-Daten sind Informationen zur Baugruppe, die zum Teil auch auf dem Gehäuse der Baugruppe aufgedruckt sind. I-Daten können im Rahmen der Baugruppendiagnose mit STEP 7 gelesen werden (Register "Allgemein" und Register "Identifikation" des Baugruppenzustands). M-Daten sind anlagenabhängige Informationen wie AKZ (Anlagenkennzeichen), OKZ (Ortskennzeichen), Einbaudatum und Kommentar, die in den Objekteigenschaften zur Baugruppe im HW-Konfig eingepflegt werden sollen. M-Daten können über Online-Zugriffe auf die Baugruppe geschrieben werden. Falls ein neuer Baugruppentyp zur Verfügung steht, ist die Kompatibilität zum Vorgängertyp zu kontrollieren. Falls eine übereinstimmende Kompatibilität vorliegt, kann die Baugruppe direkt getauscht werden.

Hinweis

Bei Prüfung der Kompatibilität einer CPU-Baugruppe ist zu berücksichtigen, ob schnellere Laufzeiten Auswirkungen auf das Anwenderprogramm haben.

Falls die Kompatibilität nicht gegeben ist, sind Konfigurationsmaßnahmen erforderlich. Das STEP 7-Projekt muss mit dem erforderlichen Hardware-Update hochgerüstet werden. Im Editor HW-Konfig werden entsprechende Anpassungen vorgenommen.

Das Automatisierungssystem S7-400 unterstützt das Ziehen / Stecken von Baugruppen während des Betriebs. Dazu ist die Programmierung des OB83 erforderlich, der sowohl beim Ziehen, als auch beim Stecken einer Baugruppe bearbeitet wird. In Verbindung mit PROFINET I/O unterstützt auch die S7-300 das Ziehen / Stecken von Baugruppen während des Betriebs (OB55, 56, 57). Beim Tausch von Baugruppen muss sichergestellt werden, dass wieder eine passende Baugruppe gesteckt wird. Das Stecken einer falschen Baugruppe wird mit der Lampe EXTF an der CPU angezeigt.



4.5.3 Versionierung der Anwendersoftware

Allgemeines zur Versionierung Die Software-Version gibt Aufschluss über den aktuellen Versionsstand der Anwendersoftware.

Zur Versionierung der Anwendersoftware werden folgende Daten angegeben:

• Name

• Datum

• Versionsnummer

• Kommentar zur Änderung

• Änderungshistorie

Hinweis

Die Versionierung der Anwendersoftware ist in STEP 7 bausteingranular möglich. Sie kann bspw. über das Feld „Version“ in den Bausteineigenschaften und / oder mittels zusätzlicher Kommentare gepflegt werden.

Die Vorgehensweise bei der Versionierung ist Teil des Konfigurationsmanagements und in einer SOP, die für alle am Projekt beteiligten Personen bindend ist, zu beschreiben.



Im Folgenden werden Beispiele und Möglichkeiten zur Durchführung einer Versionierung in STEP 7 aufgezeigt.

Versionierung einzelner Bausteine Für jeden Baustein (OB, FB, FC, DB, UDT) werden in STEP 7 automatisch Objekteigenschaften angelegt. Diese werden im Ordner Baustein über das Kontextmenü Objekteigenschaften zum angewählten Baustein ausgelesen und manuell ergänzt. Im Register Allgemein – Teil 2 befinden sich Felder zur Angabe der Versionsnummer und des Autors.

Die Versionsnummer wird manuell vergeben. Die Merkmale für die Vergabe einer Haupt- oder einer Nebenversionsnummer sind in einer SOP zu definieren sowie die Konfigurationselemente, die zu versionieren sind.

Die Änderungshistorie wird im Bausteinkommentar eingetragen. Der Bausteinkommentar und damit die Änderungshistorie kann auch in den Objekteigenschaften zum Baustein im Register Allgemeiner Teil 1 ausgelesen werden.

Das Datum Erstellt am wird bei der Ersterstellung des Bausteins automatisch von STEP 7 fixiert. Ebenso werden die Daten für Zuletzt geändert am: getrennt nach Code- und Schnittstellenänderung automatisch vom System aufgezeichnet.



Versionierung des STEP 7-Projekts Die Basissoftware STEP 7 erzeugt Prüfsummen für Systemdaten und Anwenderdaten, die einen bestimmten Versionsstand des STEP 7-Projekts repräsentieren (siehe auch Kapitel 4.6.3 „Schutzmaßnahmen in der Software“).

Zur Verwaltung der S7-Projekte (Anwendersoftware) aus GMP-Sicht entlang des Lebenszyklus eines Automatisierungssystems wird die lizenzpflichtige Software Version Trail eingesetzt (siehe auch Kapitel 3.3.3.2 „Versionierung, Änderungslenkung“).

Hinweis

Für die Anwendung von Version Trail ist die lizenzpflichtige Software SIMATIC Logon erforderlich. Über den SIMATIC Logon Service oder über den SIMATIC Manager muss ein Benutzer angemeldet sein, unter dem alle relevanten Aktionen in der Änderungshistorie eingetragen werden.

Mit Version Trail können mehrere STEP 7-Projekte / Bibliotheken / Multiprojekte versioniert werden. Jedes STEP 7-Projekt wird unter einer Haupt- oder einer Nebenversionsnummer archiviert. Die Merkmale für die Vergabe einer Haupt- oder einer Nebenversionsnummer sind in einer SOP zu definieren, sowie die Konfigurationselemente, die zu versionieren sind. Eine lückenlose Hochzählung der Versionen nach Validierungsgesichtspunkten wird von Version Trail gewährleistet. Eine abgeschlossene Version kann nicht mehr verändert werden. Aus dem mit Version Trail erzeugten Archiv (Versionsprojekt) von Projektdaten können auch Projekte zurückgelesen (dearchiviert) werden.

Version Trail wird über Start > Programme > SIMATIC > STEP 7 > Version Trail geöffnet. Nur geschlossene Projekte können archiviert werden.

Jeder Archivierungsvorgang in Version Trail wird mit Aktion, Projektnamen, Versionsnummer, Zeitstempel, angemeldeter Benutzer-ID und Kommentar aufgezeichnet. Die Historie kann über das Menü Extras > Versionshistorie ausgelesen werden.



Im SIMATIC Manager kann zur Archivierung / Dearchivierung eines STEP 7-Projekts direkt auf die Software Version Trail zugegriffen werden. Dazu wird das Menü Datei > Version > Archivieren (Dearchivieren) geöffnet.

Hinweis

Falls im STEP 7-Projekt ein HMI-System wie WinCC oder WinCC flexible integriert ist, wird das HMI-Projekt in die Versionierung mit einbezogen.

Detaillierte Informationen zum Anlegen und Verwalten der Projektversionen enthält das Hilfesystem zur Software Version Trail.



4.5.4 Änderungslenkung (Change Control) Die Änderungslenkung (Change Control) gibt Auskunft über durchgeführte Änderungen der Anwendersoftware (Wer hat, Wann, Was geändert).

Online / Offline Vergleich auf Basis STEP 7 Mit dem Online / Offline Vergleich bietet STEP 7 ein Hilfsmittel um Unterschiede zwischen zwei unterschiedlichen Projekten/Versionen (Offline/Offline) oder zwischen Zielsystem (CPU) und Projektversion (Online/Offline) darzustellen. Unterstützt werden die Programmiersprachen KOP/AWL/FUP.

Der Online / Offline Vergleich wird im SIMATIC Manager unter dem Menü Extras > Bausteine vergleichen geöffnet.

Verglichen werden wahlweise Bausteincode oder Zeitstempel. Bei Aktivierung des Kontrollkästchens SDB wird auch die Hardware-Konfiguration verglichen. Gleicher Zeitstempel bedeutet immer gleicher Code. In den Vergleich werden alle Bausteintypen wie OB, PB, FB, FC, DB, UDT etc. einbezogen. Das Ergebnis wird in einem Dialogfenster dargestellt, in dem die Bausteinliste und die Vergleichsergebnisse gezeigt werden. Weiterhin können zu jedem Baustein Details abgerufen werden. Zur Dokumentation kann das Vergleichsergebnis auf einem Drucker ausgegeben werden.



Hinweis Zum Vergleich von CFC-Quellen ist die Option Version Cross Checker erforderlich.

Änderungsprotokoll aktivieren In Verbindung mit der lizenzpflichtigen Software SIMATIC Logon kann ein Änderungsprotokoll für das STEP 7-Projekt aktiviert werden. In das Änderungsprotokoll werden Online-Aktionen mit Zeitstempel und angemeldeter Benutzer-ID aufgezeichnet. Die Eingabe eines Kommentars ist Pflicht.

Folgende Online-Aktionen werden aufgezeichnet:

• Aktivierung / Deaktivierung / Konfiguration von Zugriffsschutz und Änderungsprotokoll

• Öffnen / Schließen von Projekten und Bibliotheken

• Laden ins Zielsystem (Systemdaten)

• Ausgewählte Operationen zum Laden und Kopieren von Bausteinen

• Aktivitäten zur Änderung des Betriebszustands

• Urlöschen



Das Änderungsprotokoll kann im SIMATIC Manager angezeigt werden. Dazu wird in der Baumstruktur z. B. das Objekt Station selektiert und das Kontextmenü Änderungsprotokoll anzeigen aufgerufen.

Der Inhalt des Änderungsprotokolls richtet sich nach der Selektion im Strukturbaum. Ein Änderungsprotokoll kann für jede Station und über das gesamte Projekt angezeigt werden. Das abgebildete Protokoll zeigt die Zugriffe auf das Zielsystem. Für den angewählten Eintrag wird im unteren Bereich der eingetragene Pflichtkommentar sowie Zeitstempel und Benutzer-ID des eingeloggten Benutzers angezeigt.

Online Übertragung von Änderungen / geänderten Bausteinen Zur Übertragung geänderter Bausteine muss die CPU in einem Betriebszustand sein, bei dem das Laden zulässig ist (STOP oder RUN-P). Falls der Baustein auf der CPU schon vorhanden ist, erfolgt eine Nachfrage, ob der Baustein überschrieben werden soll. Der Zugriff auf die CPU sollte mit einem Passwort geschützt sein (siehe Kapitel 4.6.1 „Zugriffsschutz auf die CPU“).

Hinweis

Vor dem Laden ist die Bausteinkonsistenz zu prüfen und gegebenenfalls wieder herzustellen über SIMATIC Manager -> Bearbeiten -> Bausteinkonsistenz prüfen. Beim Laden im RUN-P-Zustand muss jedoch beachtet werden, dass das Programm bausteinweise übertragen wird. Dabei können Konflikte auftreten, wenn z. B. ein Bausteinparameter geändert wurde. Die CPU geht dann während der Bearbeitung des Zyklus in den Betriebszustand STOP. Es wird daher empfohlen, die CPU vor dem Laden in den Betriebszustand "STOP" zu schalten.

Hinweis

Vor dem Laden ist der Bedarf der Lokaldaten je Priorität mit der Referenzliste zu ermitteln und mit der Parametrierung in HW-Konfig zu überprüfen und gegebenenfalls entsprechend anzupassen.





4.6 Zugriffsschutz Ein Zugriffsschutz kann sowohl für den Zugriff auf die CPU, als auch für das STEP 7-Projekt eingerichtet werden.

! Hinweis Ein Urlöschen der CPU über die Hardware kann weder bei der S7-300, noch bei der S7-400 verhindert werden. Ein Urlöschen ist mit dem Ziehen der Baugruppe in spannungslosem Zustand gleich zu stellen. Daher liegt es in der Verantwortung des Betreibers, den physikalischen Zugang (z.B. abgeschlossener Schrank) zu den Automatisierungssystemen entsprechend zu sichern.

4.6.1 Zugriffsschutz auf die CPU CPU-Baugruppen, die diese Funktionalität unterstützen, können mit einem Passwort vor unberechtigtem Zugriff geschützt werden. Das Passwort wird im Editor HW-Konfig festgelegt. In der Hardwareauflistung wird die CPU angewählt und mit Doppelklick der linken Maustaste der Dialog Objekteigenschaften geöffnet. Im Register Schutz wird das Passwort eingegeben.

Der abgebildete Dialog ist abhängig von der Ausführung der CPU-Baugruppe und daher nur ein Beispiel.

Für diese CPU können drei verschiedene Schutzstufen konfiguriert werden.

1. Alle PG-Funktionen sind abhängig von der Schlüsselschalterstellung erlaubt (Default-Einstellung).Beispiel: Schlüsselschalterstellung RUN: Das Laden von Objekten aus der CPU ins PG ist erlaubt, d. h. nur lesende PG-Funktionen sind erlaubt. Die Funktionen für Prozessführung, Prozessbeobachtung und Prozesskommunikation sind erlaubt. Alle Auskunftsfunktionen sind erlaubt.

2. Die Funktionen für Prozessführung, Prozessbeobachtung und Prozesskommunikation sind erlaubt. Alle Auskunftsfunktionen sind erlaubt.



3. Das Passwort wird bei jeder Bedienung abgefragt oder kann generell für eine Projektsitzung eingegeben werden. Die Freigabe durch das Passwort kann gezielt wieder aufgehoben werden, endet jedoch immer mit dem Beenden des SIMATIC Managers.

Einzelheiten zur Passwortvergabe stehen in der STEP 7 Hilfe > Aufbau der Online-Verbindung und CPU-Einstellung > Passwortschutz für Zugriff auf Zielsysteme oder in der Hilfe zum Dialog Objekteigenschaften der CPU im Editor HW-Konfig.

4.6.2 Zugriffsschutz auf STEP 7-Projekt Ab der Version V5.4 der Basissoftware STEP 7 kann in Verbindung mit der lizenzpflichtigen Software SIMATIC Logon im STEP 7-Projekt eine Benutzerverwaltung eingerichtet werden. Dazu wird das Menü Extras > Zugriffsschutz > Verwalten angewählt.

Die Benutzer müssen in Windows unter Systemsteuerung > Verwaltung > Computerverwaltung > Lokale Benutzer und Benutzergruppen angelegt sein. Im Bereich links unten werden die in Windows eingerichteten Benutzergruppen und Benutzer angezeigt.

Für den Zugriffsschutz der STEP 7-Projekte sind im System zwei Rollen mit unterschiedlichen Rechten vorgesehen:

• Projekt Administrator Der Projekt Administrator hat Rechte zur Verwaltung der Benutzer, zum Aktivieren / Deaktivieren des Zugriffschutzes, zum Aktivieren / Deaktivieren des Änderungsprotokolls und zur kompletten Bearbeitung des Projekts.

• Projekt Bearbeiter Der Projekt Bearbeiter hat das Recht zur kompletten Bearbeitung des Projekts, kann jedoch keine Benutzer verwalten und die Einstellungen für Zugriffsschutz und Änderungsprotokoll nicht verändern.



Beim ersten Aktivieren des Zugriffschutzes wird ein Dialog zur Eingabe eines Projektpasswortes geöffnet. Für Anwender, die nicht als Projekt Bearbeiter eingetragen sind, oder die kein SIMATIC Logon installiert haben, gilt dann: Das STEP 7-Projekt kann dann nur noch mit Kenntnis des Projektpasswortes geöffnet werden.

Nachdem der Zugriffsschutz für ein STEP 7-Projekt aktiviert wurde, wird beim Öffnen des Projekts der SIMATIC Logon Service zum Einloggen des Benutzers eingeblendet. SIMATIC Logon kontrolliert Benutzer-ID und Passwort.

Hinweis Meldet sich ein Benutzer am SIMATIC Logon Service an, der nicht in der Benutzerverwaltung des STEP 7-Projekts eingetragen ist, so kann er nur mittels des Projektpasswortes Zugriff erlangen. Aus diesem Grund sollte das Projektpasswort vertraulich gehandhabt werden. Zugriff und Rahmenbedingungen für die Nutzung des Projektpasswortes sollten organisatorisch geregelt werden (bspw. mittels einer SOP).

Hinweis

Es wird empfohlen, den Zugriffsschutz und das Änderungsprotokoll nach dem ersten qualifizierten Versionsstand zu aktivieren.



4.6.3 Schutzmaßnahmen in der Software

Bausteinschutz Bausteine vom Typ OB, FB, FC und DB können geschützt werden. Um einen Baustein mit dem Attribut Know How Schutz zu belegen, wird der Baustein im KOP/AWL/FUP-Editor als AWL-Quelle generiert. Dazu wird das Menü Datei > Quelle generieren angewählt. Für die Bausteinquelle wird ein Name festgelegt und der zu generierende Baustein ausgewählt. Die erzeugte Quelle wird im SIMATIC Manager im Ordner Quelle abgelegt. Ein Doppelklick auf die entsprechende Quelle öffnet den Inhalt.

Der Eintrag KNOW_HOW_PROTECT verhindert eine Ausgabe des Codes im KOP/AWL/FUP-Editor. Der Code kann nur noch in der Quelle ausgelesen und bearbeitet werden. Da die Bausteine auch ohne Quelle im Automatisierungssystem ablaufen, kann die Quelle vom Lieferumfang der Anwendersoftware ausgenommen werden. Damit ist eine Änderung des Bausteins nur mit dem Besitz der Quelle möglich.

Kontrolle der Integrität des S7 Runtime-Systems auf einer CPU Die Basissoftware STEP 7 legt automatisch Prüfsummen für Systemdaten und Anwenderprogramm fest. Über die Prüfsumme Systemdaten wird die Hardware-Konfiguration (z.B. Parametrierung der Baugruppen, Konfiguration der Verbindungen) kontrolliert, über die Prüfsumme Anwenderdaten das Anwenderprogramm. In der Prüfsumme Anwenderdaten sind die Runtime-Daten der Datenbausteine nicht enthalten. Bei Änderungen wird die entsprechende Prüfsumme neu ermittelt. Die aktuellen Prüfsummen können über den Dialog Objekteigenschaften zum Ordner Bausteine angezeigt werden.



Folgende Vorgehensweise wird zur Auswertung der Prüfsumme empfohlen:

1. Versionierung des getesteten und abgenommenen STEP 7-Projekts (z. B. nach SAT)

2. Auslesen der Soll-Prüfsummen Systemdaten und Anwenderdaten im S7-Offline-Projekt (SIMATIC Manager) über die Objekteigenschaften des Bausteincontainers

3. Laden der getesteten, versionierten Version in die S7 Station

4. Auslesen der Online-Istprüfsumme

- über die Objekteigenschaften des Online-Bausteincontainers

- über den SFC51 aus der Systemzustandsliste (SZL)

5. Vergleich der Sollprüfsummen (Offline) / Istprüfsummen (Online)

- Manuell über das Engineering System

6. Differenzen beim Vergleich können z. B. Meldungen im HMI-System auslösen

7. Feststellen unbefugter Änderungen über die Funktion Online- / Offline-Vergleich einzelner Bausteine (Kapitel 4.5.4 Änderungslenkung (Change Control)) oder Version Cross Checker in Verbindung mit CFC (Kapitel 3.3.3.2 „Versionierung, Änderungslenkung“)



Eine Beschreibung der SFC51 RDSYSST zur Auswertung der SZL-Teilliste für Diagnosefunktionen ist in der STEP 7 Hilfe folgendermaßen abgelegt:

1. STEP 7 Hilfe > Aufruf von Referenzhilfen > Sprachbeschreibungen, Baustein-Hilfen, Systemattribute > Hilfe zu SFBs/SFCs

2. Unter der Überschrift SFCs für die Diagnose > Auslesen einer SZL-Teilliste oder eines SZL-Teillistenauszugs mit der SFC 51 "RDSYSST" informiert eine allgemeine Beschreibung über den Einsatz, die Parametrierung und den Aufruf des SFC 51

3. Unter der Überschrift Kommunikationszustandsdaten > SZL_ID W#16#0232 Zustandsdaten zu einem Kommunikationsteil, CPU-Schutzstufe und Bedienschalterstellungen wird die Teilliste für die Kommunikation beschrieben.

4. Unter Datensatz des Teillistenauszugs mit der SZL-ID W#16#0232 Index W#16#0004 ist die Ablage der Prüfsummen dokumentiert

Vorschlag für eine Lösung:

Nach Inbetriebnahme und Abnahme des Anwenderprogramms durch den Kunden werden die aktuellen Prüfsummen für Systemdaten und Anwenderdaten im SIMATIC Manager ausgelesen und manuell in einem Datenbereich (read-only) abgelegt. Jede Prüfsumme belegt ein Doppelwort. Zusätzlich können Versionsnummer und Versionsdatum in dem Datenbereich hinterlegt werden. Über den Aufruf des SFC51 RDSYSST wird das Auslesen der Prüfsummen aus der Systemzustandsliste (SZL) der CPU organisiert. Zur Auswertung werden die aktuell ausgelesenen Prüfsummen mit dem Inhalt des manuell angelegten Datenbereichs verglichen und entsprechende Meldungen erzeugt.

Erkennen von elektromagnetischen Störungen (nur bei S7-400) Die Hardware des Automatisierungssystems muss gemäß Aufbaurichtlinie vor elektromagnetischen Störungen (EMV) gesichert werden. Elektromagnetische Störungen verursachen Speicherfehler in der CPU, die spontan zu unkontrolliertem Verhalten der Software führen können. Die S7-400 kann Speicherfehler selbst korrigieren. Beim Korrigieren des Speichers wird der OB84 aufgerufen, die Fehlerursache wird in den Startinformationen angezeigt. Zur Erkennung von Speicherfehlern wird über den OB84 eine Meldung im HMI-System erzeugt.



4.7 Audit Trail Das Anwenderprogramm (STEP 7-Projekt) ist eine validierte Version. Daher werden Änderungen auf den Automatisierungssystemen während der Laufzeit nicht vorgenommen.

Unbefugte Eingriffe auf das Automatisierungssystem können zur Laufzeit erkannt werden. Die erforderlichen Maßnahmen sind im Kapitel 4.6 „Zugriffsschutz“ beschrieben.

Der Audit Trail für die Bedienung des Prozesses wird von den Bedien- und Beobachtungssystemen erzeugt. Weitere Informationen dazu sind im SIMATIC PCS 7, SIMATIC WinCC oder SIMATIC WinCC flexible GMP-Engineering Handbuch: Leitfaden zur Durchführung von Automatisierungsprojekten im GMP Umfeld“ zu entnehmen.



4.8 Uhrzeitsynchronisation Innerhalb eines Systems muss eine einheitliche Zeitreferenz gewährleistet sein, um die Archivierung von Meldungen, Alarmen etc. mit eindeutigen Zeitstempeln versehen zu können. Eine Uhrzeitsynchronisation auf ein Zeitnormal ist zwar wünschenswert, jedoch nicht zwingend erforderlich. Besonders empfehlenswert ist eine Zeitsynchronisation bei der Archivierung von Daten und der Analyse von Störungen (Sequence of Events, SOE).

Die Uhrzeitsynchronisation erfolgt auf Basis der normierten Weltuhrzeit UTC (Universal Time Coordinated).

In einem automatisierten System kann entweder die Steuerung, das Bedien- und Beobachtungssystem oder z. B. SICLOCK der Uhrzeit-Master sein. SICLOCK unterstützt die Synchronisation auf Basis GPS oder DCF77.

Zur Uhrzeitsynchronisation (im Millisekundenbereich) über Ethernet steht das Protokoll SIMATIC- Uhrzeitsynchronisation zur Verfügung. Ein Uhrzeit Stellen (im Sekundenbereich) wird mit dem Protokoll NTP (Network Time Protocol) durchgeführt.

Im Automatisierungssystem S7-300 wird in den neuen CPUs (CPU 319) die Uhrzeit synchronisiert, ansonsten gestellt. Das „Uhrzeit stellen“ hat allerdings nicht dieselbe Genauigkeit wie die Uhrzeitsynchronisation, da Telegramm- und Skriptlaufzeiten einfließen.

Die Automatisierungssysteme S7-400 können auf dem Anlagenbus Ethernet zeitsynchron betrieben werden. Dabei wird eine S7-400 als Master eingestellt, alle weiteren als Slave. Diese Einstellungen erfolgen im Editor HW-Konfig im Dialog Objekteigenschaften zur CPU, CP, DP-Master, DP-Slave.

Die Vorgehensweise zum Stellen der Uhrzeit im Automatisierungssystem ist für die Bussysteme Ethernet, Profibus und MPI gleich. Das Ethernet NTP ist auf Profibus und MPI nicht verfügbar.

Uhrzeit stellen im Automatisierungssystem Zum Stellen der Uhrzeit vom SIMATIC WinCC Server als Uhrzeit-Master in einer S7-Steuerung ist in der Beitrags-ID 7802886 ausführlich beschrieben (http://support.automation.siemens.com/WW/view/de/7802886).

Das Stellen der Uhrzeit von einem WinCC flexible Bediengerät als Uhrzeit-Master ist im „SIMATIC WinCC flexible GMP-Engineering Handbuch: Leitfaden zur Durchführung von Automatisierungsprojekten im GMP-Umfeld“ dokumentiert.

Stellen der Uhrzeit vom AS im Panel (WinCC flexible) Anlegen eines Datenbereiches Datum/Uhrzeit in einem Datenbaustein

In der Steuerung wird ein Datenbereich, bestehend aus einer "DATE_AND_TIME" Variablen, angelegt.

In diesem Datenbereich wird die Systemzeit des Automatisierungssystems zum Abholen von WinCC flexible bereitgestellt.



Das Auslesen der Systemzeit wird mit dem Weckalarm OB35 durchgeführt. Der OB35 wird defaultmäßig alle 100ms bearbeitet. Der Zeitpunkt, zu dem die Bearbeitung des OB35 gestartet wurde, liegt in den Lokaldaten des OB und wird lediglich auf den zuvor definierten Datenbereich übertragen.

In WinCC flexible wird beim Bereichszeiger Datum/Uhrzeit Steuerung der Datenbereich angegeben und der Erfassungszyklus für die Uhrzeitsynchronisation eingestellt. Die Synchronisation führt das Bediengerät automatisch durch.



4.9 Zeitstempelung Die Automatisierungssysteme S7-300 und S7-400 sind mit einer Echtzeituhr (Software-Uhr) ausgestattet. Für die Zeitstempelung wird diese Baugruppenzeit herangezogen. Ab der Basisversion STEP 7 V5.4 wird die CPU-Uhrzeit, die der UTC-Zeit entspricht, umgerechnet in die lokale Zeit des Engineering Systems bzw. PGs. Damit werden Zeitstempel von z.B. Einträgen im Diagnosepuffer in der entsprechende Lokalzeit des PG/PC angezeigt

Zeitstempelung von GMP-relevanten Daten Für Produktionsanlagen im GMP-Umfeld werden sowohl GMP-relevanten Prozessdaten, als auch Meldeereignisse archiviert. Die Archivierung erfolgt immer mit einem Zeitstempel. Die Archivierung der Prozesswerte wird im Bedien- und Beobachtungssystem (SIMATIC WinCC, SIMATIC WinCC flexible) durchgeführt, das den Zeitstempel des Archivierungszeitpunkts zu dem Prozesswert hinzugefügt.

Für die Archivierung der Meldeereignisse bestehen zwei Meldeverfahren, das Bitmeldeverfahren und das Meldenummernverfahren.

• Bitmeldeverfahren Eine Meldung wird von der Steuerung erkannt und über einen Bitwechsel in einer Variablen dem Bediengerät signalisiert. Der Zeitstempel der Meldung wird vom Bediengerät beim Auswerten der Variablen festgelegt.

• Meldenummernverfahren Die Steuerung überträgt eine Meldenummer (eventuell auch Meldetext) zur Anzeige einer Meldung. Dazu werden in STEP 7 Meldungen über die Meldebausteine ALARM_S/SQ/D/DQ bzw. ALARM, ALARM_8/8P projektiert. Der Zeitstempel bezieht sich auf den Zeitpunkt des Aufrufs des Alarm-Bausteins und nicht direkt auf die Entstehung des Ereignisses/Alarms.

Beim Bitmeldeverfahren sind im Zeitstempel Erfassungszyklus, Buslaufzeit und Verarbeitungszeit enthalten. Meldungen, die kürzer anstehen als der Erfassungszyklus, gehen verloren. Das Bitmeldeverfahren und die Grenzwertüberwachung kann im WinCC Einzelplatzsystem angewandt werden. Die Busbelastung ist hoch (Bediensystem pollt). In redundanten Systemen oder WinCC- und WinCC flexible-Systemen mit mehreren Bedienstationen wird für koordiniertes Quittieren und Senden das zeitfolgerichtige Melden eingesetzt.

Die Zeitstempelung über das Meldenummernverfahren ist wesentlich genauer. Die Busbelastung ist gering (AS meldet aktiv). Falls sehr hohe Anforderungen an die Genauigkeit des Zeitstempels beim Eintreten der Meldeereignisse bestehen (Zeitstempelung in der ET200M), steht für das Automatisierungssystem S7-400 das kostenpflichtige Meldebeispiel ALRM7PBT (Beitrags-ID 20614217) zur Verfügung. Dieses Beispiel zeichnet den originalen Zeitstempel beim Meldeereignis auf und puffert die auflaufenden Meldeereignisse zur Übertragung an das HMI-System WinCC.



Allerdings bestehen hinsichtlich des Meldenummernverfahrens folgende Einschränkungen:

• SIMATIC WinCC flexible unterstützt nur das Meldenummernverfahren mit den Meldebausteinen ALARM_S/SQ/D/DQ. Damit können in der momentan leistungsfähigsten CPU3xx max. 60 Meldungen und in der momentan leistungsfähigsten CPU 4xx max. 200 Meldungen erzeugt werden.

• Eine CPU4xx kann bis zu 10000 Instanzen, das bedeutet über die Meldebausteine ALARM, ALARM_8/8P bis zu 80000 Meldungen, nach dem Meldenummernverfahren an ein SIMATIC WinCC System senden.

Hinweis

Der Einsatz des Meldeverfahrens ist als Entscheidungskriterium bei der Auswahl der Hardware-Komponenten unbedingt zu beachten.



4.10 CPU Speicherung Beim Laden des Anwenderprogramms vom Programmiergerät in die CPU werden nur die Code- und Datenbausteine in den Lade- und den Arbeitsspeicher der CPU geladen. Die symbolische Operandenzuordnung (Symboltabelle) und die Bausteinkommentare bleiben im Speicherbereich des PG.

Der Speicher einer CPU ist aufgeteilt in den Ladespeicher und den Arbeitsspeicher. Um eine schnelle Bearbeitung des Anwenderprogramms zu gewährleisten und den nicht erweiterbaren Arbeitsspeicher nicht unnötig zu belasten, werden nur die Teile der Bausteine, die für die Programmbearbeitung relevant sind, in den Arbeitsspeicher geladen.

Nachfolgendes Bild zeigt das Laden des Programms in den CPU-Speicher.

4.10.1 Speicherkonzept bei S7-300 CPUs Die Gesamtgröße des Arbeitsspeichers (RAM) sowie der remanente Anteil sind CPU abhängig. Die CPU wird mit einer Micro Memory Card (MMC) als Ladespeicher ausgerüstet, auf die das Anwenderprogramm geladen wird. Wenn die Speichergröße der MMC großzügig gewählt wird, können zusätzlich die Projektdaten des kompletten STEP 7-Projekts als archivierte Datei darauf geladen werden.

Datenbausteine, die nicht ablaufrelevant sind (z. B. Rezeptdaten enthalten), können ebenso auf die MMC geladen werden. Dazu wird in den Objekteigenschaften zum Datenbaustein die Eigenschaft unlinked aktiviert.



Ein Überschreiben eines Datenbausteins, der auf der MMC abgelegt ist, ist nur über Systemfunktionen möglich. Dies sollte nicht zyklisch, sondern nur sehr sporadisch erfolgen, da für die MMC nur eine begrenzte Anzahl an Schreibzugriffen besteht.

Der Vorteil der MMC ist, dass die Daten bei einem Spannungsausfall nicht verloren gehen, obwohl die S7-300 keine Batteriepufferung hat. Runtime-Daten aus dem Arbeitsspeicher werden mit der verbleibenden Restspannung auf die MMC übertragen. Dabei wird jedoch nur die Menge an Runtime-Daten zurück geschrieben, die die Größe des ausgewiesenen remanenten Speicherbereichs der CPU zulässt.

Beim Zurückschreiben werden zuerst die Inhalte der Datenbausteine, die nicht mit Non-Retain gekennzeichnet sind, gesichert.

! Hinweis Die Größe des remanenten Speicherbereichs, der im Spannungsausfall zum Rückladen der Runtime-Daten zur Verfügung steht, ist abhängig von der ausgewählten CPU. In der Regel beträgt der remanente Speicherbereich nur die Hälfte des Arbeitsspeichers. Dies kann zu Runtime-Daten-Verlust führen.

Hinweis

Eine MMC ist für eine begrenzte Anzahl (ca. 100 000) an Schreibzugriffen ausgelegt. Jeder Ladevorgang, jeder Spannungsausfall bedeutet einen Schreibzugriff. Die Anzahl der Schreibzugriffe ist in der Regel nicht kritisch, wenn darauf geachtet wird, dass keine zyklischen Schreibzugriffe auf die MMC zugreifen. Wenn die Anzahl Schreibzugriffe abgearbeitet ist, muss die MMC durch eine neue MMC ersetzt werden. Dies kann allerdings nur spannungslos erfolgen und bedeutet Runtime-Datenverlust.

4.10.2 Speicherkonzept bei S7-400 CPUs Der Speicherausbau ist abhängig vom Typ der CPU. Der Ladespeicher kann mit einem Flash- oder RAM-Speicher erweitert werden. Wenn die Speichergröße großzügig gewählt wird, können die Projektdaten des kompletten STEP 7-Projekts als archivierte Datei darauf geladen werden.

Bei Spannungsausfall können Anwenderprogramm und Runtime-Daten im Automatisierungssystem S7-400 mit Pufferbatterien gesichert werden. Zur Pufferung wird eine Lithium-Batterien eingesetzt. Eine zweite redundante Batterie kann gesteckt werden. Die Pufferspannung wird systemseitig überwacht. Im Falle eines Fehlers in der Stromversorgung / Pufferung ruft das System den OB81 auf. (siehe STEP 7 Hilfe > Aufruf von Referenz-Hilfen > Sprachbeschreibungen, Baustein-Hilfen, …> Hilfe zu OBs)

Die S7-400 kann auch mit zwei redundanten Stromversorgungen ausgerüstet werden, z.B. eine mit 220V und eine mit 24V. Jede kann mit zwei Batterien gepuffert werden.



4.11 Sicherung / Wiederherstellung der System/Anwendersoftware Um im Notfallfall auf die erstellte Software zurückgreifen zu können, müssen während der Projektierungsphase in regelmäßigen Abständen Sicherungskopien von Softwareständen angefertigt werden. Zusätzlich wird empfohlen, von der Systempartition des Engineering Systems mit den Inhalten Betriebssystem, SIMATIC STEP 7 Basissystem, etc., eine Datensicherung zu erstellen.

Sicherung der Anwendersoftware Die Sicherung der STEP 7 Anwendersoftware kann auf verschiedene Arten durchgeführt werden:

• Über das Menü Datei > Speichern unter wird eine Kopie des STEP 7-Projekts angelegt, z. B. Sicherungskopie. Ausreichend Speicherplatz sollte zur Verfügung stehen. Regelmäßig sollte dabei auch das Kontrollkästchen mit Reorganisation aktiviert werden, wodurch der Speicherbedarf des Projekts verringert wird. Mit dem Menü Datei > Öffnen kann eine Sicherungskopie bearbeitet werden.

• Während der Engineering Phase wird empfohlen das Kontrollkästchen Beim Öffnen eines Projekts / Bibliothek automatisch archivieren zu aktivieren.

• Im SIMATIC Manager über das Menü Datei > Archivieren… Mit dieser Funktion wird das STEP 7-Projekt komprimiert archiviert. Das Tool, das zur Archivierung eingesetzt wird, kann im Menü Extras > Einstellungen > Archivieren konfiguriert werden. (Voreingestellt ist das Archivier-Programm PKZIP). Vor der Bearbeitung des STEP 7-Projekts muss eine Dearchivierung erfolgen.

Zum Archivieren ist die STEP 7 Hilfe unter Drucken und Archivieren > Archivieren von Projekten und Bibliotheken > Voraussetzungen für das Archivieren zu beachten.



• In der lizenzpflichtigen Software Version Trail (siehe Kapitel 4.5.3 „Versionierung der Anwendersoftware“) wird das STEP 7-Projekt unter einer Haupt- oder Nebenversion gesichert. Mit Version Trail kann jede Version wieder dekomprimiert werden.

•

Hinweis Zur Versionsverwaltung der STEP 7-Projekt wird die Option Version Trail empfohlen.


5 Ergänzende Software-Komponenten

5.1 Diagnostic Tools Komfortable Funktionen zur Hardware- und Software-Diagnose sind bereits in der Basissoftware STEP 7 integriert. Diese Funktionen dienen in erster Linie bei der Inbetriebnahme des Anwenderprogramms und bei der Diagnose in einem Fehlerfall.

Hardware-Diagnose Die Diagnose der Hardware wird im Basissystem STEP 7 direkt über den SIMATIC Manager oder über den Editor HW-Konfig durchgeführt. Nachfolgend werden einige Beispiele aufgeführt. In der STEP 7 Hilfe unter Diagnose sind die Diagnosemöglichkeiten ausführlich beschrieben.

• Das Menü Ansicht > Online z.B. kennzeichnet die Baugruppen mit einem aussagekräftigen Symbol. Es erfolgt ein Wechsel in die Online-Sicht des Projektes und Zugriffe auf das Zielsystem werden ermöglicht.

• Über das Menü Zielsystem > Diagnose/Einstellungen > Hardware diagnostizieren wird ein Dialog geöffnet, der den Baugruppenzustand beschreibt.

Falls sich die Baugruppe in einem fehlerhaften Zustand befindet, werden diese Fehler im Feld Status aufgelistet. Die genaue Fehlerursache kann im Register Diagnosepuffer analysiert werden.

Ergänzende Software-Komponenten


Software-Diagnose Zur Software-Diagnose bzw. Software-Test werden Variablentabellen und die Statusanzeige einzelner Bausteine verwendet. Nachfolgend werden einige Beispiele aufgeführt. In der STEP 7 Hilfe unter Testen sind die Testmöglichkeiten ausführlich beschrieben.

Variablentabellen

In Variablentabellen werden Variablen, Datenbereiche, Merker, Zeiten, Zähler beliebig zusammengestellt um deren aktuellen Werte auszulesen. Über die Steuerfunktion können die Werte manipuliert werden. Die Variablentabellen werden unter einem Namen gespeichert und sind jederzeit wieder abrufbar.

! Hinweis Die Steuerfunktion in der Variablentabelle ist sehr gefährlich und nur während der Entwicklungsphase des Anwenderprogramms erlaubt. Die Steuerfunktion sollte über die Einstellung Schreibschutz bzw. Schreib-/Leseschutz in den Objekteigenschaften der CPU in Runtime verhindert werden. (siehe auch Kapitel 4.6.1 „Zugriffsschutz auf die CPU“)



Statusbeobachtung einzelner Bausteine

Zur Beobachtung des Programmablaufs können einzelne Bausteine online betrachtet werden. Dazu wird der Baustein im Editor KOP/AWL/FUP geöffnet. Das Beobachten des Bausteins wird mit der Schaltfläche Beobachten ein/aus ab- bzw. eingeschaltet. In der Bausteindarstellung werden nun aktive Verbindungen farbig hervorgehoben und inaktive Verbindungen unterbrochen abgebildet.

! Hinweis Die Steuerfunktion im KOP/AWL/FUP-Editor ist sehr gefährlich und nur während der Entwicklungsphase des Anwenderprogramms erlaubt. Die Steuerfunktion sollte über die Einstellung Schreibschutz in den Objekteigenschaften der CPU in Runtime verhindert werden. siehe auch Kapitel 4.6.1 „Zugriffsschutz auf die CPU“)



Im On-/Offline-Vergleich wird der Baustein im Zielsystem neben dem Baustein im Projekt dargestellt. Die Gegenüberstellung erleichtert das Auffinden von Differenzen.



5.2 Simulationstools Mit dem lizenzpflichtigen Optionspaket S7-PLCSIM wird auf dem Computer bzw. dem Programmiergerät (Field PG) ein Automatisierungssystem simuliert, auf dem das laufende Programm getestet wird. Da die Simulation vollständig in der STEP 7-Software realisiert wird, ist keine S7-Hardware (CPU oder Signalbaugruppen) erforderlich. Mit der simulierten S7-CPU können Programme für S7-300 und S7-400 CPUs getestet und Fehler behoben werden.

Die Applikation bietet eine einfache Bedienoberfläche zum Überwachen und Ändern der verschiedenen Parameter, die in dem Programm verwendet werden (z. B. zum Ein- und Ausschalten von Eingängen). Außerdem können die verschiedenen Applikationen der STEP 7-Software eingesetzt werden, während das Programm von der simulierten CPU bearbeitet wird. So können beispielsweise mit der Variablentabelle Variablen überwacht und geändert werden.

Hinweis Es kann vorkommen, dass ganz neue SFB/SFC der CPUs nicht unterstützt werden. Die Aktualisierung der neuen Funktionen wird zeitversetzt in S7-PLCSIM integriert.



5.3 Simulationssoftware SIMIT Die Simulationssoftware SIMIT ermöglicht über eine Simulationsplattform einen Softwaretest ohne das man die entsprechenden Feldgeräte benötigt. SIMIT simuliert Feldgeräte und ermöglicht somit einfache Signaltests per Knopfdruck bis hin zu komplexen Tests der Antriebsebene. Zusammen mit der SPSSimulationssoftware S7-PLCSIM zur Simulation der CPU eines Automatisierungssystems lassen sich so kostengünstig Softwaretests ohne Hardware-Komponenten wie Automatisierungssystem (AS) und Feldgeräte durchführen. Auf diese Weise kann z.B. ein Factory Acceptance Tests (FAT) beim Software-Ersteller durchgeführt werden. Der Factory Acceptance Test dient dazu mögliche Fehler im Vorfeld der Inbetriebnahme zu erkennen und beheben zu können dadurch lässt sich die Inbetriebnahmezeit verkürzen.



5.4 Umverdrahtung von S7-Programmen Die Basissoftware STEP 7 unterstützt das Umverdrahten von Ein- / Ausgängen, Merkern, Zeiten, Zählern, Funktionen und Funktionsbausteinen. Bei der Umverdrahtung wird ein alter Operand gegen einen neuen Operand ersetzt. In einer Infodatei wird die durchgeführte Umverdrahtung dokumentiert.

Hinweis

Bei Symbolik führend muss mit Bausteinkonsistenz prüfen das Programm erneut übersetzt werden.




6 Unterstützende Funktionen bei der Qualifizierung

6.1 Einleitung In diesem Kapitel stehen Systemfunktionen zur Unterstützung von Qualifizierungsaktivitäten im Fokus. Diese Aktivitäten finden in der Phase „Test / Qualifizierung“ statt und werden im nachfolgend dargestellten Lebenszyklusmodell durch die Markierung im rechten Bereich der Grafik gekennzeichnet.

Das Ziel der Qualifizierung ist, den dokumentierten Nachweis zu erbringen, dass das System gemäß den Spezifikationen errichtet wurde und alle spezifizierten Anforderungen erfüllt. In der Qualifizierung werden die dafür erforderlichen Aktivitäten beschrieben, durchgeführt und abschließend bewertet. Verschiedene Standardfunktionalitäten von SIMATIC STEP 7 können unterstützend bei der Qualifizierung während IQ und OQ genutzt werden.

Unterstützende Funktionen bei der Qualifizierung


6.2 Qualifizierung von Automatisierungshardware Die Designspezifikation der eingesetzten Hardware dient der Errichtung des Systems nach detaillierten Vorgaben, deren Einhaltung im Verlauf der späteren Systemtests geprüft werden kann und muss. In der Designspezifikation wird die gesamte eingesetzte Hardware mit Angaben wie Bestellnummer, Firmware- / Ausgabestand, Seriennummer, Bestimmungsort etc. beschrieben. Die Komponenten wie eingesetzte CPUs, Ein- und Ausgangskarten, Schnittstellen zu Fremdsystemen, etc. werden nachfolgend aufgegliedert.

Qualifizierung von Feldgeräten Bei der Qualifizierung von Feldgeräten muss darauf geachtet werden, dass die Vorgaben der Hardwaredesignspezifikation umgesetzt wurden. Hieraus erfolgt die Überprüfung der:

Hersteller Bestellnummer Seriennummer Funktion des Feldgerätes Bestimmungsort Messstellenbezeichnung Anschlussart elektrisch / Bustype Anschlussart physikalisch Adressnummer Einheit Messbereich

Hinweis Die Überprüfung erfolgt visuell am Feldgerät.



Qualifizierung der Automatisierungshardware Bei der Qualifizierung der Automatisierungshardware muss darauf geachtet werden, dass die Vorgaben der Hardwaredesignspezifikation umgesetzt wurden. In der Hardware-Konfiguration von SIMATIC STEP 7 müssen alle Hardware-Komponenten wie in der Designvorgabe spezifiziert konfiguriert sein. Hierzu zählen:

• Anzahl an Baugruppenträgern

• Überprüfung der eingesetzten Hardware-Komponenten (CPU, CP, etc.)

• Anzahl an Dezentralen Peripheriestationen

• Schnittstellen zu Fremdsystemen

• Überprüfung der Bestellnummern der eingesetzten Hardware

• Adressbeschreibung

• Symbolische Benennung von Eingängen/Ausgängen

• Etc.

Hinweis Die Hardware-Konfiguration kann ausgedruckt und als Qualifizierungsnachweis (IQ/OQ) der installierten Hardware-Komponenten genutzt werden. Eine visuelle Überprüfung der installierten Hardware kann parallel erfolgen. Die eingesetzte Hardware muss deckungsgleich mit der Schaltschrankdokumentation sein.

Qualifizierung der Netzwerkstruktur Bei der Qualifizierung der Netzwerkstruktur muss darauf geachtet werden, dass die Vorgaben der Hardwaredesignspezifikation umgesetzt wurden. In der SIMATIC NetPro Konfiguration von SIMATIC STEP 7 müssen alle Verbindungen konfiguriert sein. Hierzu zählen:

• Name von: Station, PC, AS, Clients etc.

• Kommunikationsbaugruppe, Art der Verbindung und Kommunikationspartner (Ethernet, PROFIBUS, Seriell etc.)

• MAC-Adresse (Bei der Nutzung des ISO-Protokolls am Analgenbus)

• TCP/IP-Adresse und Subnetmask (Bei der Nutzung von Clients)

• PROFIBUS-Adressen

• Etc.

Hinweis Die Netz- Konfiguration kann ausgedruckt und als Qualifizierungsnachweis (IQ/OQ) der konfigurierten Netzwerkstruktur genutzt werden. Eine visuelle Überprüfung der konfigurierten Netzwerkstruktur kann parallel erfolgen.



6.3 Qualifizierung von Automatisierungssoftware

6.3.1 Qualifizierung von Standard Software Bei der Qualifizierung der eingesetzten Standard Software muss darauf geachtet werden, dass die Vorgaben der Softwaredesignspezifikation umgesetzt wurden. Hierzu zählen:

• Betriebssystem des Engineering Systems

• SIMATIC STEP 7 Standardbasispakete (Engineering System) und Optionspakete (CFC, SCL, SIMATIC Logon, Version Trail, DOCPRO, etc.)

• Standardbibliotheken

Hinweis (Betriebssystem)

Die Überprüfung von installierter Software kann durch Betriebssystem -Funktionen erfolgen. Die Informationen findet man in der Systemsteuerung > Software. Hier werden alle installierten Software-Komponenten angezeigt. Ein Screen-Shot kann ausgedruckt und für die Qualifizierung (IQ/OQ) genutzt werden.

Hinweis (SIMATIC-Software)

Die Überprüfung von installierter SIMATIC Software kann durch das Software Tool "Installierte Software" realisiert werden. Das Tool informiert über die aktuelle installierte SIMATIC-Software auf dem Rechner. Die installierten Komponenten können ausgedruckt und für die Qualifizierung (IQ/OQ) genutzt werden.

6.3.2 Installierte SIMATIC-Software STEP 7 Für das Engineering System, das zur Konfiguration der Automatisierungssysteme eingesetzt wurde, ist eine Dokumentation der installierten Software-Pakete anzufertigen. Die installierte SIMATIC Software wird unter Programme > SIMATIC > Produkt-Hinweise > Installierte Software ausführlich dokumentiert.

Die Auflistung gibt Aufschluss über die installierten Softwareprodukte, Software-Komponenten und DLLs auf dem lokalen Rechner. Diese Informationen können z.B. für die Aufnahme der installierten Software in der Installationsqualifizierung genutzt werden.



6.3.3 Installierte Lizenzen von SIMATIC STEP 7 Das Programm Automation License Manager gibt Auskunft über die aktuell installierten Lizenzen auf dem Engineering System. Hierzu ist der Automation License Manager zu öffnen. In der Explorerleiste ist auf der linken Seite die Partition des PCs anzuwählen, auf der die Lizenzen installiert sind. In der rechten Seite des Fensters werden daraufhin alle verfügbaren SIMATIC Lizenzen des Systems angezeigt.

In Verbindung mit der Option SIMATIC Logon kann für die Applikation Automation License Manager ein Zugriffsschutz aktiviert werden. Dazu wird im Menü Datei > Einstellungen > SIMATIC Logon Zugriffsschutz aktivieren angewählt.

Im Menü Datei > Benutzerverwaltung werden die Benutzer den entsprechenden Rollen zugewiesen. Mit einer Rolle z.B. Lizenzgeber oder Haupt-Anwender sind bestimmte Funktionen verbunden, die der zugewiesene Benutzer in der Applikation ausführen darf.

Die Benutzer / Benutzergruppen müssen zuvor in der Windows Benutzerverwaltung angelegt werden.


Beim Starten des Automation License Managers wird der SIMATIC Logon Service zum Anmelden eines Benutzers geöffnet. SIMATIC Logon kontrolliert Benutzer-ID und Passwort.

Hinweis

Die installierten Lizenzen müssen den in der Spezifikation definierten Vorgaben entsprechen. Die installierten Lizenzen können ausgedruckt und als Nachweis für die Qualifizierung (IQ/OQ) genutzt werden.

6.3.4 Qualifizierung der Anwendersoftware Bei der Qualifizierung der Anwendersoftware muss darauf geachtet werden, dass die Vorgaben der Softwaredesign – Spezifikation umgesetzt wurden. Es müssen Testbeschreibungen (z.B. für FAT/SAT) mit dem Betreiber abgestimmt und generiert werden. Diese Testbeschreibungen müssen individuell auf die Softwaredesignvorgaben erstellt werden.

Folgende Mindestinhalte müssen überprüft und getestet werden und können als Referenz für die Qualifizierung genutzt werden:

• Überprüfung des Namens der Anwendersoftware

• Überprüfung der Technologischen Hierarchie (Anlage, Teilanlage, technische Einrichtung, Einzelsteuerelement etc.)

• Software Modul Test (Typical Test)

• Überprüfung der Kommunikation zu anderen Teilnehmern (Fremdsteuerungen, MES-Systeme etc.)

• Überprüfung aller Ein- und Ausgänge

• Überprüfung aller Control Module (Einzelsteuerebene)

• Überprüfung aller Equipment Phasen und Equipment Operationen (Technische Funktionen)

• Überprüfung der Zusammenhänge von Betriebsarten (HAND/AUTOMATIK- Umschaltungen, Verriegelungen, Start, Läuft, Angehalten, Abbrechend, Beendet etc.)

• Überprüfung von Messstellenbezeichnungen

• Überprüfung der Visualisierungsstruktur (R&I Darstellung)

• Überprüfung der Bedienphilosophie (Zugangskontrolle, Gruppenrechte, Benutzerrechte)

• Überprüfung der Archivierungskonzepte (Umlaufarchive, Langzeitarchive)

• Überprüfung des Meldekonzepts

• Überprüfung der Trends, Kurven

• Überprüfung der Uhrzeitsynchronisation

Leitfaden zur Durchführung von Automatisierungsprojekten im GMP Umfeld A5E01100598-01 Index-1

Index

2 21 CFR Part 11.............................................. 1-7

A Adressierung ................................................. 4-9

Ä Änderung der Systemsoftware .................... 4-18 Änderungslenkung (Change Control) ............ 3-8 Änderungsprotokoll...................................... 4-27

A Anwender-Lastenheft .................................... 1-4 Audit Trail .................................................... 4-36 Audit-Trail .................................................... 2-12 Austausch / Änderung der

Hardware / Firmware ............................... 4-20

B Backup ........................................................ 2-14 Backup Anwendersoftware.......................... 2-15 Backup Prozessdaten.................................. 2-16 Baugruppe - Austausch ............................... 4-21 Baustein-Container........................................ 4-6 Bausteineigenschaften .................................. 4-7 Bausteinschutz ............................................ 4-33 Bausteintitel und Bausteinkommentar ......... 4-13 Benutzer-ID .......................................... 2-9, 2-11 Benutzerverwaltung....................................... 2-8 Biometrische Systeme................................... 2-9

C Change Control .................................... 2-6, 4-26 Chipkarte ....................................................... 2-9 Code-Review............................................... 4-10 CPU Speicherung........................................ 4-41

D Design Spezifikation - Entwurfsspezifikation . 1-4 Diagnostic Tools ............................................ 5-1 DOCPRO..................................................... 4-15

E Elektronische Unterschrift............................ 2-10 EU-GMP-Leitfaden ................................. 1-7, 1-8

F FAT................................................................ 1-5 FDA ............................................................... 1-7 Firmware - Aktualisierung............................ 4-20 Fremdkomponente ...................................... 2-17

G GAMP..................................................... 1-7, 1-8 GMP-Anforderungen ..................................... 2-1

H Hardware Auswahlkriterien............................ 3-3 Hardware Dimensionierung ........................... 3-2 Hardware-Diagnose ...................................... 5-1 Hardware-Kategorisierung............................. 2-2

I Implementierung............................................ 1-5 integriertes HMI-System.............................. 4-11

K Konfigurationskennzeichnung ....................... 2-6 Konfigurationskontrolle .................................. 2-6 Konfigurationsmanagement.................. 2-5, 4-18

L Lebenszyklusmodell ...................................... 1-1

M Meldungsverarbeitung................................... 4-9

N NAMUR .................................................. 1-7, 1-8 Netzwerktitel und Netzwerkkommentar ....... 4-13

Index

Leitfaden zur Durchführung von Automatisierungsprojekten im GMP Umfeld Index-2 A5E01100598-01

O Online / Offline Vergleich............................. 4-26 Online / Offline-Vergleich............................... 3-9

P Passwort............................................... 2-9, 2-11 Pflichtenheft................................................... 1-4 Programmierungsvorgehensweise ................ 4-5 Projektierung - Grundlagen............................ 4-4

Q Qualifizierung.......................................... 1-5, 6-1 Qualifizierung Anwendersoftware .................. 6-6 Qualifizierung Automatisierungshardware ..... 6-3 Qualifizierung Feldgeräte .............................. 6-2 Qualifizierung Netzwerkstruktur..................... 6-3 Qualifizierung Standard Software .................. 6-4 Qualifizierungsbericht .................................... 1-5 Qualifizierungsplan ........................................ 1-3 Qualitäts- und Projektplan ...................... 1-3, 1-9

R Regeln und Konventionen ............................. 4-9 Rücklesen von ausgelagerten Daten........... 2-17

S SAT ............................................................... 1-5 Sicherung / Wiederherstellung der

System/Anwendersoftware ...................... 4-43 SIMATIC Logon ............................................. 3-8 SIMIT............................................................. 5-6 Simulationstools ............................................ 5-5 Software - Basis Engineering ........................ 3-5 Software – Zusatzpakete Engineering.... 3-5, 4-5 Software – Zusatzpakete

für GMP-Konformität.................................. 3-8 Software- Verriegelungen/Sicherheit ........... 4-10

Softwareaktualisierung ................................ 4-20 Software-Diagnose........................................ 5-2 Software-Dokumentation ............................. 4-13 Software-Erstellung ....................................... 4-4 Software-Installation...................................... 4-3 Softwarekategorisierung.............................. 1-10 Software-Kategorisierung .............................. 2-3 Software-Kategorisierung von STEP 7.......... 4-2 Software-Pakete - erforderliche /

optionale Pakete........................................ 3-5 Spezifikation .................................................. 1-3 Symbolischer Name .................................... 4-14 Systemspezifikation....................................... 3-1

T Typicals ......................................................... 2-7

U Uhrzeitsynchronisation ....................... 2-13, 4-37 Umverdrahtung S7 Programmen................... 5-7 Update, Service Pack, Hotfix....................... 4-18 Upgrade (Migration) .................................... 4-19

V Validierungsbericht ........................................ 1-6 Validierungsplan............................................ 1-3 Version Cross Checker.................................. 3-9 Version Trail .................................................. 3-8 Versionierung .............................. 3-8, 4-24, 4-34 Versionierung - Bausteine ........................... 4-23 Versionierung - Projekt ................................ 4-24 Versionierung der Anwendersoftware ......... 4-22 Versionskontrolle........................................... 2-6

Z Zeilenkommentar......................................... 4-14 Zeitstempelung............................................ 4-39 Zugriffschutz.................................................. 3-8 Zugriffsschutz ....................................... 2-8, 4-30 Zugriffsschutz - CPU ................................... 4-30 Zugriffsschutz auf STEP 7-Projekt .............. 4-31

Documents

Einleitung Automatisierten Systemen SIMATIC STEP 7 V5 · PDF fileEinleitung Leitfaden zur Durchführung von Automatisierungsprojekten im GMP Umfeld iv A5E01100598-01 Gültigkeitsbereich