GMP-Engineering Leitfaden zur Durchführung von

Transcription

s
Einleitung
Inhaltsverzeichnis
SIMATIC STEP 7 V5.4
GMP-Engineering Handbuch
Leitfaden zur Durchführung
von Automatisierungsprojekten
im GMP Umfeld
Voraussetzung für die
Projektierung von
Automatisierten Systemen
im GMP-Umfeld
1
Anforderungen an
Automatisierte Systeme im
GMP-Umfeld
2
Systemspezifikation
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
04/2007
A5E01100598-01
3
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.
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
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, Wartungsund 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.
Leitfaden zur Durchführung von Automatisierungsprojekten im GMP Umfeld
A5E01100598-01
iii
Einleitung
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
iv
A5E01100598-01
Einleitung
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:
pharma.aud@siemens.com
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:
•
Fax:
+ 49 180 5050 222
+ 49 180 5050 223
Weitere Informationen zu unserem Technical Support finden Sie im Internet unter
http://www.siemens.de/automation/service
A5E01100598-01
v
Einleitung
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:
vi
•
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.
A5E01100598-01
Inhaltsverzeichnis
Einleitung
1
Inhaltsverzeichnis
1
Voraussetzung für die Projektierung von Automatisierte Systemen im GMP-Umfeld 1-1
1.1
1.2
1.3
1.4
1.5
2
Lebenszyklusmodell ...............................................................................................1-1
Gesetze und Richtlinien..........................................................................................1-7
Verantwortlichkeiten................................................................................................1-9
Genehmigung und Änderungsverfahren ................................................................1-9
Software-Kategorisierung von Leitsystemen ........................................................1-10
Anforderungen an automatisierte Systeme im GMP-Umfeld
2.1
2.2
2.3
2.3.1
2.3.2
2.3.2.1
2.3.2.2
2.4
2.4.1
2.4.2
2.4.3
2.5
2.5.1
2.5.2
2.5.3
2.6
2.6.1
2.6.2
2.6.3
2.7
2.8
2.9
2.9.1
2.9.2
2.10
2.11
3
vii
2-1
Hardware-Kategorisierung......................................................................................2-2
Software-Kategorisierung .......................................................................................2-3
Konfigurationsmanagement....................................................................................2-5
Konfigurationskennzeichnung.................................................................................2-6
Konfigurationskontrolle ...........................................................................................2-6
Versionskontrolle ....................................................................................................2-6
Änderungslenkung (Change control) ......................................................................2-6
Software-Erstellung.................................................................................................2-7
Verwendung von Typicals zur Programmierung.....................................................2-7
Kennung von Software-Modulen / Typicals ............................................................2-7
Änderung von Software-Modulen / Typicals...........................................................2-7
Zugriffsschutz und Benutzerverwaltung .................................................................2-8
Anwendung des Zugriffsschutzes auf ein System..................................................2-8
Anforderungen an die Benutzer-ID und Passwort ..................................................2-9
Chipkarten und biometrische Systeme ...................................................................2-9
Elektronische Unterschriften.................................................................................2-10
Konventionelle elektronische Unterschriften ........................................................2-10
Elektronische Unterschriften auf biometrischer Basis ..........................................2-11
Sicherheitsmassnahmen zu Benutzer-IDs/Passwörtern ......................................2-11
Audit-Trail..............................................................................................................2-12
Uhrzeitsynchronisation .........................................................................................2-13
Datensicherung (Backup) .....................................................................................2-14
Anwendersoftware ................................................................................................2-15
Prozessdaten ........................................................................................................2-16
Rücklesen von ausgelagerten Daten....................................................................2-17
Einsatz von Fremdkomponenten ..........................................................................2-17
Systemspezifikation
3.1
3.2
3.3
3.3.1
3.3.2
3.3.3
3.3.3.1
3.3.3.2
3-1
Dimensionierung der Hardware ..............................................................................3-2
Auswahlkriterien an Hardware................................................................................3-3
Erforderliche / optionale Software-Pakete ..............................................................3-5
Basis Software Engineering....................................................................................3-5
Zusatz Software Engineering..................................................................................3-5
Zusatzsoftware-Pakete zur Unterstützung der GMP-Konformität ..........................3-8
Zugriffschutz ...........................................................................................................3-8
Versionierung, Änderungslenkung (Change Control) , Audit Trail .........................3-9
A5E01100598-01
vii
Inhaltsverzeichnis
4
Leitfaden für die Implementierung von SIMATIC S7 im GMP Umfeld
4.1
4.2
4.3
4.4
4.4.1
4.4.1.1
4.4.1.2
4.4.1.3
4.4.2
4.4.3
4.5
4.5.1
4.5.2
4.5.3
4.5.4
4.6
4.6.1
4.6.2
4.6.3
4.7
4.8
4.9
4.10
4.10.1
4.10.2
4.11
5
viii
5-1
Diagnostic Tools .....................................................................................................5-1
Simulationstools......................................................................................................5-5
Simulationssoftware SIMIT .....................................................................................5-6
Umverdrahtung von S7-Programmen.....................................................................5-7
Unterstützende Funktionen bei der Qualifizierung
6.1
6.2
6.3
6.3.1
6.3.2
6.3.3
6.3.4
Index
Einleitung ................................................................................................................4-1
Software-Kategorisierung von STEP 7 ...................................................................4-2
Software-Installation ...............................................................................................4-3
Grundlagen zur Projektierung.................................................................................4-4
Software-Erstellung.................................................................................................4-4
Vorgehensweise bei der Programmierung .............................................................4-5
Regeln und Konventionen ......................................................................................4-9
Software-Verriegelungen/Sicherheit .....................................................................4-10
Integriertes HMI-System .......................................................................................4-11
Software-Dokumentation ......................................................................................4-13
Konfigurationsmanagement..................................................................................4-18
Änderung der Systemsoftware .............................................................................4-18
Austausch / Änderung der Hardware / Firmware .................................................4-20
Versionierung der Anwendersoftware ..................................................................4-22
Änderungslenkung (Change Control) ...................................................................4-26
Zugriffsschutz........................................................................................................4-30
Zugriffsschutz auf die CPU ...................................................................................4-30
Zugriffsschutz auf STEP 7-Projekt........................................................................4-31
Schutzmaßnahmen in der Software .....................................................................4-33
Audit Trail..............................................................................................................4-36
Uhrzeitsynchronisation .........................................................................................4-37
Zeitstempelung .....................................................................................................4-39
CPU Speicherung .................................................................................................4-41
Speicherkonzept bei S7-300 CPUs ......................................................................4-41
Speicherkonzept bei S7-400 CPUs ......................................................................4-42
Sicherung / Wiederherstellung der System/Anwendersoftware ...........................4-43
Ergänzende Software-Komponenten
5.1
5.2
5.3
5.4
6
4-1
6-1
Einleitung ................................................................................................................6-1
Qualifizierung von Automatisierungshardware .......................................................6-2
Qualifizierung von Automatisierungssoftware ........................................................6-4
Qualifizierung von Standard Software ....................................................................6-4
Installierte SIMATIC-Software STEP 7 ...................................................................6-4
Installierte Lizenzen von SIMATIC STEP 7 ............................................................6-5
Qualifizierung der Anwendersoftware.....................................................................6-6
Index-1
A5E01100598-01
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
A5E01100598-01
1-1
Voraussetzung für die Projektierung von Automatisierte Systemen im GMP-Umfeld
Legende für das Lebenszyklusmodell
1-2
Abkürzung
Beschreibung
VP
Validierungsplan (Validation Plan 1)
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.
A5E01100598-01
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 verfahrenstechnischen 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 AnwenderLastenheft 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.
A5E01100598-01
1-3
Die Funktions - und Designspezifikationen bilden gleichzeitig die Grundlage für
spätere Tests im Rahmen der Qualifizierung bzw. Validierung. In den Funktionsund 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.
•
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.
•
1-4
einer Hardware-Entwurfsspezifikation" und GAMP®4, Anhang D4 "BeispielVorgehensweise für die Erstellung von Software-Entwurfsspezifikationen und
Softwaremodul-Entwurfsspezifikationen".
A5E01100598-01
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 DokumentenManagement".
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.
A5E01100598-01
1-5
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
•
1-6
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.
A5E01100598-01
1.2
Gesetze und Richtlinien
Zur Projektierung von validierungspflichtigen Automatisierten Systemen im GMPUmfeld 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 /
Titel
Organisation
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
Gesetz /
Geltungsbereich
Empfehlung
Gesetz
Hersteller und
Importeure von
Arzneimitteln für
den USamerikansichen
Markt
21 CFR Part 211
US FDA
Current good
manufacturing practice for
finished pharmaceuticals
Annex 11 zum
EU-GMPLeitfaden
European
Commission
Directorate
General III
Computer-aided systems
Richtlinie
Europa
Annex 18 zum
EU-GMPLeitfaden
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
Empfehlung
NE 71
NAMUR
Betreiben und Betreuen
validierter Anlagen
Empfehlung
Europa
NAMUR
Empfehlung
NE 72
NAMUR
Validierungsunterstützung Empfehlung
bei Einsatz von
Leitsystemen
Europa
Hinweis
Basis für die Grundlage dieses Handbuches sind die Anforderung der GAMP ® 4
und US 21 CFR Part 11.
A5E01100598-01
1-7
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 “Interessengemeinschaft 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:
1-8
•
NE 58 "Abwicklung von qualifizierungspflichtigen PLT-Projekten"
•
NE 71 "Betreiben und Betreuen validierter Anlagen"
•
NE 72 "Validierungsunterstützung bei Einsatz von Leitsystemen"
A5E01100598-01
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 AsBuilt-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.
A5E01100598-01
1-9
1.5
Software-Kategorisierung von Leitsystemen
Wie in Kapitel 2.2 "Software-Kategorisierung" und Kapitel 4.2 "SoftwareKategorisierung 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.
1-10
A5E01100598-01
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.
A5E01100598-01
2-1
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
A5E01100598-01
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äftsund Herstellungsprozesse ermöglichen. Hierzu sind vorkonfektionierte SoftwareModule 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.
A5E01100598-01
2-3
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.
1
2-4
2
3
4
5
Software
Kategorie
A5E01100598-01
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.
A5E01100598-01
2-5
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.
2-6
•
Software-Versionierung
•
Vorgaben wie Programmierrichtlinien, Namenskonventionen etc.
•
Gewährleistung der Nachvollziehbarkeit von Programmcode-Änderungen
•
Eindeutige Kennzeichnung der Software und aller darin enthaltenen
Komponenten
A5E01100598-01
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)".
A5E01100598-01
2-7
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.
!
2-8
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.
A5E01100598-01
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:
2.5.3
•
Mindestlänge des Passwortes
•
Verwendung von numerischen und alphanumerischen Zeichen
•
Verwendung von Groß- und Kleinbuchstaben
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.
A5E01100598-01
2-9
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.
!
2.6.1
Hinweis
Beim Export von Pharmazeutika in die USA müssen die Vorschriften gemäß 21
CFR Part 11 der FDA beachtet werden.
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-10
A5E01100598-01
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
A5E01100598-01
2-11
2.7
Audit-Trail
Das Audit-Trail ist ein systemseitiger Kontrollmechanismus, der die Nachvollziehbarkeit 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 AuditTrail 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-12
A5E01100598-01
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.
A5E01100598-01
2-13
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 SoftwareSicherungen (z. B. Anwendersoftware, Partitionsimage) und Archivdatensicherungen.
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-14
A5E01100598-01
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.
A5E01100598-01
2-15
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-16
A5E01100598-01
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.
A5E01100598-01
2-17
2-18
A5E01100598-01
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
A5E01100598-01
3-1
Systemspezifikation
3.1
•
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
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.
3-2
A5E01100598-01
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 S7300 / 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)
A5E01100598-01
3-3
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 PCbased 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.
3-4
A5E01100598-01
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 PCbasierte 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
A5E01100598-01
3-5
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.
3-6
A5E01100598-01
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)
A5E01100598-01
3-7
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 PIDAlgorithmus
•
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 IPAdresse 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“).
3-8
A5E01100598-01
Systemspezifikation
3.3.3.2
Versionierung, Änderungslenkung (Change Control) , Audit Trail
Version Trail
Die lizenzpflichtige Software Version Trail wird zur Versionierung der STEP 7Projekte 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 7Projekte. 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.
A5E01100598-01
3-9
Systemspezifikation
3-10
A5E01100598-01
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.
A5E01100598-01
4-1
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-2
A5E01100598-01
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 LiesmichDatei unter Start > SIMATIC > Produkt-Hinweise auf der Produkt-CD
dokumentiert.
Der Anschluss an das Automatisierungssystem erfolgt entweder über die MPISchnittstelle, 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.
A5E01100598-01
4-3
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 S7Verbindungen) 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
A5E01100598-01
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.
A5E01100598-01
4-5
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.
4-6
A5E01100598-01
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.
A5E01100598-01
4-7
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/FUPEditor für die Programmerstellung.
4-8
A5E01100598-01
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.
A5E01100598-01
4-9
•
4.4.1.3
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 KonfigurationsManagement) 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,
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 NotAus 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-10
A5E01100598-01
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 GMPHandbuch 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.
A5E01100598-01
4-11
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-12
A5E01100598-01
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.
A5E01100598-01
4-13
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.
4-14
A5E01100598-01
DOCPRO
Mit der lizenzpflichtigen Option DOCPRO kann ein Anlagenbuch komfortabel und
konsistent einschließlich Versionierung erstellt werden.
A5E01100598-01
4-15
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:
4-16
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
A5E01100598-01
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.
A5E01100598-01
4-17
4.5
Konfigurationsmanagement
STEP 7 ist das Basispaket zur Konfigurierung und Programmierung von SIMATICAutomatisierungssystemen. Die in STEP 7 integrierten SIMATICProgrammiersprachen 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 Versionsund Ä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.
4-18
A5E01100598-01
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.
A5E01100598-01
4-19
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:
4.5.2
•
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
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.
4-20
A5E01100598-01
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&MFunktionen 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.
A5E01100598-01
4-21
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.
4-22
A5E01100598-01
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.
A5E01100598-01
4-23
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.
4-24
A5E01100598-01
Im SIMATIC Manager kann zur Archivierung / Dearchivierung eines STEP 7Projekts 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.
A5E01100598-01
4-25
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.
4-26
A5E01100598-01
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
A5E01100598-01
4-27
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-28
A5E01100598-01
A5E01100598-01
4-29
4.6
Zugriffsschutz
Ein Zugriffsschutz kann sowohl für den Zugriff auf die CPU, als auch für das STEP
7-Projekt eingerichtet werden.
!
4.6.1
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.
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.
4-30
A5E01100598-01
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.
A5E01100598-01
4-31
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-32
A5E01100598-01
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 HardwareKonfiguration (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.
A5E01100598-01
4-33
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 S7Offline-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- / OfflineVergleich einzelner Bausteine (Kapitel 4.5.4 Änderungslenkung (Change
Control)) oder Version Cross Checker in Verbindung mit CFC (Kapitel 3.3.3.2
„Versionierung, Änderungslenkung“)
4-34
A5E01100598-01
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.
A5E01100598-01
4-35
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-36
A5E01100598-01
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.
A5E01100598-01
4-37
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-38
A5E01100598-01
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 AlarmBausteins 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.
A5E01100598-01
4-39
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-40
A5E01100598-01
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.
A5E01100598-01
4-41
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-42
A5E01100598-01
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 7Projekts 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.
A5E01100598-01
4-43
•
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.
4-44
A5E01100598-01
5
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.
A5E01100598-01
5-1
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.
!
5-2
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“)
A5E01100598-01
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 abbzw. 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“)
A5E01100598-01
5-3
Im On-/Offline-Vergleich wird der Baustein im Zielsystem neben dem Baustein im
Projekt dargestellt. Die Gegenüberstellung erleichtert das Auffinden von
Differenzen.
5-4
A5E01100598-01
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 S7400 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.
A5E01100598-01
5-5
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-6
A5E01100598-01
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.
A5E01100598-01
5-7
5-8
A5E01100598-01
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.
A5E01100598-01
6-1
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.
6-2
A5E01100598-01
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 HardwareKomponenten 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.
A5E01100598-01
6-3
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, SoftwareKomponenten 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-4
A5E01100598-01
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.
A5E01100598-01
6-5
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:
6-6
•
Ü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/AUTOMATIKUmschaltungen, 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
A5E01100598-01
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
A5E01100598-01
Index-1
Index
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
T
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
Index-2
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
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
A5E01100598-01

GMP-Engineering Leitfaden zur Durchführung von

Transcription

Similar documents

SIMATIC WinCC Open Architecture

SIMATIC WinCC Open Architecture

SIMATIC STEP 7 im Totally Integrtaed Automation Portal

KPM Königliche Porzellan Manufaktur, Berlin

How-To-Do -Konfiguration eines CC03 mit dem Hardware

Kurze AbschlÃ¤ge bewirken Gutes: ChariTEE

Neue Funktionalitäten des TIA-Portal V13 SP1

How-To-Do Ethernet-Konfiguration der CPU 31xNET mit dem SIMATIC Manager von Siemens

Klein, stark und einfach

Leitfaden Parkraumbewirtschaftung

Engineering Manual PCS 7

SIMATIC S7-1200 Basic Controller im TIA Portal

Kontakt Ihr Weg zu uns - Hospital zum heiligen Geist

des Leitfadens als PDF

Stadtentwicklungsplan Verkehr Berlin

gewalt gegen Kinder und jugendliche

Stadtentwicklungsplan Verkehr Berlin

Best Practice Leitfaden Development

MANUAL DIPLOMARBEIT Leitfaden für die Erstellung der Disposition für die Diplomarbeit

MANUAL DIPLOMARBEIT Leitfäden für die Erstellung der 1 Disposition

Katastrophenmedizin - Bundesamt für Bevölkerungsschutz und

siwarex fta