APROL R 4.0 D1 System Handbuch - B&R Industrial Automation

APROL R 4.0 D1 System Handbuch

Inhaltliche Änderungen dieses Handbuches behalten wir uns ohne Ankündigung vor. Die Bernecker + Rainer Industrie-Elektronik Ges.m.b.H. haftet nicht für technische oder drucktechnische Fehler und Mängel in diesem Handbuch. Außerdem übernimmt die Bernecker + Rainer Industrie-Elektronik Ges.m.b.H. keine Haftung für Schäden, die direkt oder indirekt auf Lieferung, Leistung und Nutzung dieses Materials zurückzuführen sind. Wir weisen darauf hin, dass die in diesem Dokument verwendeten Soft- und Hardware-Bezeichnungen und Markennamen der jeweiligen Firmen dem allgemeinen warenzeichen-, marken- oder patentrechtlichen Schutz unterliegen. Vorliegende Dokumentation D1 System Handbuch (Version 4.06 / 30.04.2014) bezieht sich auf APROL R 4.0

2014 Bernecker + Rainer Industrie-Elektronik Ges.m.b.H. Die Handbuchgruppe Extended Engineering enthält folgende Handbücher D1 System Handbuch D2 System API D3 Gateway Editor D4 Backup & Recovery unter der Bestellnummer: MAAPEENG40-GER

i

Inhaltsverzeichnis

D1 System Handbuch V4.06

1 Sammlung zum APROL-System 1-1

1.1 Warum Zeitsynchronisation 1-1 1.1.1 Zeitsynchronisation über XNTP 1-1

1.2 Webserver und Webbrowser 1-2 1.2.1 Interventionstexte für Alarme 1-2 1.2.1.1 Vorteile durch Einbinden von PHP4 und Flash 1-3

1.2.2 Eigene Projektdokumentation 1-4 1.3 Allgemeines zum SNMP-Mechanismus 1-5

1.3.1 Konfiguration und Benutzung der SNMP-Clients 1-5 1.3.2 Erstellen der SNMP-Bausteine 1-7 1.3.3 Erstellen des Scripts 1-10

1.4 Systembefehle und -programme 1-12 1.5 Systembefehle 1-13

1.5.1 AprolCmd 1-13 1.5.2 GetEnvi 1-13 1.5.3 ps 1-14 1.5.4 Datenbankoptimierung 1-15

1.6 APROL Systemprogramme 1-17 1.6.1 Iosys-Tools 1-17 1.6.2 Erweiterung aller Iosys-Tools für Multi Runtime-Systeme 1-17 1.6.2.1 Aufrufoptionen 1-17 1.6.2.2 Verarbeitung 1-19 1.6.2.3 IosStat 1-20 1.6.2.4 IosLsClients 1-22 1.6.2.5 IosLsObjects 1-24 1.6.2.6 IosEv 1-27 1.6.2.7 IosInOut 1-32 1.6.2.8 pio 1-36

1.6.3 Erklärungen zu Vsets, Vts und Statusflags einer PV 1-38 1.6.3.1 Vset 1-39 1.6.3.2 Vt 1-39 1.6.3.3 Statusflags einer PV 1-39

1.7 Besonderheiten 1-40 1.7.1 Linux-Benutzer aprolsys 1-40 1.7.1.1 Die Datei rhosts und aprolsys 1-40

1.8 Systemvariablen 1-41 1.8.1 Systemvariablen für Anwendungen 1-41 1.8.2 Systemvariable zur Überwachung des Redundanz-Status 1-44 1.8.3 Systemvariablen für Speicher und Festplattenkapazität 1-44 1.8.4 Systemvariablen für die CPU des PC 1-49 1.8.5 Systemvariablen für Prozesse im Betriebsystem 1-50

ii

1.8.6 Systemvariablen für Zeiten im Prozessleitsystem 1-51 1.8.7 Systemvariablen für die Lizenzierung 1-53 1.8.8 Systemdienst 'ApcHwInfo' 1-53 1.8.8.1 Konfiguration des ApcHwInfo 1-53 1.8.8.2 Modul-unabhängige Variablen 1-55 1.8.8.3 Variablen für die Module 1-56 1.8.8.4 Variablen für das CPU-Modul 1-56 1.8.8.5 Variablen für das Lüfter-Kit (optional) 1-57 1.8.8.6 Variablen für das Einschubmodul1 (optional) 1-57 1.8.8.7 Variablen für das Einschubmodul2 (optional) 1-57 1.8.8.8 Variablen der Schnittstellenmodule (optional) 1-57 1.8.8.9 Variablen für die Speichermodule1 und 2 1-58 1.8.8.10 Variablen für die Buseinheit 1-58 1.8.8.11 Variablen für die SystemUnit 1-59 1.8.8.12 Variablen für das DisplayLink 1-59 1.8.8.13 Variablen für das Panel 0 bis 15 1-59 1.8.8.14 Variablen des PPC800-/APC810-Netzteils 1-60 1.8.8.15 Variablen für die Unterbrechungsfreie Stromversorgung (optional) 1-60 1.8.8.16 Besonderheiten für den PPC800 / APC810 1-60

1.9 InaConnect 1-60 1.9.1 InaConnect in der Kommandoshell 1-61 1.9.1.1 Verbindung über Profibus 1-63 1.9.1.2 Verbindung über Ethernet 1-64 1.9.1.3 Serielle Verbindung 1-64 1.9.1.4 InaConnect für Routing 1-65

1.9.2 InaConnect als Kommando (Aufruf) 1-66

2 Beschreibung zur UTF8StringAPI 2-1

2.1 Motivation 2-1 2.2 Von ASCII zu UTF8 2-1 2.3 UTF8 Kodierung 2-2 2.4 Funktionsbeschreibung zum Datentyp STRING 2-3

2.4.1 UTF8_getAPIVersion 2-4 2.4.2 UTF8_LengthInCharacters 2-4 2.4.3 UTF8_LengthInBytes 2-5 2.4.4 UTF8_Copy 2-6 2.4.5 UTF8_Delete 2-8 2.4.6 UTF8_Find 2-9 2.4.7 UTF8_Insert 2-11 2.4.8 UTF8_Left 2-12 2.4.9 UTF8_Mid 2-14 2.4.10 UTF8_Replace 2-16 2.4.11 UTF8_Right 2-18

2.5 Abbildungen 2-20 2.6 Allgemeines zum Datentyp LSTRING 2-22 2.7 Verwendung des Datentyps LSTRING 2-22 2.8 Funktionsbeschreibung zum Datentyp LSTRING 2-23

iii

2.8.1 LSTRING_val 2-24 2.8.2 LSTRING_setc 2-25 2.8.3 LSTRING_set 2-25 2.8.4 LSTRING_free 2-26 2.8.5 LSTRING_sprintf 2-26 2.8.6 LSTRING_UTF8_LengthInCharacters 2-27 2.8.7 LSTRING_UTF8_LengthInBytes 2-28 2.8.8 LSTRING_UTF8_Copy 2-30 2.8.9 LSTRING_UTF8_NCopy 2-31 2.8.10 LSTRING_UTF8_Delete 2-32 2.8.11 LSTRING_UTF8_Find 2-34 2.8.12 LSTRING_UTF8_Insert 2-36 2.8.13 LSTRING_UTF8_Left 2-37 2.8.14 LSTRING_UTF8_Mid 2-39 2.8.15 LSTRING_UTF8_Replace 2-41 2.8.16 LSTRING_UTF8_Right 2-43

2.9 Beispiele für die Bausteine Charge und Splitter 2-45 2.9.1 Beispiel Baustein Charge 2-46 2.9.2 Beispiel Baustein Splitter 2-49

3 Konfiguration des AlarmMonitors via XML 3-1

3.1 Konfiguration der AlarmMonitor via XML 3-1 3.2 Allgemeines zur Konfiguration des AlarmMonitors 3-2

3.2.1 Besonderheiten beim Betrieb mit mehreren CC-Accounts 3-4 3.3 Die XML-Konfigurationsdateien für den AlarmMonitor 3-5

3.3.1 Iosys- und CC-Account Einstellungen 3-6 3.3.2 Modifikation einer XML-Konfigurationsdatei 3-8 3.3.3 Zuweisen der Konfigurationsdateien 3-10

3.4 Beschreibung der Konfigurationsmöglichkeiten 3-12 3.4.1 Aufbau der Layout-Konfigurationsdateien 3-12 3.4.2 Geometrie-Management 3-14 3.4.2.1 Positionierung der Alarmzeile 3-14 3.4.2.2 Variable Feldbreiten 3-14 3.4.2.3 Konfiguration der Alarmzeile und Alarmliste 3-15 3.4.2.4 Anzahl der angezeigten Alarmereignisse 3-16 3.4.2.5 Frei positionierbare Alarmzeile 3-17 3.4.2.6 Verhalten aufgeschalteter Makros bei geöffneter Alarmliste 3-18 3.4.2.7 Verhalten der Alarmliste beim Wechsel der Prozessgrafik 3-18 3.4.2.8 Buttons, Statuszeile und Zeilen der Alarmereignisse 3-19

3.4.3 Informationen zu den Alarmereignissen 3-23 3.4.3.1 Lokaler Warnton 3-24 3.4.3.2 Positionierung der Alarmzeile und Anzahl der angezeigten Alarmereignisse 3-24 3.4.3.3 Unterdrückung der Alarmfilter 3-24 3.4.3.4 Zeitdarstellung 3-24 3.4.3.5 Sortierung der Alarmereignisse 3-25 3.4.3.6 Informationen in der Statuszeile und in den Zeilen der Alarmereignisse 3-25

iv

3.4.3.7 Alarminformation (alarminfo) 3-26 3.4.3.8 Text (text) 3-29 3.4.3.9 Trennfelder (spacer) 3-29

3.4.4 Schriftformatierungen und Farben 3-29 3.4.4.1 Hervorhebung der Mauszeiger-Position 3-30 3.4.4.2 Schriftformatierungen (fontlist, font) 3-30 3.4.4.3 Darstellungsstile (styles) 3-31 3.4.4.4 Darstellung von Systemmeldungen (system) 3-32 3.4.4.5 Alarmdatenabhängige Darstellung (data) 3-34 3.4.4.6 Festes Zuweisen von Schriftformatierungen und Farben 3-38

3.5 Die Layout- und Monitor-DTD-Dateien 3-38 3.5.1 Kurzinformation zur Anzahl und Reihenfolge der Elemente 3-40 3.5.2 Kurzinformation zu Attributen 3-40 3.5.3 Inhalt der Monitor-DTD-Datei 3-41 3.5.4 Inhalt der Layout-DTD-Datei 3-42

3.6 Neue Funktionalitäten in den APROL-Releases 3-47 3.7 Sprachausgabe für Alarme 3-48

3.7.1 Erweiterung der Alarm-Layout-Konfiguration 3-48 3.7.2 Verwendung der Loquendo-Controls 3-50 3.7.3 Sprachausgabe über den TtsServer 3-51 3.7.4 Interaktive und automatische Sprachausgabe von Alarmen im

DisplayCenter 3-52 3.7.5 Einschränkungen 3-54 3.7.6 Lizenzierung der Loquendo TTS7 Software zur Sprachausgabe von

Alarmen 3-56 3.7.7 Komponenten eines TTS-Systems 3-58

4 Offline-Engineering 4-1

4.1 Einführung zum Offline-Engineering 4-1 4.2 Lösung 4-1 4.3 Voraussetzungen für Offline-Engineering 4-2 4.4 Struktur Offline- und Online-Engineering 4-4 4.5 Vorbereitung für Offline-Engineering und Auschecken 4-4

4.5.1 Verriegeln der benötigten Projektierungsteile: 4-4 4.5.2 Auschecken der benötigten Projektierungsteile: 4-5

4.6 Arbeiten in der Online-Umgebung 4-6 4.6.1 Kontinuierliche Weiterarbeit in der Engineering-Umgebung: 4-6

4.7 Arbeiten im Offline-Engineering und beenden 4-6 4.7.1 Offline-Engineering starten 4-6 4.7.2 Offline-Engineering durchführen 4-7 4.7.3 Offline-Engineering beenden 4-9

4.8 Zusammenführung von Offline und Online 4-9 4.8.1 Einchecken der bearbeiteten Projektierungsteile 4-9 4.8.2 Prüfen, aktivieren und kompilieren der Projektierungsteile 4-10

4.9 Offline-Engineering mit projektspezifischer Datenreduktion 4-10

5 IosDiagnosticManager 5-1

v

5.1 Hinweise zur Unterstützung von Multi-Runtime-Systemen 5-1 5.2 Allgemeines zur Verwendung des IosDiagnosticManager 5-2

5.2.1 Iosys-Clients / Iosys-PVs 5-2 5.2.2 Statischer / dynamischer Watch 5-4 5.2.2.1 Allgemeines zur Bedienung im Watch-Fenster 5-6

5.3 Verwendung eines Signalgenerators 5-8 5.4 PV-Werte in den Iosys schreiben / aus Iosys ermitteln 5-9

6 Iosys HTTP-Schnittstelle 6-1

6.1 Allgemeines 6-1 6.1.1 Anwendung IosHttp 6-1 6.1.2 Konfiguration des Webservers 6-1

6.2 Detailinformationen 6-2 6.2.1 Request-Spezifikation 6-2 6.2.2 Response Formate 6-3 6.2.2.1 XML-Format 6-3 6.2.2.2 json-Format 6-3

6.2.3 HTML-Testseite mit Systemvariablen 6-6

7 Iosys-Kopplung 7-1

7.1 Konfiguration einer Iosys-Kopplung 7-1 7.1.1 Definition der Variablen 7-1 7.1.2 Definition des zu kontaktierenden CAE-Projekts 7-2 7.1.3 Anlegen der Kommunikationsdatei 7-3

8 APROL-SQL 5

8.1 Systemaufbau 5 8.2 Einrichtung einer Verbindung zum AprolSqlServer 7

8.2.1 Authentifizierung und Autorisierung 7 8.2.2 Client-Verbindung mit ODBC 8 8.2.2.1 Installation des JDBC- und ODBC-Remotetreibers unter Linux 8 8.2.2.2 Installation des JDBC- und ODBC-Remotetreibers unter Windows 10

8.2.3 Client-Verbindung mittels JDBC 13 8.2.4 Verbindungen in Python und PHP 14 8.2.4.1 Python 14 8.2.4.2 PHP 15

8.3 Den AprolSqlServer bedienen und konfigurieren 15 8.3.1 Starten und Stoppen des Dienstes 15 8.3.2 Port-Konfiguration 16 8.3.3 Konfiguration der Verbindungsverschlüsselung 17 8.3.4 Logging 18

8.4 APROL SQL-Tabellen 18 8.4.1 Vordefinierte SQL-Tabellen 18 8.4.2 JSON-Tabellenschema Dateien 8-1 8.4.3 Manuelle Erstellung von Tabellenschema-Dateien 8-2 8.4.3.1 Aufbau der Konfigurationsdatei im JSON-Format 8-2

vi

8.4.3.2 Abschnitt 'DataSourceHeader': 8-2 8.4.3.3 Abschnitt 'DataSourceDefinition': 8-2 8.4.3.4 Projekt-Substitution 8-3 8.4.3.5 Abschnitt 'TableDefinition': 8-3 8.4.3.6 Beispiel eines SQL-Select Statements: 8-4 8.4.3.7 Validierung einer Tabellenkonfiguration 8-4

8.5 Anhang APROL-SQL 8-4 8.5.1 Treiberparameter 8-4 8.5.2 Unterstützte SQL-Datentypen 8-5 8.5.3 IEC zu SQL Datentyp-Mapping 8-6 8.5.4 Verwendung von AprolSqlQueryTool als Datenbank-Client 8-6 8.5.4.1 Beschreibung der Benutzeroberfläche 8-7 8.5.4.2 Eingabefelder 8-7 8.5.4.3 Anzeigeflächen 8-8 8.5.4.4 Hauptmenü 8-8 8.5.4.5 Query-Job Liste 8-9 8.5.4.6 Protokollierung 8-9

8.5.5 Verwendung von SQuirreL als Datenbank-Client 8-9 8.5.5.1 Einrichtung des Datenbanktreibers 8-10 8.5.5.2 Einrichtung eines Alias (DB-Verbindungs-Alias) 8-11 8.5.5.3 SSL-Verbindung über SQiurreL 8-11 8.5.5.4 Datenbankverbindung aufbauen 8-12

8.5.6 Anmerkungen zu SQL-Abfragen 8-13 8.5.6.1 TOP-Klausel 8-13 8.5.6.2 Datums- und Zeitangaben 8-13 8.5.6.3 Performancebetrachtung 8-13

9 ReportSpooler 9-14

9.1 Allgemeines zur ereignisgesteuerten Report-Erstellung 9-14 9.1.1 Prinzipieller Ablauf zur Erstellung von PDF-Dateien 9-14

9.2 Konfiguration der Report-Erstellung mit dem Baustein AprCcTrigReport 9-16 9.2.1 Konfiguration und Funktionsweise des ReportSpoolers 9-21 9.2.2 AprolCreateReport 9-21

9.3 Abläufe und Wirkungswege bei der Ereignis-gesteuerten Report-Erstellung9-23 9.4 Erstellung kundenspezifischer Reports 9-25

9.4.1 Redundanz 9-29

10 Digitale Signatur von PDF-Dokumenten 10-1

10.1 Grundlagen der digitalen Signatur 10-1 10.1.1 Motivation und Intention 10-1 10.1.2 Was ist Signierung? 10-1 10.1.3 Wozu dienen digitale Signaturen in APROL? 10-2 10.1.4 Was ist asymetrische Verschlüsselung? 10-2 10.1.5 Was ist ein Zertifikat? 10-3 10.1.6 In welchem Format werden Zertifikate gespeichert? 10-4 10.1.7 Was ist eine Zertifizierungsstelle? 10-4 10.1.8 Wozu dient ein Zeitstempelserver? 10-4

vii

10.2 Wie erstelle ich digitale Signaturen in APROL? 10-5 10.2.1 Wozu werden Zertifikate in APROL verwendet? 10-5 10.2.2 Welche Zertifikate gibt es in APROL? 10-5 10.2.2.1 Wie werden Zertifikate für die digitale Signatur in APROL verwendet?10-6 10.2.2.2 Können Zertifikate verwendet werden, die von einer externen Zertifizierungsstelle kommen? 10-7

10.2.3 Wie werden Zertifikate für Benutzer und Operatoren erstellt? 10-8 10.2.3.1 Erstellen eines Benutzer-Zertifikats 10-8 10.2.3.2 Erstellen eines Operator-Zertifikats 10-10

10.2.4 Wie werden PDF-Dokumente in APROL signiert? 10-11 10.2.5 Welche Eingaben sind bei der Erstellung einer Signatur erforderlich? 10-11 10.2.6 Was ist der Unterschied zwischen Zertifizieren und Signieren beim Adobe

Reader? 10-14 10.2.7 Wie kann nachträglich ein Operator-Zertifikat erstellt werden? 10-14 10.2.8 Wann wird eine Signatur vom AdobeReader als gültig angezeigt? 10-15 10.2.9 Können Zertifikate als 'ungültig' deklariert werden? 10-18 10.2.10 Was mache ich, wenn das Passwort für ein Benutzer- / Operator-

Zertifikat einem Dritten bekannt geworden ist? 10-18 10.2.11 Wie sicher ist die APROL-Signatur? 10-19 10.2.12 Wie signiere ich mit einem privaten (auf einem externen Datenträger

vorhandenen) Zertifikat? 10-19 10.2.13 Wie konfiguriere ich einen Zeitstempel-Server 10-20

11 TranslationManager 11-1

11.1 Aufrufen des TranslationManagers 11-2 11.2 Grundlegende Funktionalitäten 11-6

11.2.1 Übersetzungs-Sitzungen 11-6 11.2.2 Kompendien 11-7 11.2.3 CSV-Import/Export 11-7

11.3 Übersetzungsleistung mit dem TranslationManager 11-8 11.3.1 Statusinformationen 11-10 11.3.2 Bearbeiten der PO-Dateien 11-10 11.3.2.1 Navigation 11-11 11.3.2.2 Sortieren 11-12 11.3.2.3 Suchen/Ersetzen 11-12 11.3.2.4 Syntaxprüfungen 11-12

11.3.3 Visualisierungstexte 11-13 11.3.4 Alarmtexte 11-15 11.3.5 Übersetzen der APROL-Systemsoftware 11-18

12 Sprachen-Lokalisierung 12-1

12.1 Installations-Voraussetzung 12-1 12.2 Inhalt der APROL Language-DVD 12-1 12.3 Erstellung einer Übersetzungsumgebung 12-2 12.4 Schritte der Übersetzungsleistung 12-3

12.4.1 Übersetzen der po-Dateien 12-3 12.4.2 Übersetzung der xsl- und clt-Dateien 12-5

viii

12.4.3 Übersetzung des KDE-Menüs für APROL 12-6 12.4.4 Übersetzung innerhalb der caedb 12-8

12.5 Test der Übersetzungsleistung 12-10 12.6 Werkzeuge für die Eingabe chinesischer Zeichen 12-10 12.7 Arbeiten mit dem Werkzeug fcitx 12-11 12.8 Detail-Informationen zur Sprachumschaltung 12-12 12.9 Technische Anmerkungen (intern) 12-13

13 Datenbank für das Parameter Management 13-1

13.1 Allgemeines zur Datenbank für das Parameter Management 13-1 13.1.1 Allgemeines zur Datenbank-Struktur 13-1 13.1.2 Beschreibung der Tabellen-Struktur 13-2 13.1.2.1 Diagramm "Abhängigkeiten" 13-6

13.2 mySQL-Befehle für das Arbeiten mit der Datenbank 13-6 13.2.1 AprolConfigParameterManagement MySQL 13-6

13.3 Allgemeines zur Replikation 13-6 13.3.1 AprolConfigParameterManagement Replikation 13-7

13.4 Backup 13-7 13.5 Purge BinLog-Files 13-7 13.6 Diagnose 13-7

13.6.1 BuRMySQLToolbox 13-7 13.7 Hinweise zur Lizenzierung 13-8

14 Authentifizierung via LDAP / Active Directory-Server 14-1

14.1 Aufschlüsselung der Platzhalter für die LDAP-Beispiele 14-5 14.2 Verwendung der B&R Beispiel-Konfigurationen 14-5 14.3 Welche Vorteile ergeben sich durch die Verwendung eines LDAP-Servers

zur Authentifizierung auf einem APROL-Server? 14-6 14.4 Wie ändert sich das Verhalten des Authentifizierungsprozesses in APROL

bei Verwendung eines LDAP-Servers? 14-7 14.5 Installation und Konfiguration eines LDAP-Servers / Active Directory-

Servers 14-8 14.5.1 Wie wird ein openLDAP-Server unter Linux mit dem YaST2 eingerichtet?14-8 14.5.2 Wie wird ein Active Directory-Server installiert? 14-12 14.5.3 Wie wird ein openLDAP-Server konfiguriert? 14-12 14.5.3.1 Wie wird die Default-Passwortrichtlinie angepasst? 14-15 14.5.3.2 Wie wird eine minimale Datenbank-Struktur eingerichtet? 14-17 14.5.3.3 Wie wird ein LDAP-Query-Benutzer für den openLDAP Server eingerichtet? 14-19

14.5.4 Wie wird die Verbindung zu einem LDAP-Server getestet? 14-21 14.5.5 Wie wird ein Active Directory Server konfiguriert? 14-21 14.5.6 Wie wird ein Apache Directory Studio (ADS) unter Linux konfiguriert? 14-23

14.6 Übertragung der APROL Benutzerdaten in den LDAP-Server 14-26 14.6.1 Einrichtung des AprolJobDispatchers für die Übertragung der

Benutzerdaten in den LDAP-Server 14-26 14.6.2 Übertragen der LDAP-Daten aus der Benutzerverwaltung und dem

OperatorManager 14-27

ix

14.6.3 Funktionsweise des AprolJobDispatcher Mechanismus 14-29 14.6.4 Sicherheit 14-30

14.7 Benutzer-Verwaltung openLDAP 14-30 14.7.1 Wie werden weitere Passwortrichtlinien auf einem openLDAP-Server mit

dem Apache Directory Studio angelegt? 14-31 14.7.2 Wie werden weitere Passwortrichtlinien auf einem openLDAP-Server mit

dem YaST angelegt? 14-37 14.7.3 Wie wird eine Passwortrichtlinie auf einem openLDAP-Server manuell

angelegt? 14-40 14.7.4 Wie wird ein Benutzer auf dem openLDAP-Server angelegt? 14-43 14.7.5 Wie wird ein Benutzer auf dem openLDAP-Server mit Apache Directory

Studio angelegt? 14-43 14.7.5.1 Wie wird ein APROL-System für den LDIF-Export vorkonfiguriert? 14-44 14.7.5.2 Wie werden Benutzer und Operator aus dem APROL-System in LDIF-Format exportiert? 14-45 14.7.5.3 Wie wird eine LDIF-Datei in den openLDAP-Server mit Apache Directory Studio importiert? 14-48

14.7.6 Wie wird ein Benutzer auf dem openLDAP-Server manuell angelegt? 14-49 14.7.7 Wie wird ein Benutzer auf einem openLDAP-Server entfernt? 14-51 14.7.8 Wie wird ein gesperrter Benutzer-Account im openLDAP-Server frei

gegeben? 14-52 14.7.9 Wie wird einem bestehenden Benutzer auf einem openLDAP Server eine

Passwortrichtlinie zugewiesen? 14-53 14.7.10 Wie wird eine Benutzer auf einem openLDAP Server editiert? 14-54 14.7.11 Wie wird das Passwort eines Benutzers auf einem openLDAP Server

geändert? 14-54 14.7.12 Wie werden alle konfigurierten Benutzer auf einem openLDAP Server

aufgelistet? 14-55 14.8 Benutzer-Verwaltung auf einem Active Directory Server 14-55

14.8.1 Wie wird ein Benutzer auf einem Active Directory Server angelegt? 14-56 14.8.2 Wie wird ein Benutzer auf einem Active Directory Server editiert? 14-58 14.8.3 Wie wird das Passwort eines Benutzers auf einem Active Directory

Server geändert? 14-62 14.9 Anbindung von APROL mit openLDAP / Active Directory Server 14-63

14.9.1 Wie wird ein APROL-Server an einen openLDAP-Server mit YaST angebunden? 14-63

14.9.1.1 Welche zusätzlichen manuellen Anpassungen müssen durchgeführt werden? 14-65

14.9.2 Wie wird ein APROL-Server manuell an einen openLDAP-Server angebunden? 14-67

14.9.3 Wie wird das PAM-LDAP-Modul für die Anbindung an den openLDAP-Server konfiguriert? 14-70

14.9.4 Wie wird einen APROL-Server an einen Active Directory-Server angebunden? 14-70

14.9.4.1 Wie wird Kerberos zur Anbindung an den Active Directory-Server konfiguriert? 14-70 14.9.4.2 Wie wird das PAM-Kerberos-Modul für die Anbindung an einen Active Directory-Server konfiguriert? 14-72

x

14.10 Erweiterte Sicherheit durch Verwendung von SSL / TLS für den openLDAP-Server 14-73

14.10.1 Wie wird die Sicherheit der Verbindung zwischen einem APROL-Server und einem openLDAP-Server erhöht? 14-73

14.10.2 Wie wird das für die SSL-Verbindung benötigte Zertifikat für einen openLDAP-Server erstellt? 14-74

14.10.3 Wie werden unverschlüsselte Verbindungen zum openLDAP-Server unterbunden? 14-77

14.10.4 Wie wird die SSL-Verschlüsselung auf dem APROL-Server aktiviert? 14-78 14.10.5 Wie wird die Sicherheit der SSL-Verbindung verschärft? 14-78 14.10.6 Wann wird ein Zertifikat endgültig aktiviert? 14-79

14.11 Konfiguration der LDAP-Authentifizierung für das Engineering- und Runtime-System 14-79

14.11.1 Wie wird die LDAP-Authentifizierung für das Engineering-System im CaeManager konfiguriert? 14-80

14.11.2 Wie wird die LDAP-Authentifizierung für das Runtime-System im CaeManager konfiguriert? 14-81

14.11.2.1 Wie wird für die lokale Authentifizierung die Komplexitäts-Überprüfung für Passwörter aktiviert? 14-82

14.12 Passwortrichtlinien / Account-Richtlinien auf einem Active Directory Server?14-83 14.12.1 Wie werden Passwortrichtlinien auf einem Active Directory Server

konfiguriert? 14-83 14.12.1.1 Wie wird die maximale Anzahl der in der Historie gespeicherten Passwörter festgelegt? 14-84 14.12.1.2 Wie wird das Höchstalter eines Passwortes festgelegt? 14-84 14.12.1.3 Wie wird die minimale Länge eines Passwortes festgelegt? 14-85 14.12.1.4 Wie wird die Komplexitäts-Überprüfung für neue Passwörter aktiviert? 14-86 14.12.1.5 Wie wird die maximale Anzahl der Falsch-Anmeldungen konfiguriert?14-87 14.12.1.6 Wie wird ein gesperrter Benutzer-Account im Active Directory Server frei gegeben? 14-89

15 Anhang 15-1

15.1 Änderungshistorie 15-1 15.2 Dokument-Information 15-6

16 Glossar 16-1

xi

APROL Dokumentation D1 System Handbuch V4.06

gehört zur Handbuchgruppe Extended Engineering Zielgruppe, Konventionen und Formate Das Handbuch D1 System Handbuch richtet sich an Projektingenieure und Systemadministratoren und beschreibt Zusatzfunktionen (z. B. Offline-Engineering, Web-Schnittstelle Prozessdatenbasis, Sprachen-Lokalisierung) die das Leistungsspektrum des Basis-Engineerings erweitern. In der vorliegenden Dokumentation gelten die folgenden Formatierungen: Taste [Esc]-Taste Menüpunkt "Modul-Gruppen/öffnen" Verzeichnisname HOME/ENGIN/HTML/049 Im vorliegenden Handbuch werden die folgenden Symbole zur Hervorhebung besonderer Hinweise verwendet:

Aufzählung

Aufzählung

Aufzählung

Tipp bzw. Vorschlag

Hinweis

Achtung

Literatur-Referenz

Diese Beschreibung ist z. Zt. in Bearbeitung. informieren Sie in regelmäßigen Abständen auf unserer Internetseite www.br-automation.com im Bereich Produktbezogene Downloads über die aktuelle APROL Dokumentation.

Dieser Punkt ist vom Benutzer auszuführen

Auflistung notwendiger Konfigurationsschritte Nächster Schritt Konfiguration abgeschlossen

Sammlung zum APROL-System 1-1

1 Sammlung zum APROL-System .

1.1 Warum Zeitsynchronisation

Informationen zur Änderungshistorie entnehmen Sie bitte dem Kapitel Änderungshistorie im Anhang.

Ein Prozessleitsystem, das mit APROL erstellt wird, besteht im allgemeinen Fall aus mehreren vernetzten Rechnern. Von diesen Rechnern werden über Programme, die lokal auf den einzelnen Rechnern "laufen", Eingaben für das Prozessleitsystem vorgenommen und diese mit Datum und Uhrzeit (= Zeitstempel) an zentraler Stelle im Runtime-System protokolliert und aufgezeichnet. Um die Protokollierung im nachhinein (Beweispflicht) sekundengenau verfolgen zu können, müssen die Uhren der Rechner synchron laufen. Da diese Bedingung im Normalfall nicht gegeben ist, muss also eine Zeitsynchronisation erfolgen. Jeder Rechner hat zwar eine eigene eingebaute batteriegepufferte Hardware-Uhr (die BIOS-Uhr), aber diese Uhren driften mit zunehmender Betriebszeit von der Normalzeit weg und dienen nur dazu, beim Einschalten und Starten des Rechners nicht immer Datum und Uhrzeit eingeben bzw. stellen zu müssen. Das Linux-Betriebssystem arbeitet mit einer internen Softwareuhr. Beim Start des Rechners übernimmt das Linux-System die Uhrzeit der BIOS-Uhr und arbeitet dann mit der UNIX-System Uhr. Diese Uhr ermittelt die Zeit aus der Taktfrequenz der CPU. Diese Taktfrequenz ist von Rechner zu Rechner mit einer Toleranz behaftet und somit driften auch diese Uhren von der Normalzeit weg.

Die UNIX-Systemzeit wird aus den Sekunden, die ab dem 01.01.1970 bis zum gewählten Zeitpunkt x (= ermitteln der Uhrzeit) verflossen sind, berechnet.

Es ist also bei einem vernetzten APROL-System unbedingt erforderlich, die Uhren allen beteiligten Rechners zu synchronisieren. Soll eine DCF77-Uhr oder GPS-Uhr als zentrales Zeitnormal zum Einsatz kommen, kann zur Erhöhung der Systemzeit-Sicherheit (Ausfall dieser Funkuhr) eine weitere Funkuhr im System an einem Rechner installiert werden.

1.1.1 Zeitsynchronisation über XNTP

Alle Rechner, die zu einem APROL-System zusammengeschaltet sind, werden - wenn gewünscht - automatisch einem Zeitabgleich, der Zeitsynchronisation auf eine zentrale Uhr, unterzogen. Diese Synchronisation der Zeit für alle Rechner kommt dann optimal zum Einsatz, wenn die Verwendung einer DCF77- oder GPS-Uhr am Zeit-Server erfolgt. Hierbei gibt der Zeit-Server die gültige Uhrzeit zwingend für alle anderen Rechner im Netz vor.

APROL benutzt bei der Synchronisation den standardisierten XNTPD-Dienst. Dieser arbeitet mit einem plattformunabhängigen Protokoll zur Synchronisation von Rechneruhren in einem Netzwerk. Das Herz dieses Dienstes ist der XNTP-Daemon (xntpd). Der Rechner, der als Server für die Zeitsynchronisation bestimmt wird, liefert die Uhrzeit; der Client übernimmt die vom Server gelieferte Uhrzeit.

D1 System Handbuch 1-2

Der Vorgang der Zeitsynchronisation in kurzen Schritten: Funktion Beschreibung

Der Rechner wird eingeschaltet und Linux startet bzw. bootet

Bei diesem Vorgang wird die Uhrzeit der Hardware- Uhr in die Linux Systemzeit übernommen.

Der xntpd wird vor dem APROL-System über sein Startskript gestartet und übernimmt "hart" die gewählte Synchronzeit in die Systemzeit.

Die gewählte Systemzeit kann von folgenden Quellen kommen: - Funkuhr am Rechner, - Zeitserver, der über aprolconfig angegeben wurde, oder (ungünstigster Fall) - die Hardware-Uhr des Rechners.

Der xntpd "nimmt seine Arbeit" auf. Er vergleicht kontinuierlich die Systemzeit mit der vorgegebenen Zeitquelle. Stellt er Abweichungen fest, verändert er die Frequenz, aus der das Zeitnormal für den Rechner erstellt wird bis die Zeiten wieder synchron sind.

Der Rechner wird runtergefahren. Er schreibt die Systemzeit in die Hardware-Uhr. Wie dieser Daemon arbeitet, kann als root abgefragt werden mit dem Befehl: ntpdc –c sysinfo

Um die Ausgabe näher zu analysieren, kontaktieren sie bitte die Seite http://www.ntp.org Der Daemon kann auch im Runtime-System netzwerkweit überwacht werden. Hierfür ist der Baustein UCB_XNTP aus der Bibliothek PCC_SYSTEM in der Gruppe LR_INFO in einen Plan einzusetzen. Das nachträgliche Ändern der Konfiguration für den XNTP-Daemon ist jederzeit als Superuser (root) durch den Aufruf des Skripts AprolConfig --xntp möglich.

1.2 Webserver und Webbrowser Der Grund für den Einsatz sowie die Installation und das Webserver-Konzept sind im Handbuch Getting Started unter dem Kapitel Web-Server beschrieben.

Wenn Ihnen der standardmäßig eingestellte Webbrowser nicht gefällt, so können Sie unter Linux einen anderen Browser nachinstallieren und diesen im CaeManager unter dem Menüpunkt "Extras / Optionen", Reiter HTML / Web für das Engineering und auch für das Runtime-System (Projektdokumentation) auswählen.

Da innerhalb von APROL für Animationen Flash benutzt wird, muss der von Ihnen gewählte Webbrowser dieses Plug-In unterstützen!

1.2.1 Interventionstexte für Alarme Das Auftreten eines Alarms ist ein Ereignis, welches vom Operator des Prozessleitsystems oftmals einen sofortigen Eingriff erfordert, um einen größeren Schaden abzuwenden. Die


Handlungen nach dem Auftreten eines sehr wichtigen Alarms sind nicht Routine und auch nicht alltäglich. So ist es beim Auftreten eines solchen Alarms für den Operator eine große Hilfe, wenn er im Bedarfsfall sofort einen Text, der die nächsten Handlungsschritte exakt beschreibt, anwählen kann.

Aus diesem Grund wurde innerhalb des APROL-Systems die Möglichkeit geschaffen, bei auftretenden Alarmen Interventionstexte anzuwählen. Die Möglichkeit Interventionstexte – als HTML-Seite – anzuzeigen ist z. B. mit dem Baustein AprCcAlarm aus der Bibliothek APROL in der Gruppe Alarm gegeben. Die Seiten (für jeden wichtigen Alarm sollte eine eigene Seite erstellt werden.) sind im home-Verzeichnis des Engineering-Systems in folgendem Pfad abzulegen: /home/<CC-Account>/ENGIN/PROJECTS/<Projektname>.pgp/WEB/ <Ländercode>/IVTEXTS

Jede Seite für einen Interventionstext muss eine eindeutige Bezeichnung haben. => <Name eindeutig>.html Die Seiten werden nach dem Download in folgendem Verzeichnis des Runtime-Systems abgelegt: /home/<CC-Account>/RUNTIME/WEB/<Ländercode>/IVTEXTS

Um diese Seiten auch nutzen können, ist unbedingt, wie im Kapitel Eigene Projektdokumentation beschrieben, für das Runtime-System der Dokumentations-Server einzutragen!

1.2.1.1 Vorteile durch Einbinden von PHP4 und Flash Mit der Einbindung von PHP4 und Flash ab Release 2.0 von APROL sind die Möglichkeiten der online Darstellung einer Projektdokumentation und die Anzeigen von Interventionstexten noch vielfältiger geworden. PHP4 wird vom Webserver genutzt und Flash vom Webbrowser. Mit PHP4 ist Ihnen z. B. die Möglichkeit gegeben, die von Ihnen als HTML-Seiten erstellte Projektdokumentation mehrsprachig zu erstellen. Je nach Landessprache, die über KDE eingestellt wird, kann somit durch die Nutzung von PHP4 sofort die Projektdokumentation oder der Interventionstext in der gewählten Sprache angezeigt werden. Durch den Einsatz von Flash in der Online Dokumentation oder den HTML-Seiten für die Interventionstexte, können diese noch effizienter gestaltet werden. Anhand des Beispiels für eine HTML-Seite (Auszug) für einen Interventionstext wird der oben genannte Sachverhalt erläutert.


<? if ($sprache=="001") { $pfad="_001"; } else if ($sprache=="033") { $pfad="_033"; } else { $pfad=""; } ?> <--Mit dem oberen Teil kann aus KDE abgeleitet werden, welche Sprache eingestellt ist und z. B. der "Flashfilm" in der entsprechenden Sprache (<?//echo $pfad;?>) gewählt werden --!> <table cellpadding="0" cellspacing="0" width="100%" height="80%" border="0"> <tr> <td> <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="600" height="400"> <param name=movie value="objekte/pro1<?echo $pfad;?>.swf"> <param name=quality value=high> <embed src="objekte/pro1<?echo $pfad;?>.swf" quality=high type="application/x-shockwave-flash" width="600" height="400"></embed> </object> <-- Der Flashfilm wird im object-Tag eingebaut. --!> </td> </tr> </table>

1.2.2 Eigene Projektdokumentation



1.3 Allgemeines zum SNMP-Mechanismus

Das Kapitel SNMP beschreibt den SNMP-Mechanismus von APROL unter Verwendung von UCB-Bausteinen. Zunächst wird kurz eingegangen auf den Umfang des SNMP-Paketes der SuSE LINUX Distribution. Beschrieben wird zunächst die Serverkomponente sowie anschließend die Konfiguration und Benutzung der SNMP-Clients. Im darauffolgenden Kapitel wird die Erstellung der SNMP-Bausteine mit Hilfe der UCB Technologie erläutert. Anschließend wird das Erstellen des ausführbaren Skripts, der eigentlichen Logik, die sich hinter dem Baustein verbirgt, anhand eines Beispiels dargestellt. SNMP-Server und SNMP-Client: SNMP ist die Abkürzung für "Simple Network Management Protocol".

Der in APROL gewählte Ansatz zur Ermittlung von Informationen SNMP-fähiger Geräte und Software bedient sich der unter Linux verfügbaren SNMP-Clients. APROL-seitig wird die Funktionalität dieser Clients über den allgemeinen in APROL verfügbaren UCB-Mechasnismus in das jeweilige Projekt integriert. Es handelt sich daher bei der Kopplung SNMP-fähiger Geräte sowohl bezogen auf das Betriebssystem, als auch auf APROL, um eine standardisierte Lösung. SNMP ermöglicht die Abfrage und Weiterverarbeitung von Systemparametern von SNMP-fähiger Hardware und Software unabhängig vom verwendeten Betriebsystem. Um SNMP-Parameter abzufragen bzw. zur Verfügung zu stellen, muss unter Linux das SNMP-Paket installiert sein. Unter SuSE heißt das Paket ucdsnmp und befindet sich in der Serie n. Das SNMP-Paket beinhaltet die Serverkomponenten snmpd und die Abfragetools snmpwalk, snmpget.

Die Servertools werden benötigt, um den Rechner SNMP-fähig zu machen, das heißt, dass Systemparameter zur Abfrage bereitgestellt werden. Für die Konfiguration wird die Konfigurationsdatei ucdsnmpd.conf benötigt. Für das nachfolgende Beispiel muss diese Datei verändert werden. Die Konfigurationsdatei /etc/ucdsnmpd.conf muss um einen weiteren Eintrag ergänzt werden. Unterhalb der Zeile "view system included system fe" wird die Zeile "view system included host fe" hinzugefügt. Danach startet man den SNMP-Server mit /sbin/init.d/snmpd restart neu. Die Abfragetools werden im Zusammenhang mit einer bestimmten Syntax benutzt, um jedwede SNMP-fähige Hard-/und Software abzufragen.

Für SNMP ist das Vorhandensein des Verzeichnisses /usr/share/snmp/mibs unbedingt erforderlich. In diesem Verzeichnis werden die MIB-Dateien gehalten. Diese Dateien sind Übersetzungstabellen für den SNMP-Client bzw. -Server, auf die im weiteren näher eingangen wird.

1.3.1 Konfiguration und Benutzung der SNMP-Clients Die SNMP-Clients: Das SNMP-Paket unter Linux enthält u. a. die Clients snmpwalk und snmpget. Der Befehl snmpwalk wird für allgemeine Abfragen, der Befehl snmpget für spezielle Abfragen benutzt.


Der SNMP-Client snmpwalk: Um eine Anzahl zusammenhängender Parameter auszulesen und diese in einer Baumstruktur anzuzeigen benötigt man den Client snmpwalk. Ein Anwendungsbeispiel wäre die Befehlsfolge snmpwalk localhost public system. Dieser Befehl zeigt die komplette Baumstruktur des Bereichs "system" des lokalen Rechners an. Die Ausgabe könnte wie folgt aussehen:

Abbildung 1: Ausgabe des snmpwalk

Der SNMP-Client snmpget: Eine weitere Möglichkeit Informationen zu erhalten, bietet der Client snmpget. Dieser zweite Client liest konkret angegebene Werte aus dem SNMP-Baum. Ein Anwendungsbeispiel ist die Befehlsfolge snmpget localhost public system.sysDescr.0, womit nur der zugehörige Wert der Variable "system-sysDescr.0" des lokalen Rechners ausgegeben wird. Hierzu könnte die Ausgabe wie folgt aussehen:

Abbildung 2: Ausgabe des snmpget

Bei jeder Abfrage wird ein konkreter textueller Begriff als Abfragevariable angegeben. In diesem Falle "system.sysDescr.0". Bei der ersten Abfrage war dies der Begriff "system". Diese Variablen existieren auf der Systemebene jedoch nicht in der angegebenen Textform sondern als Zahlencodes. Um eine Umwandlung Text-->Zahl bzw. Zahl-->Text durchzuführen, benötigt man die bereits erwähnten MIB-Dateien.


Eine textuelle Variable wie z.B. host.hrStorage.hrStorageTable.hrStorageEntry. hrStorageUsed.1 wird durch die MIB-Datei, in welcher die Hauptsystemvariable "host" entschlüsselt wird ("HOST-RESOURCES.TXT"), vom SNMP-Client bzw. -Server in den Zahlencode 25.2.3.1.6.1 umgewandelt werden. Anhand dieser Zahlencodes werden Werte aus den Systemvariablen gelesen bzw. den zurückgegebenen Variablen wird ein Name zugewiesen. Wenn nun eine Soft-/oder Hardware SNMP-fähig ist, muss überprüft werden, ob in den MIB-Dateien die Konfigurationseigenschaften für die entsprechende Hard-/ Software abgelegt sind oder sogar eine eigene MIB-Datei existiert, die in das beschriebene Verzeichnis /usr/share/snmp/mibs kopiert werden muss.

1.3.2 Erstellen der SNMP-Bausteine SNMP-Bausteine auf Basis der UCB-Technologie: Um einen Baustein zu entwickeln, der Daten aus SNMP-Abfragen zur Verfügung stellt, stellt die Verwendung von UCB-Bausteinen einen sinnvollen Ansatz dar. Die Bausteine sollten in einer Customer-Bibliothek abgelegt werden, um die zugrunde gelegte Funktionalität validierbar kapseln zu können. Anhand eines konkreten Beispiels, welches den belegten Speicherplatz der Root-Partition eines SNMP-gekoppelten Gerätes ausliest, wird die Vorgehensweise zur Erstellung eines solchen Bausteins erklärt. Innerhalb des CaeManagers wird zunächst die Bibliothek "SNMPTEST" angelegt. Diese wird als Customer-Bibliothek gekennzeichnet.


Abbildung 3: Anlegen der Bibliothek SNMPTEST

Im nächsten Schritt wird eine neue Gruppe namens "Harddisk" erstellt. Diese Gruppe wird später einen oder mehrere SNMP-Bausteine enthalten, die für die Ermittlung von Harddisk-Daten verantwortlich sein soll. Daraufhin wird ein Baustein, der "SNMPUsedRootDisk" benannt wird, konfiguriert. Dieser Baustein wird zur Ermittlung des belegten Speicherplatzes auf der Root-Partition des Rechners verwendet. Er gehört zu der schon erstellten Gruppe Harddisk und ist vom Typ UCB.

UCB-Bausteine werden verwendet, da sie durch ihre interne Script-Fähigkeit sehr flexibel und deshalb für alle Aufgaben geeignet sind.


Abbildung 4: Anlegen des Bausteins

Jeder UCB-Baustein benötigt einen Default-Eingang "UcbTrigger" und einen Default-Ausgang "UcbStatus".

Abbildung 5: Konfiguration der Default-Ein- und –Ausgänge

Da SNMP netzwerkweit angewendet werden kann, konfiguriert man einen zweiten Eingang vom Typ STRING, der vom Anwender veränderbar ist. Der Eingang erhält die Bezeichnung "Host",


da dort die IP-Adresse bzw. der Hostname der abzufragenden Hard- oder Software eingetragen wird. Um eine Rückgabe zu erhalten, die man z.B. im DisplayCenter anzeigen kann, sollte man einen zusätzlichen Ausgang erstellen. Der ausgegebene Wert ist in diesem Fall ein String. Der Pin ist vom Typ STRING und erhält die Bezeichnung "UsedDisk".

Abbildung 6: Anlegen des Ausgangs UsedDisk

Falls in der ucdsnmpd.conf mehrere Communities eingerichtet worden sind, kann man optional einen weiteren Eingangspin mit dem Namen "Community" konfigurieren, der im Script vom Client snmpget oder snmpwalk ausgewertet werden kann.

1.3.3 Erstellen des Scripts Ermittlung des belegten Speicherplatzes der Root-Partition: Dieses Script ist ein simples Unix-Bash-Script, in dem auf Systemebene die schon vorher besprochenen SNMP-Variablen mit den Werkzeugen snmpget bzw. snmpwalk ausgelesen werden. Anhand des Scripts für die Ermittlung des belegten Speicherplatzes wird die grundlegende Vorgehensweise beispielhaft erläutert. Das Grundgerüst eines jeden UCB-Scripts sieht wie folgt aus:


Abbildung 7: Das Skript-Template

Innerhalb des Anfangs-/und Endbereiches, kann nun das eigentliche Script geschrieben werden. Zuerst muss jedoch herausgefunden werden, welche Variablen per SNMP ausgelesen werden sollen, um den belegten Platz in MB auszugeben. Eine direkte Art diesen Wert zu bekommen gibt es nicht, und deshalb müssen auch einige Berechnungen durchgeführt werden. Für die Berechnung des belegten Speicherplatzes werden folgende Werte benötigt:

Die Position der Root-Partition auf der Platte

Die I-Node-Dichte

Die Anzahl der verbrauchten Blocks auf der Partition

Die Namen für diese Systemvariablen sind in der HOST-RESOURCES.TXT im Verzeichnis /usr/share/snmp/mibs gespeichert. Mit dem Befehl "snmpwalk localhost public host" werden alle Systemvariablen angezeigt.

Von Interesse ist "host.hrStorage.hrStorageTable.hrStorageEntry.hrStorage Index.*". Je nachdem, wie viele Partition existieren, gibt es analog dazu Einträge. Um herauszufinden, welche Variable die Root-Partition repräsentiert, überprüft man den Eintrag "host.hrStorage.hrStorageTable.hrStorageEntry.hrStorageDescr.*" und sucht nach dem Wert "/". Im zugrundeliegenden Beispiel ist also die Root-Partition "host.hrStorage.hrStorage Entry.hrStorageIndex.1". Die ".1" am Ende kennzeichnet im weiteren Verlauf der Beschreibung also immer die Root-Partition. Für die I-Node Dichte, wird die Variable "host.hrStorage.hrStorageTable. hrStorageEntry.hrStorageAllocationUnits.1" benutzt. Ersetzt man die ".1" durch eine andere Kennzeichnungszahl, dann wird die I-Node Dichte für eine andere Partition ausgegeben. Nachfolgend muss man den Wert für die Anzahl der verbrauchten Blocks auf der Partition ausgeben. Dieser Wert ist in der Variable "host.hrStorage.hrStorageEntry. hrStorageUsed.1" enthalten. Mit den Befehlen "snmpget localhost public host.hrStorage.hrStorageTable.hrSto rageEntry.hrStorageUsed.1" und "snmpget localhost public host.hrStorage.hr StorageTable.hrStorageEntry.hrStorageAllocationUnits.1" bekommt man die darin gespeicherten Werte zusammen mit den Variablen im folgenden Format zurück: host.hrStorage.hrStorageEntry.hrStorageTable.hrStorageEntry.hrStorageIndex.1 = <Wert>

host.hrStorage.hrStorageEntry.hrStorageTable.hrStorageEntry.hrStorageAllocationUnits.1 = <Wert>

Die Ausgabe ist in jedem Fall gleich, sodass man mit einigen Bash-Befehlen den <Wert> herausfiltern kann.


Der erste Ansatz für das Script müsste demnach wie folgt aussehen:

Abbildung 8: Entwicklung des Scripts -Schritt 1

Um leere Werte abzufangen wird eine if-Abfrage erstellt und ermittelt durch eine arithmetische Operation den korrekten Endwert. Das fertige Script sieht demnach wie folgt aus:

Abbildung 9: Script zur Ermittlung des belegten Speicherplatzes der Root-Partition

Mit einem "echo <AusgangsPinName>=<$ENDVALUE>" wird der errechnete Wert auf den Ausgangs-Pin des UCB-Bausteins geschrieben, wo man ihn dann weiterverarbeiten bzw. im DisplayCenter anzeigen lassen kann.

1.4 Systembefehle und -programme Die in den in den folgenden Kapiteln und Abschnitten beschriebenen Systembefehle, –programme und Besonderheiten sollen Ihnen eine weiter und auch tiefere Einsicht in die APROL-Systeme ermöglichen. Die Befehle und Programme sollten aber nur von versierten Benutzern oder Systemadministratoren benutzt werden, da durch fehlerhafte Eingaben das APROL-System beschädigt werden kann.

Die folgende Tabelle gibt einen Überblick:

Systembefehle

APROL systemprogramme

Besonderheiten


1.5 Systembefehle Die im Folgenden nicht nach Priorität aufgelisteten Befehle und Programme sollen Sie bei der Analyse unterstützen. Es werden auch Befehle des Betriebssystems Linux aufgeführt, wenn sie beim Arbeiten mit APROL hilfreich sind. Alle Befehle sind in einem X-Term oder einer virtuellen Konsole einzugeben. Vorraussetzung ist, dass Sie sich über das Linux-Login in ein APROL-System eingeloggt haben. Die folgende Tabelle gibt einen Überblick:

AprolCmd

GetEnvi

Datenbankoptimierung

ps

1.5.1 AprolCmd

AprolCmd ermöglicht ein beschleunigtes Starten und Stoppen des APROL-Systems. Es können einzelne Anwendungen separat, ohne die Abhängigkeiten kennen zu müssen, hoch und herunter gefahren werden. Das Starten und Stoppen von einzelnen Anwendungen muss nun nicht mehr über die Linux-Systembefehle erfolgen. Es existieren 5 Runlevel, in denen bestimmte Anwendungen gestartet werden. Diese können in dem GUI-Anwendung 'StartManager' (Handbuch 'B5 Download & Debugging', Kapitel 'Allgemeines zum StartManager') unterhalb die jeweiligen Runlevel gesehen werden. Z.B. RunLevel 1 enthält 'Iosys', RunLevel 5 enthält 'Alarmserver', usw.

Eine Ausagbe der Kommandozeil-Optionen bekommen Sie mit dem Befehl 'AprolCmd -h'.

1.5.2 GetEnvi Der Name GetEnvi ist aus "get environment" abgeleitet. Dieser Aufruf zeigt Ihnen alle Umgebungsvariablen (Environments) des APROL-Systems, in dem Sie eingeloggt sind, an.

Aufruf: <rechner>:~ > GetEnvi

Das Ergebnis des Aufrufes zeigt die folgende Abbildung. Die Namen der Environments sprechen für sich .


Abbildung 10: Ergebnis vom Aufruf "GetEnvi"

1.5.3 ps Dieser Befehl stammt vom Linux bzw. von UNIX und zeigt Ihnen die auf dem Rechner unter Linux laufenden Prozesse an.

Jedes Programm, das unter Linux gestartet worden ist, wird als Prozess bezeichnet. Folglich sind alle Programme und Anwendungen unter APROL nach Linux-Konvention Prozesse.

Diesem Systembefehl können in verschiedenen Kombinationen Optionen angehängt werden. Wollen Sie mehr über diesen Befehl erfahren, so rufen Sie einfach in einem X-Term das Manual mit "man ps" auf. An dieser Stelle wird nur eine Kombination erläutert.


Aufruf: ps –ef | grep runtime

Für die folgende Erläuterung wird vorrausgesetzt, dass Ihr Runtime-System unter dem Linux-Login "runtime" eingerichtet und konfiguriert wurde.

Abbildung 11: Ergebnis vom Aufruf 'ps'

Über die User-ID (runtime) werden alle laufenden Prozesse des CC-Accounts "runtime" angezeigt. Nach der User-ID folgen Prozessidentifikation (PID), Parentprozessidentifikation (PPID), Startzeit des Prozesses, das Terminal, auf dem der Prozess gestartet wurde, die Rechnerzeit, die der Prozess bis zum Aufruf von ps beansprucht hat und das Kommando, mit dem der Prozess gestartet wurde.

1.5.4 Datenbankoptimierung Werden während der Projektierung mit dem CaeManager nicht mehr benötigte Daten in den Plänen gelöscht, kann es vorkommen, dass nicht mehr benutzte Instanzen innerhalb des Projektes vorhanden sind. Diese Instanzen vergrößern den Datenbankbereich in der caedb für dieses Projekt unnötigerweise. Im CaeManager erfolgt der Aufruf der Datenbankoptimierung über das Menü 'Datei / CAE-Datenbank / Datenbank-Optimierung'. Dieser Menüpunkt bezieht sich auf das aktuell geöffnete Projekt! Wird er angewählt, so werden alle im Projekt abgelegten Instanzen auf ihre Verwendung hin überprüft. Sollte dabei ermittelt werden, dass es sich um eine nicht mehr verwendete Instanz handelt, wird diese gelöscht. Da der Vorgang bei größeren Projekten durchaus länger dauern kann, wird der Fortschritt angezeigt.


Diese Funktionalität sollte lediglich kurz vor dem Projektabschluss aufgerufen werden, um die Datenbank von unnötigem Ballast zu befreien und so klein wie möglich zu halten (Datensicherung, Transport auf Tape / CD usw.). Ein häufiger Aufruf ist absolut nicht notwendig!


1.6 APROL Systemprogramme .

1.6.1 Iosys-Tools

Das APROL-Runtime-System verwaltet alle Prozessvariablen in der Prozessdatenbasis Iosys.

APROL bietet die Möglichkeit mit Konsolenanwendungen einen vielleicht notwendigen kurzen Überblick über einen Systemstatus zu erhalten. Diese Tools ermöglichen einen Einblick in die Iosys-Datenbasis sowie die Manipulation der Daten auf dem lokalen als auch auf einem entfernten Iosys.

Die Verwendung dieser Tools darf nur durch erfahrene Anwender erfolgen. Sie ersetzen nicht den ordnungsgemäßen Betrieb über die GUI-Anwendungen und dürfen nicht für eine reguläre Anlagensteuerung verwendet werden.

Es wird die Benutzung dieser Konsolen-Anwendungen im SysLogReport mit Zeitstempel, Rechnername, PID und Beschreibung dokumentiert. Eingriffe in die Prozessführung werden im AuditTrailReport aufgezeichnet. Die Iosys-Tools eignen sich besonders gut, um im Debugging bestimmter Variablen zu überprüfen oder zu setzen. Folgende Tools sind verfügbar.

IosStat (Iosys Statusinformationen)

IosLsClients (Liste aller Clients, die auf Iosys zugreifen)

IosLsObjects (Liste aller Prozessvariablen in einem Iosys)

IosEv (Chronologischer Ablauf von gefilterten Prozessvariablen)

IosInOut (Import und Export von Prozessvariablen)

pio (Prozessvariablen lesen / schreiben)

1.6.2 Erweiterung aller Iosys-Tools für Multi Runtime-Systeme

Einhergehend mit der Einführung von Multi Runtime-Systemen in APROL ist auch die Syntax der Iosys-Tools erweitert worden.

1.6.2.1 Aufrufoptionen

Für die Optionen '-iosys' und '-mask' können nun zusätzlich der Instanzname des APROL-Systems angegeben werden. Dieses wird für die nachfolgenden Beschreibungen immer als <INSTANZ> bezeichnet. Das aufgeführte Beispiel 'IosLsObjects' zeigt, welche zusätzlichen Aufrufe für die Optionen '-iosys' und '-mask' möglich sind:


Syntax bisher: IosLsObjects -iosys <HOSTNAME>:[PORT] -mask "*String*" Beispiel: IosLsObjects -iosys l3supp4064:0 -mask "APROL*_Idle*" Ausgabe: APROL_SYSTEM_01_M_IdleStatePercent APROL_SYSTEM_01_M_IdleStateWarning APROL_SYSTEM_01_M_IdleStateViolationTime Anmerkungen: Wird kein [PORT] angegeben, erfolgt ein Fallback auf den Port 0. IosLsObjects -iosys <HOSTNAME_MASTER>:[PORT], <HOSTNAME_SLAVE>:[PORT]-mask "*String*" Erweiterung für Multi-Runtime-Systeme IosLsObjects -iosys <INSTANZ> -mask "*String*" Beispiel: IosLsObjects -iosys APROL_SYSTEM_01 -mask "APROL*_Idle*" Ausgabe: APROL_SYSTEM_01_M_IdleStatePercent APROL_SYSTEM_01_M_IdleStateWarning APROL_SYSTEM_01_M_IdleStateViolationTime Anmerkungen: - IosLsObjects -iosys "*" -mask "*String*" Beispiel: IosLsObjects -iosys "*" -mask "APROL*_Idle*" Ausgabe: APROL_SYSTEM_01_M_IdleStatePercent APROL_SYSTEM_01_M_IdleStateWarning APROL_SYSTEM_01_M_IdleStateViolationTime APROL_SYSTEM_02_M_IdleStatePercent APROL_SYSTEM_02_M_IdleStateWarning APROL_SYSTEM_02_M_IdleStateViolationTime APROL_SYSTEM_01_M_IdleStatePercent APROL_SYSTEM_01_M_IdleStateWarning APROL_SYSTEM_01_M_IdleStateViolationTime Anmerkungen: Bei Verwendung der Wildcard "*" erfolgt eine Suche über alle Systeme, die in dem Projekt bekannt und aktiviert sind. IosLsObjects -mask "*String*"@<INSTANZ> -showIosysConnection Beispiel: IosLsObjects -mask "APROL*_Idle*"@APROL_SYSTEM_01 -showIosysConnection Ausgabe: APROL_SYSTEM_01_M_IdleStatePercent@APROL_SYSTEM_01 APROL_SYSTEM_01_M_IdleStateWarning@APROL_SYSTEM_01 APROL_SYSTEM_01_M_IdleStateViolationTime@APROL_SYSTEM_01 Anmerkungen: Der Parameter '-showIosysConnection' ist optional und zeigt zusätzlich an, welche Prozessvariable von welcher Iosys-Verbindung stammt. IosLsObjects -mask "*String*"@<INSTANZ> "*tcapc*" @<INSTANZ_2>


Beispiel: IosLsObjects -mask "APROL*_Idle*"@APROL_SYSTEM_01 "APROL*_Idle*"@APROL_SYSTEM_02 Ausgabe: APROL_SYSTEM_01_M_IdleStatePercent APROL_SYSTEM_01_M_IdleStateWarning APROL_SYSTEM_01_M_IdleStateViolationTime APROL_SYSTEM_02_M_IdleStatePercent APROL_SYSTEM_02_M_IdleStateWarning APROL_SYSTEM_02_M_IdleStateViolationTime Anmerkungen: Mit dieser Art des Aufrufs ist es möglich PVs von verschiedenen Systemen gleichzeitig abzufragen. Für die Verwendung der Aufrufoption '-mask' ist nun folgende Syntax erlaubt: <PV-name>[@<APROL-System-Instanz>]

Nicht erlaubt: IosLsObjects -iosys APROL_SYSTEM_01, APROL_SYSTEM_02 -mask …

1.6.2.2 Verarbeitung Zur Auflösung der <INSTANZ> Bezeichnung, werten alle Iosys-Tools während der Laufzeit die Datei $HOME/RUNTIME/runtime-system.cnf aus. Diese Datei wird während der Codegenerierung von dem Projekt automatisch erzeugt und enthält die grundsätzlichen Systemdefinitionen für die verwendeten APROL-Systeme. Jeder Abschnitt beginnt mit der Systemdefinition [HW/ Instanznamen des APROL-Systems]

Für eine temporäre Beobachtung oder Diagnose, kann eine Datei mit dem Namen runtime-user-system.cnf verwendet werden. Diese erlaubt einen Zugriff auf nicht in das Cae-Projekt eingebundenen AprolSystem-Instanzen und muss nach der gleichen Syntax aufgebaut sein wie die runtime-system.cnf. Nicht unterstützt wird aber eine projektübergreifende Kopplung.

Beispiel runtime-system.cnf: … [HW/APROL_SYSTEM_01] project_name=SamplesProject active_conn=l3supp4064:0 alasrv_self=dem1 ccname=APROL_Runtime_01_SYS ccdesc=B&R APC 810 Runtime Server, Default Runtime System cluster=l3supp4064.br-automation.com runtimeuser=runtime is_a_term=1 is_a_fas=1 is_a_serv=1 is_redundant=0


[HW/APROL_SYSTEM_02] project_name=SamplesProject active_conn=l3supp4064:1 alasrv_self=001 ccname=APROL_Runtime_02_SYS ccdesc=B&R APC 810 Runtime Server, Multi Runtime System 02 cluster=l3supp4064.br-automation.com runtimeuser=runtime2 is_a_term=1 is_a_fas=1 is_a_serv=1 is_redundant=0

1.6.2.3 IosStat Mit IosStat kann die Verfügbarkeit eines Iosys auf dem lokalen oder einem entfernten Runtime-System geprüft werden. Optional kann für den Fall, dass die Verbindung von der Anwendung IosStat zum Iosys verloren geht, eine Zeit definiert werden, nach der die Verbindung erneut aufgebaut werden soll (Reconnect-Zeit).

Option Erläuterung

-checkconn Test der Iosys-Verbindung mit ergebnisabhängigem Exitcode. Exitcode 0: Iosys gefunden Exitcode 1: Iosys nicht gefunden

-iosys <host[:port][,host[:port]]> -iosys <Instanzname APROL-SYSTEM>

Spezifikation des zu verwendenden Iosys Beispiele: -iosys 192.168.0.23:3 Verkürzte Fassung: -iosys :3 (lokales System, Port 3) -iosys 192.168.0.123 (Runtime-System, Port 0) -iosys APROL_SYSTEM_01 Instanzname des zu kontaktierenden APROL-Systems -iosys “*“ Alle Instanznamen der im Projekt bekannten und aktiven APROL-Systeme Bei einer Redundanz-Konfiguration müssen die Systeme angegeben werden in der Reihenfolge: <Master:[PORT]>,[<SLAVE:[PORT]] (Siehe auch Option reconnect) Default = lokales System: Port 0

-reconnect <time> Reconnect-Zeit (in Sekunden). Wird die Verbindung zu dem Iosys unterbrochen, wird nach der definierten Zeit erneut versucht, diese Verbindung herzustellen.


Option Erläuterung

Bei einer Redundanz-Konfiguration sollte dieser Parameter immer angegeben werden, da sonst bei einem erfolglosen Versuch eine Verbindung zu dem Master auszubauen, die Anwendung beendet wird. Beispiel: -reconnect 10

-preferUserSystems Bevorzugt gleichlautend definierte Systeme aus der runtime-user-system.cnf

-self <selfoption> eigene Instanzen-Bezeichnung nach Schema ANWENDUNGS-NAME_<SELF-OPTION> ändern Beispiel: -self TEST

-languageCode <areacode> keine Funktion (Default-Einstellung: Englisch)

-ver Kurzinformation über APROL- und Anwendungsversion

-version Detailinformationen über APROL- und Anwendungsversion

-info Name und Version der Anwendung und zugehöriger Bibliotheken mit folgenden Daten: Modul, Datum, Zeit, Typ, System, Architektur, Hostname

-showlog Öffnet den SysLogReport (Browserfenster mit Auflistung aller APROL- Anwendungsaufrufe des aktuellen Tages samt Kommandozeilen-Parameter, Datum, etc.)

-help, -h, -? Anzeige des Hilfetextes

Anwendungsbeispiele: Zustandsermittlung eines lokalen, auf Port 2 laufenden Iosys IosStat -iosys :2

positives Ergebnis: 2006.09.25 17:13:31 IosStat: Iosys found

negatives Ergebnis (fehlende Iosys-Verbindung): 2006.09.25 17:14:20 IosStat: Iosys not found or lost

Zustandsermittlung eines entfernten, auf Port 0 laufenden Iosys mit erneutem Verbindungsaufbau nach 5 Sekunden IosStat -iosys 192.168.0.12:0 -reconnect 5

positives Ergebnis: 2006.09.25 17:13:31 IosStat: Iosys found

negatives Ergebnis (fehlende Iosys-Verbindung): 2006.09.25 17:16:32 IosStat: Iosys not found or lost 2006.09.25 17:16:37 IosStat: Iosys not found or lost 2006.09.25 17:16:42 IosStat: Iosys not found or lost


Bedingte Ausgabe nach fehlender Kommunikation zum Iosys IosStat -iosys :1 -checkconn || echo "Iosys nicht gefunden."

Positives Ergebnis: 2006.09.25 17:20:05 IosStat: Iosys found 2006.09.25 17:20:05 IosStat: Leave with exitcode 0

negatives Ergebnis (fehlende Iosys-Verbindung): 2006.09.25 17:20:25 IosStat: Iosys not found or lost 2006.09.25 17:20:25 IosStat: Leave with exitcode 1 Iosys nicht gefunden.

1.6.2.4 IosLsClients IosLsClients ist in der Lage alle Clients, welche mit einem lokalen oder entfernten Iosys kommunizieren, aufzulisten. Optional kann beispielsweise eine Filterung über Suchmasken gesetzt werden. Um nach ähnlichen Variablennamen zu suchen, besteht die Möglichkeit der unscharfen Suche über die Levenshtein-Distanz, welche ein Maß für den Unterschied zwischen zwei Zeichenketten darstellt. Die Levenshtein-Distanz beschreibt die minimale Anzahl der Operationen Einfügen, Löschen und Ersetzen, um eine Zeichenkette in eine andere zu überführen. Beim Debugging kann mit IosLsClients überprüft werden, ob bestimmte Anwendungen am Iosys angemeldet sind, oder ob die Verbindung unterbrochen ist.

Option Erläuterung

-mask <mask> -mask “<mask>“@[<INSTANZ>]

Gefilterte Anzeige der verbundenen Clients. Die Benutzung von Wildcards ist möglich. Beispiel: -mask *InaDriver_* -mask “*InaDriver_*“@APROL_SYSTEM_01

-mask <mask> -mld <distance> Die Option "-mld" muss im Zusammenhang mit "-mask" Funktion verwendet werden. (Levenshtein-Distanz, um den Filteralgorithmus zu definieren). Beispiel: -mask HA_* -mld 1


Spezifikation des zu verwendenden Iosys Beispiele: -iosys 192.168.0.23:3 Verkürzte Fassung: -iosys :3 (lokales System, Port 3) -iosys 192.168.0.123 (Runtime-System, Port 0) -iosys APROL_SYSTEM_01 Instanzname des zu kontaktierenden APROL-Systems -iosys “*“ Alle Instanznamen der im Projekt bekannten und aktiven APROL-Systeme Bei einer Redundanz-Konfiguration müssen die Systeme


Option Erläuterung

angegeben werden in der Reihenfolge: <Master:[PORT]>,[<SLAVE:[PORT]] (Siehe auch Option reconnect) Default = lokales System: Port 0

-reconnect <time> Reconnect-Zeit (in Sekunden). Wird die Verbindung zu dem Iosys unterbrochen, wird nach der definierten Zeit erneut versucht, diese Verbindung herzustellen. Bei einer Redundanz-Konfiguration sollte dieser Parameter immer angegeben werden, da sonst bei einem erfolglosen Versuch eine Verbindung zu dem Master auszubauen, die Anwendung beendet wird. Beispiel: -reconnect 10


-showIosysConnection Anzeige der Iosys Verbindung

-showSystemInstanz Anzeige der Systeminstanz



-ver Kurzinformation über APROL-und Anwendungsversion

-version Detailinformationen über APROL-und Anwendungsversion


-showlog Öffnet den SysLogReport (Browserfenster mit Auflistung aller APROL-Anwendungsaufrufe des aktuellen Tages samt Kommandozeilen-Parameter, Datum, etc.)


Anwendungsbeispiele:

Anzeigen aller Clients eines entfernten, auf Port 2 laufenden Iosys mit definierter Reconnect-Zeit nach 5 Sekunden IosLsClients -iosys 192.168.0.42:2 -reconnect 5


positives Ergebnis: ... 14 eng1.InaDriver_01.8258 15 eng1.SysInfo_01.8248 16 op1.LoginServer_01.11124 ...

negatives Ergebnis (fehlende Iosys-Verbindung): Warten auf erfolgreiche Verbindung, bei kontinuierlichem Prüfen im 5 Sekunden- Intervall (Abbruch mit[Strg]+[C]).

Aufschlüsselung des Bezeichners:

Zusammensetzung der Instanzen-Bezeichnung am Beispiel eng1.InaDriver_09.8285:

eng1 :Rechnername InaDriver_ :Anwendungsname 09 :Self-ID (wird mit der "self"-Option gesetzt) 8285 :vom System vergebene PID

Auflisten der Clients auf einem lokalen, auf Port 0 laufenden Iosys mit eingegebener Maskierung und Levenshtein-Distanz IosLsClients -iosys 127.0.0.1:0 -mask *InaDriver_* -mld 1

positives Ergebnis: L E V E N S H T E I N - M O D E Distanz Bezeichner ======= ========== 0 eng1.InaDriver_098285 0 eng1.InaDriver_088279

negatives Ergebnis (fehlende Iosys-Verbindung): 2006.09.25 17:46:27 IosLsClients: Error ( main.cc, 247): cannot connect to IOSYS

Anzeige aller Clients welche den Text „Display“ enthalten und der zugehörenden Iosys Verbindung. IosLsClients -mask “*Display*” -showIosysConnection

Ausgabe: 1 l3supp4064.__unknown__@localhost:0.22147 2 l3supp4064.DisplayCenter_dem1@localhost:0.11314

1.6.2.5 IosLsObjects Dieses Werkzeug listet alle existierenden Prozessvariablen (PVs) innerhalb eines lokalen oder entfernten Iosys auf. Die Anzahl der aufgelisteten PVs läst sich optional begrenzen. Außerdem besteht auch bei IosLsObjects die Möglichkeit der unscharfen Suche über die Levenshtein-Distanz (siehe IosLsClients).


Programmoptionen:

Option Erläuterung

-max <object_count> Anzahl der zeilenweise aufgelisteten PVs +1 Default = 1024

-query Gibt den aktuellen Wert sowie Typ der PV wieder

-mask <mask> -mask “<mask>“@[<INSTANZ>] -mask <Plan-Instanzname>

Filterung von einer/mehreren PV (mit Wildcards möglich). Beispiel: -mask HA_* (Zeigt alle PVs beginnend mit „HA_“ an.) -mask “HA*“@APROL_SYSTEM_01 (Zeigt alle PVs beginnend mit „HA_“ von dem Aprol System mit Instanznamen „APROL_SYSTEM_01“an.) Filterung von PVs einer Plan-Instanz

-mask <mask> -mld <distance> Levenshtein-Distanz, um den Filteralgorithmus zu definieren (muss im Zusammenhang mit "-mask" stehen). Beispiel: -mask HA_* -mld 1

-pv <Pvname_1> [<Pvname_n>] Spezifizierung einer PV (mehrere PV-Namen durch Leerzeichen getrennt) Beispiel: -pv HA_RPSF_DI476_K1_12_01



-reconnect <time> Reconnect-Zeit (in Sekunden). Wird die Verbindung zu dem Iosys unterbrochen, wird


Option Erläuterung

nach der definierten Zeit erneut versucht, diese Verbindung herzustellen. Bei einer Redundanz-Konfiguration sollte dieser Parameter immer angegeben werden, da sonst bei einem erfolglosen Versuch eine Verbindung zu dem Master auszubauen, die Anwendung beendet wird. Beispiel: -reconnect 10










-help, -h, -? Anzeige des Hilfetextes Anwendungsbeispiele:

Auflisten der ersten fünf Prozessvariablen des Typs "Hardware-I/O" (beginnend mit "HA") auf einem entfernten Iosys mit der Portnummer 0 IosLsObjects -iosys 192.168.0.120:0 -mask HA* -max 4

Ergebnis: HA_RPSB_AI375_K1_05_AI01 HA_RPSB_AI375_K1_05_AI02 HA_RPSB_AI375_K1_05_AI03 HA_RPSB_AI375_K1_05_AI04 HA_RPSB_AI375_K1_05_AI05


Auflisten aller zu "TC243_1_TC243_BTI_1" ähnlichen (Levenshtein-Distanz = 3) PV auf einem lokalen Iosys mit der Portnummer 2 IosLsObjects -iosys 127.0.0.1:2 -mask TC243_1_TC243_BTI_1 -mld 3

positives Ergebnis: L E V E N S H T E I N - M O D E Distanz Bezeichner ======= ========== 0 TC243_1_TC243_BTI_1 1.5 TC243_1_TC243_BTI_2 3 TC244_1_TC244_BTI_1 3 TC245_1_TC245_BTI_1 ...

negatives Ergebnis (fehlende Iosys-Verbindung): 2006.09.25 18:45:30 IosLsObjects: Error ( main.cc, 331): cannot connect to IOSYS

Ermitteln des Datentyps sowie des aktuellen Wertes der PV "TC243_1_TC243_BTI_1" auf einem lokalen Iosys mit automatischer Reconnect-Zeit nach 5 Sekunden IosLsObjects -iosys 127.0.0.1:0 -mask TC243_1_TC243_BTI_1 -query -reconnect 5

positives Ergebnis: TC243_1_TC243_BTI_1 Int 1

negatives Ergebnis (fehlende Iosys-Verbindung): Warten auf erfolgreiche Verbindung, bei kontinuierlichem Prüfen im 5 Sekunden- Intervall (Abbruch mit[Strg]+[C]). Anzeige aller Objekte welche den Text "Display" enthalten und der zugehörenden Iosys Verbindung. IosLsObjects -mask "*Display*" -showIosysConnection

Ausgabe: APROL_SYSTEM_OPERATOR_01_M_AppDisplayCenter_dem3@localhost:0 APROL_SYSTEM_01_M_AppDisplayCenter_dem1_UsedMem@localhost:0 APROL_SYSTEM_01_M_AppDisplayCenter_dem1_UsedRMem@localhost:0 APROL_SYSTEM_01_M_AppDisplayCenter_dem2_UsedMem@localhost:0

1.6.2.6 IosEv IosEv ermöglicht die Aufzeichnung einer chronologischen Liste der angegebenen Variablen. Diese Aufzeichnung ist ereignisgesteuert und kann auf einen lokalen oder entfernten Iosys angewandt werden. Auf diese Weise können zum Beispiel Treibervariablen überwacht werden, um genaue Fehlerdiagnosen zu erstellen. Programmoptionen:

Option Erläuterung

-autoStop <time> Nach <time> Sekunden wird der IosEv automatisch beendet. Default = deaktiviert


Option Erläuterung

Beispiel: IosEv -pv TestVariable -autoStop 30

-mask <mask> -mask “<mask>“ [<INSTANZ>]

Filterung von einer/mehreren PV (mit Wildcards möglich) Beispiel: -mask HA_RPSF_* -mask “HA_RPSF_*“@APROL_SYSTEM_01

-vtdump [vtmask] PVs des Typs VSET werden mit dieser Option detailliert aufgeschlüsselt. Mit [vtmask] können bestimmte Vts herausgefiltert werden (siehe Vset und Vt). Beispiel: -vtdump `*info*`

-human Formatierung eines vtdump auf ein lesbares Format.

-pv <Pvname_1> [<Pvname_n>] Spezifizierung einer PV (mehrere PV-Namen durch Leerzeichen getrennt) Beispiel: -pv HA_RPSF_DI476_K1_12_01

-file <file> Einlesen von PVs aus einer externen Datei Beispiel: -file ./list/myListFile.lst Die Datei kann über IosLsObjects erzeugt werden (siehe Beispiel nach Tabelle).

-maxlines <count> Zeigt eine maximale Anzahl von Zeilen +1 an Beispiel: -maxlines 12 Default = 1024

-realformat <format> Numerischen Ausgabe der real-Werte wird so formatiert, dass anstatt einer Anzeige mit Exponenten eine genauere Anzeige erfolgt. Default = %%g

-intformat <format> Numerischen Ausgabe der integer-Werte wird so formatiert, dass anstatt einer Anzeige mit Exponenten eine genauere Anzeige erfolgt. Default = %%ld

-tsformat [real|time|timeus] Ausgabe von formatierten Werten von Zeitstempeln. Default = time

-x Zeigt zusätzlich zur Uhrzeit das Datum an.

-noheader Deaktivieren der Kopfzeile und "clear screen"-Funktion

-showidler Blendet die IDLE-Flag Änderungen ein (siehe Statusflags einer PV).


Option Erläuterung

-hideIpAddr Ausblenden der Host-IP Adresse

-hideCid Ausblenden der CID (PID) Nummer





-iosys_watchdog Timeout für Watchdog Default = 30s





-ver Kurzinformation über APROL-und


Option Erläuterung

Anwendungsversion





Anwendungsbeispiele: Überwachen der Prozessvariable "HA_RPSF_DI476_K1_12_01" mit einer maximalen Anzeige von fünf Zeilen. Die Prozessvariable ist in einem lokalen Iosys mit der Portnummer 2. IosEv -iosys :2 -pv HA_RPSF_DI476_K1_12_01 -maxlines 4

positives Ergebnis: EVENT NAME HOST CID TIME STATUS TYPE VALUE/ACC_CNT

------ ----------------------------- ------------- ------------ IVSQFP ---- -------------

CHA HA_RPSF_DI476_K1_12_01 010.049.083.150 29085 17:12:34.876 -VS--P INT 0


...

(insgesamt 5 Zeilen) Bei jeder Änderung der Prozessvariablen wird die chronologische Liste um einen Eintrag ergänzt. Beim Überschreiten des Parameters "maxlines" wird die gesamte Liste gelöscht und die Aufzeichnung startet erneut. negatives Ergebnis (PV nicht vorhanden): EVENT NAME HOST CID TIME STATUS TYPE VALUE/ACC_CNT

------ ----------------------------- ------------- ------------ IVSQFP ---- -------------

Aufschlüsselung der Ausgabe: EVENT NAME HOST CID TIME STATUS TYPE VALUE/ACC_CNT

------ ----------------------------- ------------- ------------ IVSQFP ---- -------------



...

"EVENT": Ereignis, welches die PV modifiziert "NAME": Name der PV "HOST": IP-Adresse der PV-Quelle "CID": PID des Versorgers "TIME": Zeit des aufgetretenen Ereignisses "STATUS": Status folgender Flags:


(I)dle, (V)alid (V), (S)ourced, (Q), (F)orce, (P)ersist "TYPE": Datentyp des PV-Wertes "VALUE/ACC_CNT": Wert der PV Überwachen definierter Prozessvariablen aus der externen Datei "5-pv.lst" ohne Spaltenüberschrift auf einem entfernten Iosys mit der Portnummer 0 IosEv -iosys 192.168.0.85:0 -file 5-pv.lst -noheader

Tipp bzw. Erstellen der Datei "5-pv.lst" durch Exportieren bestehender PVs aus dem Iosys. Die Auswahl beschränkt sich auf die Hardware I/Os des Controllers "RPSF", digitale Eingänge. In die Datei werden die ersten fünf PVs geschrieben. IosLsObjects -mask HA_RPSF_DI* -max 4 -iosys :2 > 5-pv.lst

Dateiinhalt "5-pv.lst": HA_RPSF_DI450_EXP1_11_01 HA_RPSF_DI450_EXP1_11_03 HA_RPSF_DI450_EXP1_11_04 HA_RPSF_DI450_EXP1_11_07 HA_RPSF_DI450_EXP1_11_08

positives Ergebnis: connecting pv HA_RPSF_DI450_EXP1_11_01 connecting pv HA_RPSF_DI450_EXP1_11_03 connecting pv HA_RPSF_DI450_EXP1_11_04 connecting pv HA_RPSF_DI450_EXP1_11_05 connecting pv HA_RPSF_DI450_EXP1_11_06 CHA HA_RPSF_DI450_EXP1_11_01 010.049.083.150 29085 17:10:14.280 -VS--P INT 0

CHA HA_RPSF_DI450_EXP1_11_03 010.049.083.150 29085 17:10:14.280 -VS--P INT 0




(Das Ergebnis kann mit dem Befehl IosEv -iosys 192.168.0.85:0 -file 5-pv.lst > umlenkdatei.lst auch in eine Datei umgeleitet werden. Mit dem Befehl tail –f umlenkdatei.lst wird der Inhalt dieser Datei angezeigt). negatives Ergebnis (fehlende Iosys-Verbindung): 2006.09.28 10:55:19 IosEv: Error ( main.c, 341): 192.168.0.85:0 IOSYS connecting ....

Überwachen einer VSET-Variable "testPV" mit Einsicht in den Inhalt, auf einem lokalen Iosys mit der Portnummer 0, sowie Auflisten aller IDLE-Ereignisse. IosEv -iosys 127.0.0.1:0 -pv testPV -vtdump -showidler

Exkurs: Erstellen einer PV vom Typ VSET (interne Variable "iVar" vom Typ STRING mit dem Wert "Hello World") auf einem entfernten Iosys mit der Portnummer 0. pio -iosys 10.49.83.150:0 -pv testPV -v 4-iVar:"Hello World" -sourced

Ergebnis: Vset set iVar(Vt_STRING) to Hello World


Ergebnis: EVENT NAME HOST CID TIME STATUS TYPE VALUE/ACC_CNT

------ --------------- --------------- ------ ------------ IVSQFP ---- --------------

IDLE- testPV 000.000.000.000 00000 01:00:00.000 ------ ??? ?

CHA testPV 010.049.083.228 05134 16:49:32.767 -V---- VSET ( iVar Vt_STRING Hello World )

IDLE+ testPV 010.049.083.228 05134 16:49:32.767 IV---- VSET ( iVar Vt_STRING Hello World )

IDLE- testPV 010.049.083.228 05134 16:49:32.767 -V---- VSET ( iVar Vt_STRING Hello World )

CHA testPV 010.049.083.228 05138 16:49:48.041 -V---- VSET ( iVar Vt_STRING Hello World )

IDLE+ testPV 010.049.083.228 05138 16:49:48.041 IV---- VSET ( iVar Vt_STRING Hello World )

Eventanzeige aller PVs ohne den Spaltenkopf, welche den Text "Sinus" enthalten, mit einer Werteformatierung auf die Anzeige von 2 Vor- und 3 Nachkommastellen und der zugehörenden Iosys Verbindung. IosEv –mask „*Sinus*“ –realformat 02.3f –noheader -showIosysConnection

Ausgabe: CHA DemoSinus120Grad@localhost:0 010.049.080.249 09595 12:03:07.471 -VS--P REAL -0.753

CHA DemoSinus240Grad@localhost:0 010.049.080.249 09595 12:03:07.471 -VS--P REAL 0.946

CHA SYS_AT_Gen_Sin.Sinus@localhost:0 010.049.080.249 09593 12:03:07.732 -VS--P REAL 56.645

CHA SYS_AT_Gen_Sin_d.Sinus@localhost:0 010.049.080.249 09593 12:03:07.732 -VS--P REAL 56.645

CHA SYS_AT_Sinus120.Sinus@localhost:0 010.049.080.249 09593 12:03:07.732 -VS--P REAL 18.483

CHA SYS_AT_Sinus240.Sinus@localhost:0 010.049.080.249 09593 12:03:07.732 -VS--P REAL 104.874

CHA DemoSinus@localhost:0 010.049.080.249 09595 12:03:07.872 -VS--P REAL -0.930

1.6.2.7 IosInOut Mit IosInOut kann der Inhalt von definierten Prozessvariablen (PVs) eines lokalen oder entfernten Iosys exportiert werden. Es besteht die Möglichkeit, diese (oder eine selbst erzeugte) Liste wieder in das System zu importieren. Bei der Fehleranalyse kann die mit IosInOut erzeugte Liste den Zustand definierter PVs zu einem bestimmten Zeitpunkt darstellen.

Im AuditTrailReport erfolgt eine Aufzeichnung aller Eingriffe in die Prozessführung des IosInOut unter "Externe Prozessführung".

Variablen mit dem Status „(S)ource“ können nicht gesetzt werden.

Syntax: IosInOut -in|-out -datafile <filename> -pvlistfile <filename> [-replace] [-checktype] [options]

Programmoptionen:

Option Erläuterung

-in <pvlistfile> [-time?] Werte aus einer Datei im Iosys setzen Optional manuelles Setzen der Zeit, wann PV gesetzt wurde

[-timeStamp <t>] Zeitstempel (nur in Verbindung mit –in)

[-timeString <s>] Zeitstring (nur in Verbindung mit -in)

[-timeBack <s>] sekündliche Differenz zur aktuellen Zeit (nur in Verbindung mit -in)

-iosys <host[:port][,host[:port]]> Spezifikation des zu verwendenden Iosys


Option Erläuterung

-iosys <Instanzname APROL-SYSTEM>

Beispiele: -iosys 192.168.0.23:3 Verkürzte Fassung: -iosys :3 (lokales System, Port 3) -iosys 192.168.0.123 (Runtime-System, Port 0) -iosys APROL_SYSTEM_01 Instanzname des zu kontaktierenden APROL-Systems -iosys “*“ Alle Instanznamen der im Projekt bekannten und aktiven APROL-Systeme Bei einer Redundanz-Konfiguration müssen die Systeme angegeben werden in der Reihenfolge: <Master:[PORT]>,[<SLAVE:[PORT]] (Siehe auch Option reconnect) Default = lokales System: Port 0



-out <pvlistfile> Aktuelle PV-Werte aus dem Iosys in die Datei <pvlistfile> einfügen (Standard). Aus dem Iosys werden Datentyp und Wert der PV sowie Informationen über Statusflags exportiert, jedoch nicht der Name der PV. Die Datei kann mit dem Befehl IosLsObjects automatisch erstellt werden.

-xmlOut Ausgabe im XML-Format auf dem Bildschirm

-type Hinzufügen des PV-Typs, valid- und Remanenz-Flag zur Ausgabe (siehe Statusflags einer PV).

-connInfo Ausgabe der zugehörenden Iosys Verbindung

-pvlistfile <name> Angabe der PV-Namen enthaltenden Datei (pro Zeile einen Namen). Die Datei kann mit dem Befehl IosLsObjects automatisch erstellt werden. Standard-Dateierweiterung: "lst" Beispiel:


Option Erläuterung

-pvlistfile myPVList.lst

-datafile <name> Angabe der Datei mit den zu schreibenden/lesenden PV-Werten (pro Zeile einen Wert). Default-Dateierweiterung: "dat" Beispiel: -datafile myDataFile.dat

-path <path> Pfad zur Datei <pvlistfile> Beispiel: -path ./toPVListings/

-replace Überschreibt die aktuelle Datei <datafile>.

-noStringQuotes PV-Werte im Datentyp STRING werden ohne Hochkommata ausgegeben







-help, -h, -? Anzeige des Hilfetextes Anwendungsbeispiele: Exportieren der Iosys-Werte der in der Datei "5-pv.lst" definierten PVs mit Angabe des Datentyps und Remanenz-Flag auf einem lokalen Iosys mit der Portnummer 2. Das Ergebnis wird in die Datei "5-pv.dat" geschrieben. IosInOut -iosys 127.0.0.1:2 -type -out -pvlistfile ./5-pv.lst -datafile ./5-pv.dat

Exkurs: Erstellen der Datei "5-pv.lst" durch Exportieren bestehender PVs aus dem Iosys. Die Auswahl beschränkt sich auf die Hardware I/Os des Controllers "RPSF", digitale Eingänge. In die Datei werden die ersten fünf PVs geschrieben. IosLsObjects -mask HA_RPSF_DI* -max 4 -iosys :2 > 5-pv.lst


Dateiinhalt "5-pv.lst" HA_RPSF_DI450_EXP1_11_01 HA_RPSF_DI450_EXP1_11_03 HA_RPSF_DI450_EXP1_11_04 HA_RPSF_DI450_EXP1_11_05 HA_RPSF_DI450_EXP1_11_06

positives Ergebnis: Dateiinhalt "5-pv.dat" INT, 0, valid, persistent INT, 0, valid, persistent INT, 0, valid, persistent INT, 0, valid, persistent INT, 0, valid, persistent

negatives Ergebnis (wenn Eingabe-/Ausgabedatei nicht gefunden wird): 2006.09.28 13:26:38 IosInOut: Error ( IosInOut.c, 406): Unable to open file /home/opr/RUNTIME/IosInOut/5-pv.dat !

Erzeugen einer XML-Datei "5-pv.xml" mittels einer definierten PV-Liste "5-pv.lst", aus einem entfernten Iosys mit der Portnummer 0 und Wiederverbindung nach fünf Sekunden. IosInOut -iosys 10.49.83.150:0 -xmlOut -pvlistfile 5-pv.lst -path ./ -reconnect 5 > 5-pv.xml

positives Ergebnis: Dateiinhalt "5-pv.xml" <iosys> <appInfo> <progName>IosInOut</progName> <progVersion>2.1.5</progVersion> <aprolRel>APROL R 3.4-000</aprolRel> <copyRight> © 1995-2006 Bernecker + Rainer Industrie-Elektronik Ges.m.b.H. </copyRight> </appInfo> <queryInfo> <server>cc4opr01</server> <user>cc4opr</user> <time>28.09.2006 13:37:22 CEST</time> </queryInfo> <data> <pv>HA_RPSF_DI450_EXP1_11_01</pv> <value>0</value> <type>INT</type> <valid>false</valid> <persistent>true</persistent> </data> ...

negatives Ergebnis (fehlende Iosys-Verbindung): Warten auf erfolgreiche Verbindung, bei kontinuierlichem Prüfen im 5 Sekunden- Intervall (Abbruch mit[Strg]+[C]).


1.6.2.8 pio Dieses Werkzeug dient zur Erzeugung sowie zur gezielten Statusabfrage von Prozessvariablen (PVs) in einem lokalen oder entfernten Iosys. Bestehende PVs können angezeigt und gesetzt werden. Eine besondere Beschränkung der Benutzerrechte für den pio ist nicht implementiert.

Im AuditTrail-Report erfolgt eine Darstellung aller Eingriffe in die Prozessführung des pio in der Aktionsgruppe 'Externe Prozessführung'. Bei der Werteänderung via 'pio' wird der Projekt-Kontext nicht mit erfasst, sodass für die Darstellung im Report ein ggf. gesetzter 'Projekt'-Filter zurückgesetzt werden muss.

Option Erläuterung

-pv <name> Spezifizierung der PV

-g [-wait] PV-Wert auslesen

-get [-wait] Die folgenden Informationen der PV ausgeben: - Name - Typ - Wert

-getmask -g [-wait] Gibt den Wert und die gesetzten Flags der PV wieder. (muss in Zusammenhang mit "-g"-Option stehen)

-wait Versetzt das "pio" in Wartezustand bis ein Ereignis der beobachteten PV auftritt.

-s <value> Setzt den PV-Wert auf <value>. Ist die PV ein String, kann sie mit einer Zahl oder einem String geschrieben werden. (Sollte die PV nicht existieren, wird eine neue angelegt. Ist diese PV nicht remanent, bleibt sie so lange bestehen, bis sich der letzte verbundene Client von ihr trennt. Siehe Statusflags einer PV.) Optional manuelles Setzen der Zeit, wann PV gesetzt wurde

[-timeStamp <t>] - Zeitstempel (double [sec.usec]) (nur in Verbindung mit -s)

[-timeString <s>] - Zeitstring (nur in Verbindung mit -s)

[-timeBack <s>] - sekündliche Differenz zur aktuellen Zeit (nur in Verbindung mit -s)

-source Setzt das "sourced"-Flag der PV (siehe Statusflags einer PV).

-noUnsource Eine Variable wird nach dem beenden des pio im Iosys nicht mehr als ungültig markiert.

-invalid Setzt das "invalid"-Flag der PV (siehe Statusflags einer PV).


Option Erläuterung

-valid Setzt das "valid"-Flag der PV (siehe Statusflags einer PV).

-v VTtype-VTname [:VTvalue] Setzt den Typ einer PV auf VSET und vergibt dieser einen Wert (siehe Vset). 0: Vt-Typ wird nicht geändert 2: Vt-Typ wird in INT geändert 3: Vt-Typ wird in DOUBLE geändert 4: Vt-Typ wird in STRING geändert 8: Vt-Typ wird in BOOL geändert 9: Vt-Typ wird in TIMESTAMP geändert Beispiel: -v 2-myName[:5] (Typ: INT, Name: myName [Wert:5])

-setType <type> wandelt eine PV in folgenden Typ um: 0: kein Typ 1: INT 2: REAL 3: STRING (Standard) 7: TIMESTAMP



-reconnect <time> Reconnect-Zeit (in Sekunden). Wird die Verbindung zu dem Iosys unterbrochen, wird nach der definierten Zeit erneut versucht, diese Verbindung herzustellen. Bei einer Redundanz-Konfiguration sollte dieser Parameter immer angegeben werden, da sonst bei einem erfolglosen Versuch eine Verbindung zu dem Master auszubauen, die Anwendung beendet wird. Beispiel:


Option Erläuterung

-reconnect 10


-iosys_watchdog Timeout für Watchdog Default = 30s

-connInfo Ausgabe der zugehörenden Iosys Verbindung

-newFormat Mehrfache Ausgabe des Wertes der Variablen








Anwendungsbeispiele: Ereignisbezogenes Ausgeben von detaillierten Informationen über eine PV, welche auf einem lokalen Iosys mit der Portnummer 2 gehalten wird. pio –iosys :2 -pv HA_RPSF_DI476_K1_12_01 -get -wait positives Ergebnis: HA_RPSF_DI476_K1_12_01 - pv of type INT, current value = 0 = 0x0

negatives Ergebnis (fehlende Iosys Verbindung): 2006.09.28 14:14:37 pio: Error ( pio.c, 189): cannot connect to IOSYS

1.6.3 Erklärungen zu Vsets, Vts und Statusflags einer PV .


1.6.3.1 Vset Eine TBase-Datenbank ist in Form einer Baumstruktur aufgebaut. Knotenpunkte in der TBase-Datenbank werden als Vsets bezeichnet. Sie können leer sein oder weitere Daten enthalten, beispielsweise weitere Vsets. Folgendes Schema zeigt die Struktur der TBase-Datenbank, wobei das Vset am Ende des Pfades leer ist: \L\L/IEC61131_3\B/ADD_INT\V1.0\I ( )

1.6.3.2 Vt Vts sind Daten, die in einem Vset enthalten sein können. Ein Vt besteht stets aus einem eindeutigen Bezeichner, einem Datentyp und einem passenden Wert. Dazu folgendes Beispiel: \L\L/IEC61131_3\B/ADD_INT\V1.0\C-CODE ( source = "return( IN01 + IN02 );" , )

In den Klammern am Ende des Pfades ist ein Vt enthalten. Der Bezeichner ist "source", der Datentyp "Vt_STRING" und der Inhalt "return ( IN01 + IN02 );". Der Inhalt des Vts kann jede beliebige Zeichenkette enthalten. In diesem Beispiel ist es ein C-Code Fragment.

1.6.3.3 Statusflags einer PV Eine Prozessvariable im Iosys besteht aus einem Namen, einem Status und einem Wert. Der Status der PV wird durch verschiedene Statusflags definiert, die nun kurz beschrieben werden.

Statusflag Erläuterung

I= idle Das idle-Flag wird auf True gesetzt, wenn nur ein Prozess mit der PV verbunden ist, z. B. beim Erzeugen der PV.

V= valid Sind der PV sowohl ein Typ als auch ein Wert zugewiesen, wird das valid-Flag auf True gesetzt. Erhält die PV durch einen Verbindungsverlust zum Controller einen undefinierten Zustand, wird dieses Flag auf False gesetzt; die PV ist demnach invalid.

Q= source Das source-Flag ist nur für Abfragen in der Iosys-Bibliothek relevant. Es kennzeichnet den verbundenen Client als Versorger, wodurch er Schreibrechte für die PV erhält. Das Versorger-Konzept ist eine Grundfunktion in APROL, die sicherstellt, dass eine PV nur von einer Quelle geschrieben werden kann. Hat ein Prozess den Versorgerstatus für eine PV erhalten, kann er davon ausgehen, dass nur er das Recht hat, die PV zu ändern.

S= sourced Das sourced-Flag zeigt an, dass der PV ein Versorger zugewiesen ist.

F= force Das force-Flag ist für zukünftige Anwendungen reserviert.


Statusflag Erläuterung

P= persist Eine remanente PV ist an dem gesetzten Remanenz-Flag zu erkennen. Remanenz im Iosys heißt, dass das der Wert und der Typ der remanenten PV beim Beenden des Iosys in einer Remanenzdatei geschrieben werden und beim Starten des Iosys aus dieser wiederhergestellt werden.

1.7 Besonderheiten

In diesem Kapitel werden Besonderheiten, deren Vorhandensein innerhalb der APROL-Systeme nicht sofort einsichtig sind, beschrieben. An dieser Stelle sind die versierten UNIX- bzw. Linux-Experten angesprochen.

Linux-Benutzer aprolsys

Die Datei rhosts und aprolsys

Systemvariablen

1.7.1 Linux-Benutzer aprolsys

Der aprolsys hat in einem Prozessleitsystem unter APROL eine besondere Funktion. Er ist auf allen APROL-Servern vorhanden und gehört zur Linux-Benutzergruppe aprol, zu denen auch alle anderen APROL-Linuxbenutzer gehören. Der Linux-Benutzer aprolsys übernimmt eine zentrale Rolle innerhalb eines APROL-Servers, da er Gruppenzugriffsberechtigung hat. Unter seiner Benutzer-Id wird der Datenbankserver TbaseServer gestartet, der auf alle CAE-Datenbanken dieses APROL-Servers zugreifen kann. Weiter ist die gesamte APROL-Software, die unter /opt/aprol installiert wird, als aprolsys-Benutzer installiert. So ist gewährleistet, dass nur Benutzer der Gruppe aprol die entsprechenden Berechtigungen haben.

1.7.1.1 Die Datei rhosts und aprolsys Die Datei rhosts ist für alle CC-Accounts identisch. Sie wird bei dem Build der Control Computer-Tasks erzeugt und enthält alle im CaeManager konfigurierten Rechner mit den entsprechenden Systemen. Auch der Engineering-Server ist mit dem Engineering-System in der Datei enthalten. Die Datei wird bei dem Terminal- und Server-Download in die entsprechende Systemumgebungen (Verzeichnis $HOME) der einzelnen Systeme kopiert. Zusätzliche Einträge sind vom Systemadministrator nur noch in der Datei /etc/hosts.equiv vorzunehmen.


1.8 Systemvariablen Die Systemvariablen dienen zur Eigenüberwachung eines Runtime-Systems und zur Überwachung des Linux Betriebssystems in den GUI-Anwendungen des Prozessleitsystems. Mit der Übernahme der Systemvariablen in das Engineering, also der Anzeige in speziellen Prozessgrafiken, der Übernahme in das Alarm- und Meldesystem und auch dem Trendsystem eines Prozessleitsystems unter APROL wird folgendes erreicht:

Erhöhung der Sicherheit des Prozessleitsystems durch Eigenüberwachung, wie zum Beispiel: Generierung von Meldungen bei Speichermangel oder zu geringen Festplattenkapazitäten, Anzeige von inaktiven aber benötigten Programmen usw.

Schnelle Übersicht des Systemzustandes sowohl des Betriebssystems Linux wie auch des Prozessleitsystems.

Der Operator des Prozessleitsystems erhält, wenn ein entsprechendes Engineering vorgenommen wurde, im Klartext Informationen über den Systemzustand und kann diese an den Systemadministrator weitergeben.

Die Werte der Systemvariablen werden vom Programm SysInfo versorgt. Die Informationen über die zu überwachenden APROL-Programme holt sich SysInfo vom Iosys, die restlichen Informationen vom Linux Betriebssystem. An dieser Stelle ist zu erkennen, dass nur Informationen über den Rechner mit Systemvariablen zu erlangen sind, auf dem SysInfo selbst läuft. SysInfo verbindet sich immer zum aktuellen Iosys des Runtime-Systems. Sollen Systemvariablen von APROL-Anwendungen auf einem Rechner ohne laufenden Iosys (Operator-System auf eine Operator-Station) ausgewertet werden, müssen diese Anwendungen eine Verbindung zum Iosys haben. Wie die Systemvariablen in einen CFC übernommen werden, entnehmen Sie bitte der APROL Dokumentation "B2 Projekt Engineering", Kapitel Eintrag von Systemvariablen.

1.8.1 Systemvariablen für Anwendungen Die Systemvariablen für die einzelnen Anwendungen geben mit ihrem Rückgabewert (Typ = INT) Aufschluss über den Status der Anwendungen. Folgende Rückgabewerte sind möglich: Rückgabe-Wert Erläuterung

0 Fehler! Die Variablen werde nicht versorgt, es ist keine Information über den Zustand der Anwendung zu bekommen. Mögliche Ursache: Das Programm ist nicht gestartet. Es besteht auch die Möglichkeit, dass der Iosys bzw. SysInfo oder beide Programme nicht gestartet wurden.

1 Die Anwendung wurde gestartet und läuft. 2 Zur Zeit keine Funktion 3 Zur Zeit keine Funktion Der Name dieser Systemvariablen setzt sich wie folgt zusammen: <Instanz-Bezeichnung des Rechners>_<M | S >_App<Anwendung>_<Self-ID der Anwendung>


Beispiel: CC01_M_AppLoginServer_dai1

Für die Nomenklatur der Systemvariablen gilt: Liegt ein redundantes System vor, wird der konfigurierte Slave mit dem Buchstaben "S" gegennzeichnet.

Es existieren einige Anwendungen, deren Status oder Speicherbedarf nicht überwacht wird, wie z.B. OperatorManager oder AlarmViewer.

Bitte beachten Sie, dass in der Syntax für die Systemvariablen zur Überwachung der Control Computer-Task keine Self-ID verwendet wird!

Die Systemvariablen für die Überwachung der CC-Task haben folgende Syntax: <Instanzname>_<M | S>_AppCCT_<Taskname>_<Verwendung>

Redundanz-Variablen der Anwendungen In einem redundanten System kann die Ermittlung der aktuell prozessführenden Anwendung gegebenenfalls erforderlich sein. Dies wird über die Auswertung der Redundanz-Variablen ermöglicht. Der Name dieser Systemvariablen setzt sich wie folgt zusammen: <Instanz-Bezeichnung des Rechners>_<M | S >_App<Anwendung>_<Self-ID der Anwendung>_ReduActiv

Bei einer prozessführenden Anwendung auf diesem Server entspricht der Wert der Redundanz-Variablen der Prozess-ID dieser Anwendung. Ist die Anwendung auf diesem Server nicht prozessführend, hat die Variable den Wert "0". Beispiel: CC01_M_AppUcbServer_dai1_ReduActiv

Bei der Realisierung einer Prozess-Redundanz auf einem Kompakt-System, wird auch nur eine Redundanz-Variable erzeugt. Der Wert dieser Variablen ändert sich bei einer Redundanz-Umschaltung von der PID der inaktiv gewordenen Anwendung auf die PID der aktuell prozessführenden Anwendung.

Im CaeManager können Sie eine Redundanz-Variable auf der Eingangsleiste des CFCs platzieren und in der Logik verwenden. Wählen Sie dazu im Kontextmenü "System-Variable". In dem sich öffnenden Dialog werden die vorhandenen Systemvariablen zur Auswahl angeboten, wobei die Redundanz-Variablen mit "_ReduActiv" enden.


Abbildung 12: Auswahl der Redundanz-Variablen

Überwachung des Speicherbedarfs der Runtime-Anwendungen Zur Überwachung des Speicherbedarfs der Runtime-Anwendungen stehen Ihnen die Systemvariablen mit der Nomenklatur <Instanz-Bezeichnung des Rechners>_<M | S >_App<Anwendung>_<Self-ID der Anwendung>_UsedMem und <Instanz-Bezeichnung des Rechners>_<M | S >_App<Anwendung>_<Self-ID der Anwendung>_UsedRMem zur Verfügung. Die Systemvariablen sind vom Typ "LREAL". Der Wert dieser Systemvariable wird mit der Größe des zur Zeit vom Prozess benötigten virtuellen Speichers in [MB] gesetzt. Kann der Prozess oder die Information nicht ermittelt werden, wird die Variable auf den Wert"-1" gesetzt.


1.8.2 Systemvariable zur Überwachung des Redundanz-Status

Die Systemvariable <Instanz-Bezeichnung des Rechners>_<M | S >_RedundancyState ist vom Typ SINT und dient der Status-Ermittlung der Server-Redundanz. Folgende Rückgabewerte sind möglich:

Rückgabewert Erläuterung

2 Der Rechner ist der konfigurierte Master und z. Zt. prozessführend. 1 Der Rechner ist der konfigurierte Slave und z. Zt. prozessführend. 0 Der Rechner ist nicht prozessführend, jedoch online. -1 Der Rechner ist betriebsbedingt "offline"

(d.h. das APROL-System ist gestoppt). -2 Der Rechner ist (unerwartet) "offline"

D. h. stromlos, ggf. nach Verlust der Versorgungsspannung ohne UPS oder im Netzwerk nicht zu erreichen.

Liegt keine Server-Redundanz vor, so kann die Systemvariable ausschließlich den Rückgabewert "2" liefern.

Die Systemvariable <Instanz-Bezeichnung des Rechners>_<M | S >_RedundancyState ist ausschließlich auf einem redundanten Runtime-Server verfügbar.

1.8.3 Systemvariablen für Speicher und Festplattenkapazität Bei Verwendung dieser Systemvariablen ist zu beachten: Unter Linux sind keine einzelnen Festplatten mit Buchstabenbezeichnung bekannt und Partitionen sind als Verzeichnisse im Dateisystem angegeben. Festplatten werden standardmäßig unter einem Namen im root-Verzeichnis eingebunden. Man spricht dann vom Mountpoint. Falls Sie auf einem Rechner zusätzlich gemountete Datenträger überwachen wollen, so können Sie bei der Konfiguration von SysInfo (Systemüberwachung) für die frei wählbaren Partitionen 1 bis 4 die entsprechenden Mountpoints eintragen, damit diese dann überwacht werden. Die Systemvariablen haben folgenden Präfix: <Instanz-Bezeichnung des Rechners>_<M | S >

Abbildung 13: Schema zum "Speicher-Management eines Linux-Servers"


Variable Erläuterung Typ

_FreeAPROLDATASpace Diese Systemvariable gibt die Größe des freien Speicherplatzes der APROL_DATA-Partition in MByte an. Wurde für APROL_DATA keine separate Partition erstellt, so werden die Daten der Root Partition ausgegeben.

LREAL

_FreeMemory Aktuell ungenutzer Speicher Diese Systemvariable gibt die Größe des ungenutzten RAM-Speichers in MByte an. Das Speichermanagement eines Linux-Systems wird den zur Verfügung stehenden RAM-Speicher (zumindest nach einiger Laufzeit) immer nahezu komplett ausnutzen. Einen nicht zu vernachlässigender Teil des Speichers benutzt das Betriebssystem intern als Buffer bzw. Cache-Bereich. Deshalb ist diese Größe allein kein Kriterium dafür, ob beim Speichermanagement Probleme vorliegen.

LREAL

_FreeMemoryViolationTime Zeit der Speicherschutzverletzung [s]. Beachten Sie bitte die nachfolgende Beschreibung zur Parametrierung.

DINT

_FreeMemoryWarning Warnung bei voll ausgelastetem Arbeitsspeicher. Beachten Sie bitte die nachfolgende Beschreibung zur Parametrierung.

BOOL

_FreePartition1Space Freie Kapazität der zusätzlichen Partition 1 [MB] LREAL -- ... -- ... -- _FreePartition4Space Freie Kapazität der zusätzlichen Partition 4 [MB] LREAL _FreeRootDiskSpace Freie Kapazität der Root-Partition [MB] LREAL FreeRssMemory Aktuell ungenutzer RSS-Speicher

(RSS=Resident Set Size) Diese Systemvariable gibt die Größe des ungenutzten RSS-Speichers in MByte an. Der RSS-Speicher ist der Teil des benutzten RAM-Speichers, der ausschließlich Programmcode und -daten (Heap und Stack) enthält. Buffer- und Cache-Bereiche gehören nicht dazu. Das Speichermanagement eines Linux-Systems wird den zur Verfügung stehenden RAM-Speicher (zumindest nach einiger Laufzeit) immer nahezu komplett ausnutzen. Einen nicht zu vernachlässigender Teil des Speichers benutzt das Betriebssystem intern als Buffer bzw. Cache-Bereich

LREAL



_FreeSwapMemory Aktuell freier Swap-Speicher Diese Systemvariable gibt die Größe des ungenutzten Swap-Speichers in MByte an. (Swap=Auslagerungsspeicher auf der Festplatte). Das Speichermanagement eines Linux-Systems wird den zur Verfügung stehenden RAM-Speicher (zumindest nach einiger Laufzeit) immer nahezu komplett ausnutzen. Einen nicht zu vernachlässigender Teil des Speichers benutzt das Betriebssystem intern als Buffer bzw. Cache-Bereich. Sollte wegen der Anzahl oder der Größe der Programme der Speicherplatz im RAM nicht ausreichen, lagert das Betriebssystem unbenutzte Speicherseiten in den Swap-Bereich aus, d.h. sie werden auf Festplatte ausgelagert.

LREAL

_APROLDATASpace Größe der APROL_DATA-Partition [MB]. Wurde für APROL_DATA keine separate Partition erstellt, so werden die Daten der Root Partition ausgegeben.

LREAL

_Partition1Space Größe der zusätzlichen Partition 1 [MB] LREAL -- ... -- ... -- _Partition4Space Größe der zusätzlichen Partition 4 [MB] LREAL _RootDiskSpace Größe der Root-Partition.

Diese Systemvariable gibt die Größe der Root-Partition in MByte an.

LREAL

_SystemType Ermöglicht eine Unterscheidung zwischen Runtime/Operator/Gateway-Systeme. SystemType kann folgende Werte annehmen: 1 = Runtime-System 2 = operator-System 3 = Runtime-System mit integriertem Operator-System 4 = Gateway-System

SINT



_TotalMemory Größe des verfügbaren Speichers. Diese Systemvariable gibt die Größe des verfügbaren Speichers (=gesteckter RAM-Speicher) in MByte an. Das Speichermanagement eines Linux-Systems wird den zur Verfügung stehenden RAM-Speicher (zumindest nach einiger Laufzeit) immer nahezu komplett ausnutzen. Einen nicht zu vernachlässigender Teil des Speichers benutzt das Betriebssystem intern als Buffer bzw. Cache-Bereich. Sollte wegen der Anzahl oder der Größe der Programme der Speicherplatz im RAM nicht ausreichen, lagert das Betriebssystem unbenutzte Speicherseiten in den Swap-Bereich aus, d.h. sie werden auf Festplatte ausgelagert.

LREAL

_TotalSwapMemory Größe des verfügbaren Swap-Speichers Diese Systemvariable gibt die Größe des verfügbaren Swap-Speichers in MByte an. (Swap=Auslagerungsspeicher auf der Festplatte). Das Speichermanagement eines Linux-Systems wird den zur Verfügung stehenden RAM-Speicher (zumindest nach einiger Laufzeit) immer nahezu komplett ausnutzen. Einen nicht zu vernachlässigender Teil des Speichers benutzt das Betriebssystem intern als Buffer bzw. Cache-Bereich. Sollte wegen der Anzahl oder der Größe der Programme der Speicherplatz im RAM nicht ausreichen, lagert das Betriebssystem unbenutzte Speicherseiten in den Swap-Bereich aus, d.h. sie werden auf Festplatte ausgelagert.

LREAL

_UsedAPROLDATASpace Benutzter Speicherplatz der APROL_DATA-Partition. Diese Systemvariable gibt die Größe des benutzten Speicherplatzes der APROL_DATA-Partition in MByte an. Wurde für APROL_DATA keine separate Partition erstellt, so werden die Daten der Root Partition ausgegeben.

LREAL



UsedMemory Größe des benutzen Speichers Diese Systemvariable gibt die Größe des benutzten RAM-Speichers in MByte an. Das Speichermanagement eines Linux-Systems wird den zur Verfügung stehenden RAM-Speicher (zumindest nach einiger Laufzeit) immer nahezu komplett ausnutzen. Einen nicht zu vernachlässigender Teil des Speichers benutzt das Betriebssystem intern als Buffer bzw. Cache-Bereich. Deshalb ist diese Größe allein kein Kriterium dafür, ob beim Speichermanagement Probleme vorliegen.

LREAL

UsedRssMemory Aktuell benutzter RSS-Speicher Diese Systemvariable gibt die Größe des benutzten RSS-Speichers in MByte an. (RSS=Resident Set Size). Der RSS-Speicher ist der Teil des benutzten RAM-Speichers, der ausschließlich Programmcode und -daten (Heap & Stack) enthält. Buffer- und Cache-Bereiche gehören nicht dazu. Das Speichermanagement eines Linux-Systems wird den zur Verfügung stehenden RAM-Speicher (zumindest nach einiger Laufzeit) immer nahezu komplett ausnutzen. Einen nicht zu vernachlässigender Teil des Speichers benutzt das Betriebssystem intern als Buffer bzw. Cache-Bereich.

LREAL

UsedPartition1Space Belegte Kapazität der zusätzlichen Partition 1 [MB]

LREAL

-- ... -- ... -- _UsedPartition4Space Belegte Kapazität der zusätzlichen Partition 4

[MB] LREAL

_UsedRootDiskSpace Benutzter Speicherplatz der Root-Partition Diese Systemvariable gibt die Größe des benutzten Speicherplatzes der Root-Partition in MByte an.

LREAL



_UsedSwapMemory Aktuell benutzter Swap-Speicher Diese Systemvariable gibt die Größe des benutzten Swap-Speichers in MByte an. (Swap=Auslagerungsspeicher auf der Festplatte). Das Speichermanagement eines Linux-Systems wird den zur Verfügung stehenden RAM-Speicher (zumindest nach einiger Laufzeit) immer nahezu komplett ausnutzen. Einen nicht zu vernachlässigender Teil des Speichers benutzt das Betriebssystem intern als Buffer bzw. Cache-Bereich. Sollte wegen der Anzahl oder der Größe der Programme der Speicherplatz im RAM nicht ausreichen, lagert das Betriebssystem unbenutzte Speicherseiten in den Swap-Bereich aus, d.h. sie werden auf Festplatte ausgelagert.

LREAL

_UsedChronoLogDiskSpace Größe der ChronoLog-Daten [MB] im Verzeichnis /home/aprolsys/APROL_DATA/chronolog

LREAL

_UsedChronoPlex ForwardingBuffer

Größe des ChronoPlex Weiterleitungs-Puffers [MB] im Verzeichnis /home/aprolsys/APROL_DATA/chronolog /replication

LREAL

_UsedVncRecorderSpace Größe der Daten [MB] des VncRecorders im Verzeichnis /home/aprolsys/vnc2swf

LREAL

Anhand der nachfolgenden Optionen können Warnungen des SysInfo-Prozesses bezüglich zu geringer IdleTime oder zu geringem freien Speicher parametriert werden.

Option Wertebereich Defaultwert -warningDelay <sec> [2 ... 200] 10 [s] -warningIdleState <%> [0 ...100] 10 [s] -warningMemoryState <%> [0 ...100] 10 [s] Wird der Parameter -warningIdleState bzw. der Parameter-warningMemoryState für mindestens "warningDelay" Sekunden unterschritten, werden folgende Systemvariablen durch den SysInfo-Prozess mit den entsprechenden Werten versorgt: _IdleStateWarning Parametriertes Level ist unterschritten _IdleStateViolationTime Dauer der Unterschreitung _FreeMemoryWarning Parametriertes Level ist unterschritten _FreeMemoryViolationTime Dauer der Unterschreitung

1.8.4 Systemvariablen für die CPU des PC Diese Systemvariablen geben Aufschluss über die Rechnerauslastung. Sie wird zum größten Teil über die CPU-Auslastung bestimmt.


Die Systemvariablen haben folgenden Präfix: <Instanz des Rechners>_<M | S >


_IdleStatePercent Freie CPU-Kapazität (Rechnerleistung) in Prozent. REAL _IdleStateViolationTime Verletzung freie CPU-Kapazität [s].

Beachten Sie bitte das vorangegangene Kapitel zur Parametrierung.

DINT

_IdleStateWarning Warnung bei geringer CPU-Kapazität. Beachten Sie bitte das vorangegangene Kapitel zur Parametrierung.

BOOL

_SystemStatePercent SYSTEM-Anteil der CPU-Auslastung in Prozent. REAL _UserStatePercent USER-Anteil der CPU-Auslastung in Prozent. Meistens

handelt es sich hier um das Runtime-System als Linux-User.

REAL

1.8.5 Systemvariablen für Prozesse im Betriebsystem Neben der CPU-Belastung ist es oftmals sinnvoll die Anzahl der laufenden Prozesse im Rechner zu überwachen. Die unten aufgeführten Systemvariablen stehen hierfür zur Verfügung. Die Systemvariablen haben folgenden Präfix: <Instanz-Bezeichnung des Rechners>_<M | S > Variable Erläuterung Typ

_ProcessCount Anzahl laufender Prozesse. Diese Systemvariable gibt die Anzahl der laufenden Prozesse an. Zu beachten ist dabei, dass Threads als einzelne Prozesse gezählt werden!

INT

_LoadAverage_1 1 minütiger Mittelwert der Systemauslastung. Als Maß für die Systemauslastung dient die Anzahl der Prozesse, die auf die Verarbeitung in der CPU warten oder gerade verarbeitet werden. Ein Wert kleiner oder gleich der Anzahl der CPUs ist ideal. Ein (viel) größerer Wert, insbesondere über einen längeren Zeitraum, lässt auf einen (sehr) stark belasteten Rechner vermuten. Die Ursachen muss nicht zwingend in der CPU-Auslastung liegen! Auch Festplatten-I/Os, o.a., können die Ursache sein.

REAL




REAL


REAL

1.8.6 Systemvariablen für Zeiten im Prozessleitsystem Diese Systemvariablen geben Aufschluss über die Zeiten und Merker im Betriebssystem. Die Systemvariablen haben folgenden Präfix: <Instanz-Bezeichnung des Rechners>_<M | S >


_DayLightSaving Flag für Sommer-/Winterzeitumstellung Diese Systemvariable gibt an, ob die Sommerzeit aktiv ist. Der Wert ist 1 für Sommerzeit aktiv, ansonsten 0

INT

_TimeDiffUTC2Timezone Zeitdifferenz zwischen UTC und der Zeitzone Diese Systemvariable gibt die Zeitdifferenz zwischen UTC (Universal Time Coordinated) und der lokalen Zeitzone in Sekunden an. Dieser Wert ist für Zeitzonen östlich des 0. Längengrades positiv, für Zeitzonen westlich negativ.

DINT

_TimeStamp Aktuelle Zeit in Sekunden seit 1970 DT _TimeString Aktuelle Zeit im Text-Format STRING _TimeZoneString Aktuelle Zeitzone im Text-Format STRING _Uptime Zeit seit der das System läuft

Diese Systemvariable gibt die Uptime des Rechners an, d.h. die Zeit, die der Rechner läuft.

DINT



1.8.7 Systemvariablen für die Lizenzierung Mit diesen Systemvariablen kann der Zustand der Lizenzierung überwacht werden. Es ist sinnvoll die Systemvariable "_LicenseState" in das Melde- und Alarmsystem zu übernehmen. Die Systemvariablen haben folgenden Präfix: <Instanz-Bezeichnung des Rechners>_<M | S > Variable Erläuterung Typ

_LicenseEvalTime Diese Systemvariable gibt die verbleibende Zeit im Evaluierungs-Modus an. Der Wert wird in [sec] angegeben.

DINT

_LicenseState Diese Systemvariable gibt den Lizenz-Status an. -1 = Unbekannter Lizenz-Fehler 0 = Unbekannter Status 1 = Evaluierungs-Modus aktiv 2 = Evaluierungs-Zeit abgelaufen 3 = Lizenz aktiviert 4 = Lizenz abgelaufen

INT

1.8.8 Systemdienst 'ApcHwInfo'

Der APROL Systemdienst 'ApcHwInfo' stellt Systemvariablen mit APC-Daten (z. B. Temperatur, Betriebsstunden) für die System- und Eigenüberwachung von B&R APCs / PPCs zur Verfügung. Folgende Hardware wird z. Zt. unterstützt:

PPC800

APC810

APC910

Detailinformationen zu den Modulen (CPU-Board, Buseinheit, Speichermodul oder Lüfterkit) entnehmen Sie der APC810 / PPC800 Implementierungsanleitung bzw. der APC910 Implementierungsanleitung.

1.8.8.1 Konfiguration des ApcHwInfo Der Systemdienst 'ApcHwInfo' wird im Projektierungsteil 'APROL-System', Sektion 'System Dienste' konfiguriert.

Eine Beschreibung der Aufrufoptionen des 'ApcHwInfo' finden Sie im Handbuch 'X99 CC-Module', Kapitel Aufrufoptionen ApcHwInfo.

Läuft der 'ApcHwInfo' auf einer unterstützten Plattform, so legt er einen Satz von Systemvariablen an, welche je nach Informationstyp (z. B. Panel, Temperatur, Lüfter) einmalig bzw. zyklisch aktualisiert werden.


Wird die Option '-enableSuccessMessages' verwendet, werden zusätzlich zu Fehlermeldungen auch allgemeine Zustandsinformationen in die zugehörigen Text-Variablen geschrieben.

Abbildung 14: Konfiguration des 'ApcHwInfo'

Die vom Systemdienst zur Verfügung gestellten Systemvariablen können z.B. im CFC-Chart an der CFC-Eingangsleiste oder als borderlose I/Os plaziert werden.


Abbildung 15:Abgreifen der Systemvariablen im CFC

1.8.8.2 Modul-unabhängige Variablen Variable Erläuterung <Rechnername>_ApcErrorText Variable vom Iosys-Typ 'STRING', in die Fehler, sowie bei

gesetzter Option -showSuccessMessages, auch Status-Meldungen geschrieben werden.

<Rechnername>_ApcHwType Hardware, auf der der ApcHwInfo aktuell läuft. Es werden nur bestimmte Plattformen (PPC800, APC810, APC910) unterstützt.

<Rechnername>_ApcHwId ID der vorgefundenen Hardware <Rechnername>_ApcHwVersion Version der vorgefundenen Hardware <Rechnername>_ApcMtcxVersion Firmware-Version des vorgefundenen MTCX-Chipsatzes <Rechnername>_ApcBatteryState Status der Pufferbatterie (numerisch) <Rechnername>_ApcBatteryStateText Status der Pufferbatterie (alphanumerisch) z. B. good, bad,

unknown, unsupported value

Hinweis: Damit alle Variablen mit korrekten Werten beschrieben werden, muss stets die aktuelle Firmware-Version des MTCX-Chipsatzes vorhanden sein. Ggf. ist ein Firmware-Update mit einem geeigneten Betriebssystem notwendig.


Für das Erkennen einer UPS an einem APC910 ist mindestens die Firmware-Version 0.08 erforderlich. Temperaturwerte, die aktuell nicht vom System ermittelt werden können, werden mit dem Wert 'NULL' belegt. Durch zukünftige Firmware-Updates werden diese Werte ggf. gefüllt. Einige Variablen sind hardware-abhängig (PowerTemp und PowerBoardTemp sind auf einem APC910 nicht verfügbar). Variablen, die auf einem System nicht verfügbar sind, werden nach dem Anlegen auf ungültig gesetzt. Variablen, die aufgrund nicht gesteckter, optionaler Hardware nicht ermittelt werden können, tragen den Wert 'NULL' oder einen Leerstring, sind jedoch grundsätzlich gültig. Die Prozessvariablen ab Kapitel Variablen für die Systemeinheit werden nur dann angelegt, wenn der ApcHwInfo unterstützte Hardware vorfindet (s.o.).

1.8.8.3 Variablen für die Module Variable Erläuterung <Rechnername>_Apc<Module ID>DeviceId Gerätekennung des Moduls <Rechnername>_Apc<Module ID>CompatId Kompatibilitätskennung des Moduls <Rechnername>_Apc<Module ID>VendorId Herstellerkennung des Moduls <Rechnername>_Apc<Module ID>HwRevision Hardware-Revision des Moduls <Rechnername>_Apc<Module ID>SerialNo Seriennummer des Moduls <Rechnername>_Apc<Module ID>ModelNo Modellnummer des Moduls <Rechnername>_Apc<Module ID>ParentDeviceId Gerätekennung der Ursprungsbaureihe des

Moduls <Rechnername>_Apc<Module ID>ParentCompatId Kompatibilitätskennung der Ursprungsbaureihe

des Moduls <Rechnername>_Apc<Module ID>Temp1 Temperatur1 des Moduls <Rechnername>_Apc<Module ID>Temp2 Temperatur2 des Moduls <Rechnername>_Apc<Module ID>Temp3 Temperatur3 des Moduls <Rechnername>_Apc<Module ID>Temp4 Temperatur4 des Moduls <Rechnername>_Apc<Module ID>PowerOnCycles Einschaltzyklen des Moduls <Rechnername>_Apc<Module ID>PowerOnHours Betriebsstunden des Moduls <Module ID> steht für: Cpu CPU-Modul Fan Lüfter-Kit SlideIn1 Einschubmodul1 SlideIn2 Einschubmodul2 IF1 Schnittstellenmodul1 IF2 Schnittstellenmodul2 DRAM1 Speichermodul1 DRAM2 Speichermodul2 BusUnit Buseinheit SystemUnit Zustände des APC910-BaseBoards DisplayLink DisplayLink Panel<Nr.> Panel 0 - 15 Ups Unterbrechungsfreie Stromversorgung Unit

1.8.8.4 Variablen für das CPU-Modul Variable Erläuterung <Rechnername>_ApcCpuDeviceId Gerätekennung des CPU-Moduls <Rechnername>_ApcCpuCompatId Kompatibilitätskennung des CPU-Moduls <Rechnername>_ApcCpuVendorId Herstellerkennung des CPU-Moduls <Rechnername>_ApcCpuHwRevision Hardware-Revision des CPU-Moduls <Rechnername>_ApcCpuSerialNo Seriennummer des CPU-Moduls <Rechnername>_ApcCpuModelNo Modellnummer des CPU-Moduls <Rechnername>_ApcCpuParentDeviceId Gerätekennung der Ursprungsbaureihe des CPU-Moduls <Rechnername>_ApcCpuParentCompatId Kompatibilitätskennung der Ursprungsbaureihe des CPU-


Moduls <Rechnername>_ApcCpuTemp1 Temperatur1 des CPU-Moduls <Rechnername>_ApcCpuTemp2 Temperatur2 des CPU-Moduls <Rechnername>_ApcCpuTemp3 Temperatur3 des CPU-Moduls <Rechnername>_ApcCpuTemp4 Temperatur4 des CPU-Moduls

1.8.8.5 Variablen für das Lüfter-Kit (optional) Variable Erläuterung <Rechnername>_ApcFanDeviceId Gerätekennung des Lüfter-Kits <Rechnername>_ApcFanCompatId Kompatibilitätskennung des Lüfter-Kits <Rechnername>_ApcFanVendorId Herstellerkennung des Lüfter-Kits <Rechnername>_ApcFanHwRevision Hardware-Revision des Lüfter-Kits <Rechnername>_ApcFanSerialNo Seriennummer des Lüfter-Kits <Rechnername>_ApcFanModelNo Modellnummer des Lüfter-Kits <Rechnername>_ApcFanParentDeviceId Gerätekennung der Ursprungsbaureihe des Lüfter-Kits <Rechnername>_ApcFanParentCompatId Kompatibilitätskennung der Ursprungsbaureihe des Lüfter-

Kits <Rechnername>_ApcFanSpeed1 Geschwindigkeit1 des Lüfter-Kits <Rechnername>_ApcFanSpeed2 Geschwindigkeit2 des Lüfter-Kits <Rechnername>_ApcFanSpeed3 Geschwindigkeit3 des Lüfter-Kits <Rechnername>_ApcFanSpeed4 Geschwindigkeit4 des Lüfter-Kits <Rechnername>_ApcFanPowerOnCycles Einschaltzyklen des Lüfter-Kits <Rechnername>_ApcFanPowerOnHours Betriebsstunden des Lüfter-Kits

1.8.8.6 Variablen für das Einschubmodul1 (optional) Variable Erläuterung <Rechnername>_ApcSlideIn1DeviceId Gerätekennung des Einschubmoduls1 <Rechnername>_ApcSlideIn1CompatId Kompatibilitätskennung des Einschubmoduls1 <Rechnername>_ApcSlideIn1VendorId Herstellerkennung des Einschubmoduls1 <Rechnername>_ApcSlideIn1HwRevision Hardware-Revision des Einschubmoduls1 <Rechnername>_ApcSlideIn1SerialNo Seriennummer des Einschubmoduls1 <Rechnername>_ApcSlideIn1ModelNo Modellnummer des Einschubmoduls1 <Rechnername>_ApcSlideIn1ParentDeviceId Gerätekennung der Ursprungsbaureihe des

Einschubmoduls1 <Rechnername>_ApcSlideIn1ParentCompatId Kompatibilitätskennung der Ursprungsbaureihe des

Einschubmoduls1 <Rechnername>_ApcSlideIn1Temp Temperatur des Einschubmoduls1

1.8.8.7 Variablen für das Einschubmodul2 (optional) Variable Erläuterung <Rechnername>_ApcSlideIn2DeviceId Gerätekennung des Einschubmoduls2 <Rechnername>_ApcSlideIn2CompatId Kompatibilitätskennung des Einschubmoduls2 <Rechnername>_ApcSlideIn2VendorId Herstellerkennung des Einschubmoduls2 <Rechnername>_ApcSlideIn2HwRevision Hardware-Revision des Einschubmoduls2 <Rechnername>_ApcSlideIn2SerialNo Seriennummer des Einschubmoduls2 <Rechnername>_ApcSlideIn2ModelNo Modellnummer des Einschubmoduls2 <Rechnername>_ApcSlideIn2ParentDeviceId Gerätekennung der Ursprungsbaureihe des

Einschubmoduls2 <Rechnername>_ApcSlideIn2ParentCompatId Kompatibilitätskennung der Ursprungsbaureihe des

Einschubmoduls2 <Rechnername>_ApcSlideIn2Temp Temperatur des Einschubmoduls2

1.8.8.8 Variablen der Schnittstellenmodule (optional) Variable Erläuterung


<Rechnername>_ApcIF1DeviceId Gerätekennung des Schnittstellenmoduls1 <Rechnername>_ApcIF1CompatId Kompatibilitätskennung des Schnittstellenmoduls1 <Rechnername>_ApcIF1VendorId Herstellerkennung des Schnittstellenmoduls1 <Rechnername>_ApcIF1HwRevision Hardware-Revision des Schnittstellenmoduls1 <Rechnername>_ApcIF1SerialNo Seriennummer des Schnittstellenmoduls1 <Rechnername>_ApcIF1ModelNo Modelnummer des Schnittstellenmoduls1 <Rechnername>_ApcIF1ParentDeviceId Gerätekennung der Ursprungsbaureihe des

Schnittstellenmoduls1 <Rechnername>_ApcIF1ParentCompatId Kompatibilitätskennung der Ursprungsbaureihe des

Schnittstellenmoduls1 <Rechnername>_ApcIF1Temp Temperatur des Schnittstellenmoduls1 <Rechnername>_ApcIF1PowerOnCycles Einschaltzyklen des Schnittstellenmoduls1 <Rechnername>_ApcIF1PowerOnHours Betriebsstunden des Schnittstellenmoduls1

Variable Erläuterung <Rechnername>_ApcIF2DeviceId Gerätekennung des Schnittstellenmoduls2 <Rechnername>_ApcIF2CompatId Kompatibilitätskennung des Schnittstellenmoduls2 <Rechnername>_ApcIF2VendorId Herstellerkennung des Schnittstellenmoduls2 <Rechnername>_ApcIF2HwRevision Hardware-Revision des Schnittstellenmoduls2 <Rechnername>_ApcIF2SerialNo Seriennummer des Schnittstellenmoduls2 <Rechnername>_ApcIF2ModelNo Modellnummer des Schnittstellenmoduls2 <Rechnername>_ApcIF2ParentDeviceId Gerätekennung der Ursprungsbaureihe des

Schnittstellenmoduls2 <Rechnername>_ApcIF2ParentCompatId Kompatibilitätskennung der Ursprungsbaureihe des

Schnittstellenmoduls2 <Rechnername>_ApcIF2Temp Temperatur des Schnittstellenmoduls1 <Rechnername>_ApcIF2PowerOnCycles Einschaltzyklen des Schnittstellenmoduls1 <Rechnername>_ApcIF2PowerOnHours Betriebsstunden des Schnittstellenmoduls1

1.8.8.9 Variablen für die Speichermodule1 und 2 Variable Erläuterung <Rechnername>_ApcDRAM1DeviceId Gerätekennung des Speichermoduls1 <Rechnername>_ApcDRAM1CompatId Kompatibilitätskennung des Speichermoduls1 <Rechnername>_ApcDRAM1VendorId Herstellerkennung des Speichermoduls1 <Rechnername>_ApcDRAM1HwRevision Hardware-Revision des Speichermoduls1 <Rechnername>_ApcDRAM1SerialNo Seriennummer des Speichermoduls1 <Rechnername>_ApcDRAM1ModelNo Seriennummer des Speichermoduls1 <Rechnername>_ApcDRAM1ParentDeviceId Gerätekennung der Ursprungsbaureihe des

Speichermoduls1 <Rechnername>_ApcDRAM1ParentCompatId Kompatibilitätskennung der Ursprungsbaureihe des

Speichermoduls1

Das Speichermodul 2 ist optional. Variable Erläuterung <Rechnername>_ApcDRAM2DeviceId Gerätekennung des Speichermoduls2 <Rechnername>_ApcDRAM2CompatId Kompatibilitätskennung des Speichermoduls2 <Rechnername>_ApcDRAM2VendorId Herstellerkennung des Speichermoduls2 <Rechnername>_ApcDRAM2HwRevision Hardware-Revision des Speichermoduls2 <Rechnername>_ApcDRAM2SerialNo Seriennummer des Speichermoduls2 <Rechnername>_ApcDRAM2ModelNo Modellnummer des Speichermoduls2 <Rechnername>_ApcDRAM2ParentDeviceId Gerätekennung der Ursprungsbaureihe des

Speichermoduls2 <Rechnername>_ApcDRAM2ParentCompatId Kompatibilitätskennung der Ursprungsbaureihe des

Speichermoduls2

1.8.8.10 Variablen für die Buseinheit Variable Erläuterung <Rechnername>_ApcBusUnitDeviceId Gerätekennung der Buseinheit <Rechnername>_ApcBusUnitCompatId Kompatibilitätskennung der Buseinheit <Rechnername>_ApcBusUnitVendorId Herstellerkennung der Buseinheit


<Rechnername>_ApcBusUnitHwRevision Hardware-Revision der Buseinheit <Rechnername>_ApcBusUnitSerialNo Seriennummer der Buseinheit <Rechnername>_ApcBusUnitModelNo Modellnummer der Buseinheit <Rechnername>_ApcBusUnitParentDeviceId Gerätekennung der Ursprungsbaureihe der Buseinheit <Rechnername>_ApcBusUnitParentCompatId Kompatibilitätskennung der Ursprungsbaureihe der

Buseinheit <Rechnername>_ApcBusUnitPowerOnCycles Einschaltzyklen der Buseinheit <Rechnername>_ApcBusUnitPowerOnHours Betriebsstunden der Buseinheit

1.8.8.11 Variablen für die SystemUnit Variable Erläuterung <Rechnername>_ApcSystemUnitDeviceId Gerätekennung des Baseboards <Rechnername>_ApcSystemUnitCompatId Kompatibilitätskennung des Baseboards <Rechnername>_ApcSystemUnitVendorId Herstellerkennung des Baseboards <Rechnername>_ApcSystemUnitHwRevision Hardware-Revision des Baseboards <Rechnername>_ApcSystemUnitSerialNo Seriennummer des Baseboards <Rechnername>_ApcSystemUnitModelNo Modellnummer des Baseboards <Rechnername>_ApcSystemUnitParentDeviceId Gerätekennung der Ursprungsbaureihe des

Baseboards <Rechnername>_ApcSystemUnitParentCompatId Kompatibilitätskennung der Ursprungsbaureihe

des Baseboards <Rechnername>_ApcSystemUnitTemp1 Temperatur1 des Baseboards <Rechnername>_ApcSystemUnitTemp2 Temperatur2 des Baseboards <Rechnername>_ApcSystemUnitTemp3 Temperatur3 des Baseboards <Rechnername>_ApcSystemUnitTemp4 Temperatur4 des Baseboards <Rechnername>_ApcSystemUnitPowerOnCycles Einschaltzyklen Baseboards <Rechnername>_ApcSystemUnitPowerOnHours Betriebsstunden Baseboards

1.8.8.12 Variablen für das DisplayLink Variable Erläuterung <Rechnername>_ApcDisplayLinkDeviceId Gerätekennung des DisplayLink <Rechnername>_ApcDisplayLinkCompatId Kompatibilitätskennung des DisplayLink <Rechnername>_ApcDisplayLinkVendorId Herstellerkennung des DisplayLink <Rechnername>_ApcDisplayLinkHwRevision Hardware-Revision des DisplayLink <Rechnername>_ApcDisplayLinkSerialNo Seriennummer des DisplayLink <Rechnername>_ApcDisplayLinkModelNo Modellnummer des DisplayLink <Rechnername>_ApcDisplayLinkParentDeviceId Gerätekennung der Ursprungsbaureihe des

DisplayLink <Rechnername>_ApcDisplayLinkParentCompatId Kompatibilitätskennung der Ursprungsbaureihe

des DisplayLink <Rechnername>_ApcDisplayLinkPowerOnCycles Einschaltzyklen des DisplayLink <Rechnername>_ApcDisplayLinkPowerOnHours Betriebsstunden des DisplayLink <Rechnername>_ApcDisplayLinkTemp1 Temperatur1 des DisplayLink <Rechnername>_ApcDisplayLinkTemp2 Temperatur2 des DisplayLink <Rechnername>_ApcDisplayLinkTemp3 Temperatur3 des DisplayLink <Rechnername>_ApcDisplayLinkTemp4 Temperatur4 des DisplayLink

1.8.8.13 Variablen für das Panel 0 bis 15 Es werden je nach Hardware bis zu 16 Panels unterstützt, welche jeweils den gleichen Variablensatz unterstützen. Nachfolgend werden nur die Variablen für das erste Panel beschrieben. Die Variablennamen für die weiteren Panels sind entsprechend angepasst. Variable Erläuterung <Rechnername>_ApcPanel0Found Panel0 gefunden <Rechnername>_ApcPanel0DeviceId Gerätekennung des Panel0 <Rechnername>_ApcPanel0CompatId Kompatibilitätskennung des Panel0 <Rechnername>_ApcPanel0VendorId Herstellerkennung des Panel0


<Rechnername>_ApcPanel0HwRevision Hardware-Revision des Panel0 <Rechnername>_ApcPanel0SerialNo Seriennummer des Panel0 <Rechnername>_ApcPanel0ModelNo Modellnummer des Panel0 <Rechnername>_ApcPanel0Linked Panel0 angeschlossen <Rechnername>_ApcPanel0Locked Panel0 gesperrt <Rechnername>_ApcPanel0ScanCodesLocked Scancodes gesperrt <Rechnername>_ApcPanel0Temp Temperatur des Panel0 <Rechnername>_ApcPanel0Speed Geschwindigkeit des Panel-Lüfters <Rechnername>_ApcPanel0BacklightOnCycles Einschaltzyklen des Panel0 <Rechnername>_ApcPanel0BacklightOnHours Betriebsstunden des Panel0

1.8.8.14 Variablen des PPC800-/APC810-Netzteils Variable Erläuterung <Rechnername>_ApcPowerTemp Temperatur des Netzteils <Rechnername>_ApcPowerBoardTemp Temperatur der Netzteil-Platine

1.8.8.15 Variablen für die Unterbrechungsfreie Stromversorgung (optional)

Variable Erläuterung <Rechnername>_ApcUpsDeviceId Gerätekennung der UPS <Rechnername>_ApcUpsCompatId Kompatibilitätskennung der UPS <Rechnername>_ApcUpsVendorId Herstellerkennung der UPS <Rechnername>_ApcUpsHwRevision Hardware-Revision der UPS <Rechnername>_ApcUpsSerialNo Seriennummer der UPS <Rechnername>_ApcUpsModelNo Modelnummer der UPS <Rechnername>_ApcUpsDetected UPS erkannt <Rechnername>_ApcUpsLinked UPS angeschlossen <Rechnername>_ApcUpsTemp Temperatur der UPS <Rechnername>_ApcUpsBatCurrent UPS-Batteriestrom lesen <Rechnername>_ApcUpsBatVoltage UPS-Batteriespannung lesen <Rechnername>_ApcUpsStatusFlags UPS-Statusflags lesen

1.8.8.16 Besonderheiten für den PPC800 / APC810 Für den PPC800 / APC810 sind nachfolgende Variablen auf andere Bereiche gemappt: Board -> SystemUnit BoardIo -> BusUnit EthBoard -> IF Option 1 EthController -> IF Option 2

1.9 InaConnect Mit dem Programm InaConnect können Sie mit einem Controller Verbindung aufnehmen, Module auf den Controller laden, den Controller initialisieren usw. ohne dass ein Runtime-System gestartet wurde. Wenn in Ihrem Runtime-System oder Engineering-System eines der Pakete InaDriver installiert ist, ist dieses Programm vorhanden. Das Programm lässt sich auf zweierlei Arten benutzen:

Als Kommandoshell (ideal für Diagnose und Fehleranalyse)

Direkte Ausführung von Kommandos (ideal für die Verwendung in Skripten oder wie oben beschrieben Laden von Modulen auf den Controller)


Welche Möglichkeiten das Programm bietet, zeigt die folgenden Abbildung mit den Aufrufparametern.

Abbildung 16: Optionen von InaConnect nach dem Aufruf mit –help

1.9.1 InaConnect in der Kommandoshell Aus den Optionen von InaConnect ist ersichtlich, dass die Verbindung zu einem Controller in drei Arten erfolgen kann, über Profibus, Ethernet, und seriell. Wie die Verbindungen über die verschiedene Medien aufgebaut wird, ist in den nachfolgenden Kapiteln beschrieben. An dieser Stelle wird erläutert, welche Funktionen ausgeführt werden können, wenn die Verbindung hergestellt ist. Wie sie die Verbindung über die einzelnen Medien aufnehmen können, lesen Sie bitte in den Kapitel, die in der folgenden Tabelle aufgelistet sind, nach.

Verbindung über Profibus

Verbindung über Ethernet

Serielle Verbindung

Um sicher zu gehen, dass eine Verbindung zu einem Controller besteht (d .h. dass keine falschen Verbindungsparameter eingegeben wurden), sollten Sie nach dem Verbindungsaufbau den Befehl "v 3 = debuglevel 3" eingeben und danach über "s" den Status abfragen.

Für alle Verbindungen kann folgende Option bzw. Kommando gesetzt werden: Option Option-

eingabe Beschreibung der Optionseingabe

-setRT VAL Timeout für das Antworttelegramm. Ohne Angabe 165ms


Folgende Aktionen bzw. Kommandos können nun durchgeführt bzw. abgesetzt werden: Aktion / Befehl

kurz Beschreibung

connect c Aufbau der Verbindung zum Controller an Hand der bei dem Aufruf eingegebenen Verbindungsparameter. Muss vor allen anderen Aktionen erfolgen.

disconnect d Abbau der Verbindung status s Anzeige des aktuellen Status der Verbindung.

CONN_establish_connection = wird aufgebaut CONN_stable_connection = ist aufgebaut CONN_lost_connection = verloren CONN_disconnecting = wird abgebaut CONN_disconnected = ist abgebaut

options o Optionen für einen weiteren Verbindungsaufbau: 1 = Ethernet, 2 = Profibus, 3 = seriell

put p Laden eines Files (Datei) auf den Controller. Mit einem Leerzeichen getrennt wird nach dem p das File mit Pfad angegeben. Danach kommt wieder durch ein Leerzeichen getrennt der Modus. 2 = laden in User-RAM (default, wenn kein Mode angegeben), 3 = laden in User-Flash (wird gebrannt).

get g Laden eines Files vom Controller. Es muss das Modul und der Name des Files angegeben werden. Das File befindet sich dann in dem Verzeichnis aus dem InaConnect gestartet wurde.

reset r Auf dem angewählten Controller wird ein Reset durchgeführt. Nach dem r folgt der Mode: TOTAL, DIAGNOSE oder NORMAL

logbook l Auslesen des Fehler-Logbuches. Es muss noch die Angabe der Einträge folgen (maximal 39):

info i Lesen der CPU-Informationen (SW-Version, Typ usw.). meminfo m Lesen der Informationen über den Speicher. listmodule lm Auflisten der Module. lm * listet alle in der CPU vorhandenen Module

auf. lm <Name des Moduls> zeigt Informationen über das Modul.

delmodule dm Löscht das angegebene Modul auf dem Controller. pvlist pl Listet die globalen PV `s des Controllers auf. pl * alle PV`s. Durch die

Angabe des Start-Index und des Bereichs lässt sich die Suche verkürzen, Der PV-Startindex einer Task lässt sich mit dem Kommando lm <Task> ermitteln.

forcelist fl Listet die PV`s für das Forcen auf. Es wird auch die Taskklasse ausgegeben.

forceon fn Forcen einer PV unter Angabe ihrer Adresse und Taskklasse auf einen Ganzzahlwert.

forceoff ff Setzt das Forcen einer PV (Adresse Taskklasse) zurück oder mit ALL alle zurück.

gettime gt Gibt das Datum und die Uhrzeit der CPU und des Rechners aus.


Aktion / Befehl

kurz Beschreibung

settime st Übernimmt die Uhrzeit und das Datum des Rechners auf dem Controller.

clearmem cm Löscht den Inhalt der Speicherbereiche (Vorsicht alle Daten werden gelöscht). Der Controller muss sich dabei im Diagnosemode befinden (r DIAGNOSE). Der Befehl ist nur über serielle Verbindung ausführbar. Nach erfolgtem Löschen ist mit einem Total-Init (r TOTAL) auf dem Controller ein Reset auszuführen.

tkinfo tki Liefert den Status der einzelnen Taskklassen des verbundenen Controllers mit Name, Nummer und dem Zustand (STOP, RUNNING, IDLE).

tkresume tkr Startet eine Taskklasse, d.h. wenn eine Taskklasse mit tks <TK> gestoppt wurde, so wird sie mit tkr <TK> wieder gestartet. Das bedeutet, alle Tasks dieser Taskklasse laufen wieder an.

tksuspend tks Stoppt die Taskklasse TK. Alle Tasks diese Taskklasse werden gestoppt und können mit tkr <TK> wieder gestartet werden.

taskresume tr Startet eine bestimmte Task, die gestoppt ist. Der Taskname muss angegeben werden.

tasksuspend ts Stoppt eine bestimme Task, die sich auf der CPU befindet und gestartet ist. Der Name muss angegeben werden.

quit q Baut die Verbindung ab und beendet das Programm. verbose v Setzt die Debug-Level (1:Error ; 2:Transactionen ; 4: Daten) trace t Zeigt die Debug-Level an. ? ? Anzeigen dieser Liste in Kurzform.

1.9.1.1 Verbindung über Profibus Nach dem Programmnamen (InaConnect) folgt die Aufrufoption für die Verbindung. Option Option-


-medium Profibus Die Profibusverbindung wird gewählt. -softing Im Rechner ist ein Softingboard eingebaut. Default (ohne Angabe) ist

die Profibuskarte von B&R eingebaut. -pbAddr ADDR Angabe der Stationsadresse des Controllers. -pbBoard NR Nummer der Profibuskarte im Rechner (0-2). Ohne Angabe wird 0

genommen. -pbLsap LSAP Optional kann bei der Profibuskarte statt der Stationsadresse auch

ein spezieller LSAP verwendet werden. Beispiel: InaConnect –medium Profibus –pbAddr ADDR –pbBoard NR


1.9.1.2 Verbindung über Ethernet Nach dem Programmnamen (InaConnect) folgt die Aufrufoption für die Verbindung. Für einen ordnungsgemäßen Verbindungsaufbau muss der Controller entsprechend konfiguriert sein. Option Option-


-medium Ethernet Das Ethernet mit TCP/IP wird gewählt. -socket NR Port für die Kommunikation auf der Partnerstation (Controller) im

HEX-Format. Wird kein Port angegeben wird 0x2b97 genommen. -ip ADDR Die IP-Adresse des Controllers. -node NODE Knotennummer des Controllers. Dann entfällt die Angabe der IP-

Adresse. Der Controller meldet sich und gibt dabei die IP-Adresse zurück.

-mynode NODE Angabe der eigenen Knotennummer. -bcast BCAST Broadcastadresse, wenn mit Knotennummern gearbeitet wird und

die Broadcastadresse nicht 255.255.255.255 ist. Beispiel 1: InaConnect –medium Ethernet –ip ADDR

Beispiel 2: InaConnect –medium Ethernet –node NODE –mynode NODE

Läuft beispielsweise schon der InaDiver, so ist die Aufrufoption InaConnect –medium Ethernet –mynode NODE zu benutzen.

1.9.1.3 Serielle Verbindung Nach dem Programmnamen (InaConnect) folgt die Aufrufoption für die Verbindung. Für einen ordnungsgemäßen Verbindungsaufbau muss der Controller entsprechend konfiguriert sein. Option Option-


-medium serialPort Die serielle Verbindung wird gewählt. -comport COM Angabe des Ports (ttyS0 bis ttyS3, abhängig von der

Rechnerausstattung in der Art COM1 bis COM4 (DOS/Windows) ). Die restlichen Parameter sind wie folgt eingestellt: Baudrate = 57600, Parität = EVEN, Timeout=14ms

-route ROUTE Information für das Routing. Beispiel: InaConnect –medium serialPort –comport COM

Wenn der Controller, mit der Sie Verbindung aufnehmen wollen, andere Parameter hat, als unter –comport angegeben, dann stellen Sie diese bitte in der Kommandoshell ein. Befehl = o 3.


Nach dem Befehl "o 3" in der Kommandoshell können Sie folgende Parameter für die serielle Verbindung zusätzlich ändern und speichern, wenn der Controller anders konfiguriert sein sollte: Parameter Nummer Beschreibung

comBD 4 Angabe einer anderen Baudrate. Die folgenden Werte sind möglich: 110, 300, 600, 1200, 2400, 3600, 4800, 9600, 19200, 38400 ,57600 ,115200.

comPa 5 Parität (0 =NO, 1=ODD , 2=EVEN) comIT 6 Timeout (0 bis 60000ms)

1.9.1.4 InaConnect für Routing Über InaConnect können sie, wenn die entsprechenden Controller "netzwerkmäßig" verbunden sind, zu jedem Controller routen bzw. jedes angeschlossene Gerät erreichen und Daten anfordern bzw. senden. Mit folgender Eingabe nehmen Sie Verbindung zum ersten Gerät auf und routen dann weiter bis zu dem Punkt, den Sie erreichen wollen. Beispiel mit Ethernet und TCP/IP InaConnect -medium Ethernet -ip <IP-Adresse> -node <Knotennr.>

An diese Zeile wird über die Option -route die Route angehängt. Alle Möglichkeiten an dieser Stelle anzugeben, würde den Rahmen sprengen. Aus diesem Grund wird nur eine Beispiel angegeben. Folgende Gerätekonfiguration liegt vor und auf dem CAN-Bus soll das Gerät an der Stelle 5 angesprochen werden.

Abbildung 17: Routing mit InaConnect

Direkte Verbindung mit dem Controller (IP-Adresse 192.168.23.4) aufnehmen: InaConnect -medium Ethernet -ip 192.168.2.34 -node 3

Das Routing zum Gerät 5 erfolgt mit weiteren Optionen: -route CP/SL0/SS0/IF1/SL0/SS1/IF1.5

Routingparameter Beschreibung

CP/ Die CPU wird angesprochen.


Routingparameter Beschreibung

SL0/SS0/IF1/ Über Slot 0 Subslot 0 wird die serielle Schnittstelle IF1 angesprochen.

Da die Kopplung zur zweite CPU (SS0/IF1) seriell erfolgt, wird diese nicht angegeben.

SL0/SS1/IF1.5 Aus der zweite CPU heraus erfolgt das weitere Routing über Slot 0 und Subslot 1 zu IF1 (Interface CAN-Bus)) und dort das Gerät 5.

1.9.2 InaConnect als Kommando (Aufruf) Wie schon am Anfang des Kapitels zu InaConnect beschrieben, können Sie auch einen großen Teil des Befehlsumfanges in einer Kommandozeile benutzen und somit ein Skript schreiben oder einzelne Befehle an den Controller senden. In diesem Kapitel wird nicht mehr auf das Medium (-medium) und die dafür restlichen Parameter eingegangen. Diese Angaben entnehmen Sie bitte folgenden Kapiteln:

Verbindung über Profibus

Verbindung über Ethernet

Serielle Verbindung

Die folgende Tabelle beschreibt die Möglichkeiten und die entsprechenden Parameter: Option Angabe

Beschreibung

-download FILE Angabe des auf den Controller zu ladenden Files mit Pfadangabe. -burn Das File wird auf den Controller "gebrannt" -upload -file

Modul FILE

Diese Optionen gehören zusammen. Das Modul, welches von dem Controller geladen werden soll und FILE=Name mit Pfadangabe, wie das Modul auf dem Rechner gespeichert werden soll.

-reset MODE Auf dem angewählten Controller wird ein Reset durchgeführt. Für MODE können folgende Angaben gemacht werden: TOTAL, DIAGNOSE oder NORMAL

-logbook NUM Auslesen des Fehler-Logbuches. NUM = Angabe über die Anzahl der Einträge (maximal 39).

-cpuinfo Lesen der CPU-Informationen (SW-Version, Typ usw.). -meminfo Lesen der Informationen über den Speicher. -dom_info MODUL Holt Informationen über das Modul (MODUL). -delete MODUL Löscht das angegebene Modul auf dem Controller. -gettime Gibt sowohl das Datum und die Uhrzeit der CPU als auch des

Rechners aus.


Option Angabe

Beschreibung

-settime Übernimmt die Uhrzeit und das Datum des Rechners auf dem Controller.

-d LEVEL Setzt die Debug-Level (1:Error ; 2:Transactionen ; 4: Daten)

Beschreibung zur UTF8StringAPI 2-1

2 Beschreibung zur UTF8StringAPI .

2.1 Motivation Bei der Verwendung des ASCII Zeichensatzes entspricht die Anzahl Bytes, genau der Anzahl an Zeichen in der Zeichenkette. Durch die Benutzung von Unicode und der damit verbundenen UTF8-Kodierung, kann sich jedoch ein Unterschied in der Anzahl Bytes und der Anzahl Zeichen einer Zeichenkette ergeben. Daraus resultierend, können bei Verwendung der Funktionen der Standard-C-Bibliothek zum Bearbeiten von Zeichenketten, Fehler entstehen.

2.2 Von ASCII zu UTF8 ASCII (American Standard Code for Information Interchange) ist ein 7-Bit Zeichencode, der 1967 als Standard veröffentlicht wurde. Jedem Zeichen entspricht ein Bitmuster aus 7 Bit. Es gibt 27 = 128 verschiedene Bitmuster, da jedes Bit zwei Werte annehmen kann. Diese Bitmuster können auch als ganze Zahlen 0–127 (hexadezimal 00–7F) interpretiert werden. Der ASCII-Code definiert neben 95 druckbaren Zeichen noch 33 nicht-druckbare Zeichen. Die 95 druckbaren Zeichen beinhalten alle Buchstaben des lateinischen Alphabets in Groß- und Kleinschreibung, die Ziffern 0 bis 9 sowie diverse Satzzeichen. Die 33 nicht-druckbaren Zeichen entsprachen Steuercodes für Peripheriegeräte (Drucker, Datenaustausch etc.). In den folgenden Jahren gab es verschiedene Versuche, die fehlenden Zeichen mit abzubilden. Es entstanden plattformabhängige 8-Bit Erweiterungen des ASCII (z.B. Codepage 437 = MS-DOS). Im neuen Standard ISO8859 wurden in 15 Varianten (ISO 8859-1 = Latin-1 Westeuropäisch, ISO8859-2 = Latin-2 Osteuropäisch, ... , ISO8859-15 = Latin-9 Westeuropäisch mit diversen im Latin-1 fehlenden französischen Sonderzeichen und dem Euro-Symbol) 8-Bit Zeichencodes für die unterschiedlichen Sprachregionen definiert. Unter Windows wird der auf der ISO 8859-1 aufbauende Windows-1252 Zeichencode verwendet. Um jedoch alle möglichen Buchstaben, Sonder- und Schriftzeichen der Menschheit in einem Zeichencode abzubilden, bedarf es weit mehr als 8 Bit. Der Zeichencode Unicode reserviert für jedes Zeichen 32 Bit. Um den Speicheraufwand zu minimieren und kompatibel mit ASCII und ISO8859 zu bleiben, wird für die Codierung der Unicode-Zeichen UTF8 verwendet. UTF-8 (8-bit Unicode Transformation Format) ist die am weitesten verbreitete Kodierung für Unicode-Zeichen. Dabei wird jedem Unicode-Zeichen eine speziell kodierte Byte-Kette von variabler Länge zugeordnet. UTF-8 unterstützt bis zu vier Byte, auf die sich wie bei allen UTF-Formaten alle 1.114.112 Unicode-Zeichen abbilden lassen.


Ein UTF-8-Zeichen besteht aus einem, zwei, drei oder vier Bytes. Alle Zeichen des Standard ASCII werden in einem Byte dargestellt, die meisten Zeichen der diversen ISO 8859 Kodierungen in zwei Byte, einige Zeichen der ISO 8859 Kodierungen (z.B. das Eurozeichen '€') in drei Byte, Schriftzeichen außereuropäischer Sprachen in maximal vier Bytes. Diese Byte-Folgen gehören zusammen und dürfen durch Operationen innerhalb eines Computer-Programms auf keinen Fall auseinander gerissen werden. Dieses kann bei Benutzung der Funktionen der Standard-C-Bibliothek der Sprache 'C' passieren! Die Funktionen der Standard-C-Bibliothek zum Bearbeiten von Zeichenketten (strlen, strcpy, strncpy, strcat, strncat, ...), gehen vom ASCII Zeichensatz aus. Sie interpretieren keine Zeichen und sind somit Byte-orientiert!

2.3 UTF8 Kodierung Der Unterschied zwischen "Zeichen-orientiert" und "Byte-orientiert" wird im Folgenden an Hand eines Beispiels erklärt [1]: Das Zeichen "A" besitzt sowohl im ASCII, ISO8859, etc. als auch im UTF-8 folgendes Bitmuster:

0 1 0 0 0 0 0 1

Es wird also 1 Byte für ein Zeichen benötigt. Verwendet man hier eine Funktion der Standard-C-Bibliothek um dieses Zeichen zu kopieren, läuft alles korrekt ab. Das Zeichen "Ü" hat im Speicher folgendes Bitmuster (Darstellung mit 8 Bit Grenze):

1 1 0 0 0 0 1 1 1 0 0 1 1 1 0 0

Start-Byte 1. Folge-Byte Das Euro-Zeichen "€" hat folgendes Bitmuster (Darstellung mit 8 Bit Grenzen):

1 1 1 0 0 0 1 0 1 0 0 0 0 0 1 0 1 0 1 0 1 1 0 0

Start-Byte 1. Folge-Byte 2. Folge-Byte Nachfolgend soll die Zeichenkette "A€Ü" betrachtet werden: char buf[32] = {0}; char *str = "A€Ü"; int len = strlen( str ); // liefert als Ergebnis 6, da 'str' UTF-8-kodiert 6 Byte lang ist! strncpy( buf, str, 3 ); // Kopiert 'A' und die ersten beiden Bytes des "€" nach "buf" // Das Ergebnis ist eine nicht legale UTF-8 Zeichenkette! strncpy( buf, &str[2], 3 ); // Kopiert das 1. und 2. Folgebyte des "€" und das Startbyte des "Ü" // nach "buf". Das Ergebnis ist eine nicht legale UTF-8 Zeichenkette! D.h. wenn eine Zeichenkette UTF-8-kodierte Mehr-Byte-Zeichen enthält, können die Funktionen der Standard-C-Bibliothek nicht ohne weiteres angewandt werden.


2.4 Funktionsbeschreibung zum Datentyp STRING B&R bietet Funktionen an zur sicheren Bearbeitung von Zeichenketten, die UTF8 Zeichen enthalten.

Das API dieser Funktionen wird hier beschrieben. Die Funktionen sind in der APROL-PccStd-Bibliothek implementiert und können somit durch Inkludieren des Headers "AprolStringUtf8.h" und Hinzulinken der Bibliothek "libPccStd" innerhalb von APROL überall verwendet werden.

Die in der Bibliothek "IEC61131_3" in der Gruppe "StringFunctions" enthaltenen Bausteine zur Bearbeitung von Zeichenketten, wurden um eine Version erweitert, die dieses API nutzt.

Die Funktionen können ohne weiteren Aufwand, d.h. ohne Einbindung des Headers "AprolStringUtf8.h", in jedem Funktionsbaustein verwendet werden.

Fehlerbehandlung: Die angebotenen API Funktionen besitzen als letzten Parameter einen Zeiger auf eine Variable vom Typ "int". Jeder API Funktion muss ein entsprechend initialisierter Zeiger übergeben werden, da sonst keine Bearbeitung stattfindet. Innerhalb jeder Funktionsbeschreibung findet sich ein Code-Beispiel aus dem ersichtlich ist, wie mit diesem Zeiger umzugehen ist. Abweichend von den Code-Beispielen muss bei Verwendung der API Funktionen immer auf den Errorcode geprüft werden, nicht auf den Wert. Folgende Fehlercodes werden von dem API übergeben:

Errorcode: Bedeutung:

UTF8_NOERRORFLAG error ist ein NULL-Zeiger

UTF8_NOERROR Kein Fehler.

UTF8_NULLSRC Ein NULL-Zeiger für src wurde übergeben.

UTF8_NULLSTR Ein NULL-Zeiger für ins / rep / toFind wurde übergeben.

UTF8_NULLDEST Ein NULL-Zeiger für dest wurde übergeben.

UTF8_START Der Wert für start wurde mit kleiner 1 übergeben.

UTF8_LEN Der Wert für len wurde mit kleiner gleich 0 übergeben.

UTF8_HIGHSTART Der Wert für start ist größer als die Anzahl Zeichen in src.

UTF8_HIGHLEN Der Wert für len ist größer als die Anzahl Zeichen in src.

UTF8_HIGHSTARTLEN Der Wert der Summe start + len ist größer als die Anzahl Zeichen in src.

UTF8_MAXSTARTLEN Der Wert der Summe start + len ist größer als die maximale Stringlänge.

UTF8_WIDTH Die Anzahl Bytes eines Zeichens konnte nicht ermittelt werden.

UTF8_STARTFOLLOW Der Wert für start liegt nicht angrenzend hinter der letzten Zeichenposition in src.


Es stehen die nachfolgenden Funktionen stehen zur Verfügung:

2.4.1 UTF8_getAPIVersion

Funktions-deklaration:

const char* UTF8_getAPIVersion(void );

Funktions-beschreibung:

Liefert die Versionsnummer der UTF8-String-API. Die Funktion gibt einen Zeiger auf einen statischen Versionsstring zurück, der maximal 7 Bytes groß ist, inklusive '\0'. Codefragment: #include <AprolStringUtf8.h> char Version[7] = {0}; strcpy(Version, UTF8_getAPIVersion()); printf("UTF8 String API Version: %s\n", Version);

Ausgabe: "UTF8 String API Version: V1.0"

Rückgabewert: Wert: Bedeutung:

Zeiger auf statischen Versionsstring.

Versionsstring der UTF8 API Funktionen. Entspricht die Version der API 1.0, dann liefert die Funktion den String: V1.0

2.4.2 UTF8_LengthInCharacters


int UTF8_LengthInCharacters( const char *src, int *error );


Diese Funktion liefert die Anzahl Zeichen in der übergebenen Zeichenkette, ohne abschließendes '\0'. Beispiel: Es soll die Anzahl Zeichen der Zeichenkette "Der Apfel fällt nicht weit vom Stamm!" ermittelt werden. Die Funktion liefert den Wert 37. Codefragment: #include <AprolStringUtf8.h> int error = 0: char *quelle = "Der Apfel fällt nicht weit vom Stamm!"; int len = UTF8_LengthInCharacters(quelle, &error); if(error) { /* Fehlerbehandlung ... */ }

Parameter: Name: Typ: Beschreibung:



int UTF8_LengthInCharacters( const char *src, int *error );

src const char*

IN Zeichenkette deren Anzahl Zeichen bestimmt werden

error int* OUT Der Errorcode der Funktion wird an diesen Parameter übergeben. ACHTUNG: Es handelt sich hierbei um einen Zeiger der auf eine Variable vom Typ 'int' zeigen muss!

Errorcodes: Wert: Bedeutung:


UTF8_NULLSRC src ist ein NULL-Zeiger.




>= 0 Die Anzahl Zeichen in der übergebenen Zeichenkette

2.4.3 UTF8_LengthInBytes

Funktionsdeklaration: int UTF8_LengthInBytes( const char *src, int *error );

Funktions-beschreibung: Diese Funktion liefert die Anzahl Bytes in der übergebenen Zeichenkette, ohne abschließendes '\0'. Beispiel: Es soll die Anzahl Bytes der Zeichenkette "Der Apfel fällt nicht weit vom Stamm!" ermittelt werden. Die Funktion liefert den Wert 38. Codefragment: #include <AprolStringUtf8.h> int error = 0: char *quelle = "Der Apfel fällt nicht weit vom Stamm!"; int bytes = UTF8_LengthInBytes(quelle, &error); if(error) { /* Fehlerbehandlung ... */ }


Funktionsdeklaration: int UTF8_LengthInBytes( const char *src, int *error );


src const char*

IN Zeichenkette deren Anzahl Zeichen

error int* OUT Der Errorcode der Funktion wird an diesen Parameter übergeben. Achtung: Es handelt sich hierbei um einen Zeiger der auf eine Variable vom Typ 'int' zeigen muss!




Rückgabe-wert: Wert: Bedeutung:


>= 0 Die Anzahl Bytes der übergebenen Zeichenkette.

2.4.4 UTF8_Copy

Funktions- deklaration:

char* UTF8_Copy( char *dest, size_t n, const char *src, int *error );


Diese Funktion kopiert eine Zeichenkette in ein übergebenes ByteArray. Kopiert die in src enthaltene Zeichenkette nach dest und liefert einen Zeiger auf dest zurück. Die Zeichenkette in dem Ziel-ByteArray wird immer mit '\0' abgeschlossen. Beispiel: Es soll die Zeichenkette "Der Apfel fällt nicht weit vom Stamm!" kopiert werden. Codefragment: #include <AprolStringUtf8.h> int error = 0; char *quelle = "Der Apfel fällt nicht weit vom Stamm!"; char ziel[65] = {0}; UTF8_Copy(ziel, 39, quelle, &error); if(error)




{ /* Fehlerbehandlung ... */ }

Überschreitet n die maximale Stringlänge, wird die resultierende Zeichenkette entsprechend dem letzten legalen UTF8-Zeichen abgeschnitten. Die maximale Stringlänge beträgt auf einem Controller sowie auf dem Control Computer 65 Bytes. Es muss unbedingt sichergestellt sein, dass das Ziel-ByteArray mindestens n Bytes groß ist, inklusive '\0'! Wird dies nicht beachtet kann es zu gravierenden Fehlern kommen.


dest char* OUT Ziel für die Kopie der übergebenen Zeichenkette.

n size_t IN Anzahl Bytes des Ziel-ByteArrays. Es werden nicht mehr als n Bytes kopiert.

src const char* IN Zeichenkette die kopiert werden soll.





UTF8_NULLDEST dest ist ein NULL-Zeiger.

UTF8_WIDTH Anzahl Bytes eines Zeichens konnte nicht ermittelt werden.


NULL Es trat ein Fehler während der Bearbeitung auf oder error ist ein NULL-Zeiger. -> siehe Errorcodes




Zeiger auf dest Die Zeichenkette wurde kopiert

2.4.5 UTF8_Delete


char* UTF8_Delete( const char *src, int start, int len, int *error);

Funktions- beschreibung:

Diese Funktion löscht einen Teilstring aus der übergebenen Zeichenkette. Aus der in src übergebenen Zeichenkette werden len Zeichen ab der Position start herausgelöscht und ein Zeiger auf die resultierende Zeichenkette zurückgeliefert. Der gelieferte Zeiger, zeigt auf ein statisches Byte-Array in der die resultierende Zeichenkette liegt. Die Größe des statischen Byte-Arrays beträgt 65 Bytes, inklusive abschließendes '\0'. Beispiel: Es soll in der Zeichenkette "Der Apfel fällt nicht weit vom Stamm!" das Wort "nicht", inklusive folgendem Leerzeichen, herauslöschen. Dazu wird der Funktion die Startposition 17 und als Anzahl Zeichen die gelöscht werden sollen 6 übergeben. Codefragment: #include <AprolStringUtf8.h> int error = 0; char *quelle = "Der Apfel fällt nicht weit vom Stamm!"; char ziel[65] = {0}; char *temp = UTF8_Delete(quelle, 17, 6, &error); if(error) { /* Fehlerbehandlung ... */ } else { strcpy(ziel, temp); }

Ausgabe: Das Resultat ist die Zeichenkette: "Der Apfel fällt weit vom Stamm!" Es ist auch möglich ab dem Zeichen start, ohne Kenntnis der Anzahl Zeichen in src, alle Zeichen zu löschen. Dazu muss der Wert von len in jedem Fall größer sein als die Länge der restlichen Zeichenkette in src.


src const char*

IN Enthält die zu bearbeitende Zeichenkette.

start int IN Gibt die Startposition in der Zeichenkette an, beginnend mit 1 ab dem ersten Zeichen.



char* UTF8_Delete( const char *src, int start, int len, int *error);

len int IN Gibt an, wie viele Zeichen ab der Startposition gelöscht werden




UTF8_START Der übergebene Wert für start ist kleiner 1.

UTF8_LEN Der übergebene Wert für len ist kleiner 0.

UTF8_HIGHSTART Der übergebene Wert für start ist größer als die Anzahl Zeichen in src.



NULL Es trat ein Fehler während der Bearbeitung auf oder error ist ein NULL-Zeiger.

Zeiger auf Kopie der in src übergebenen Zeichenkette

Es trat ein Fehler während der Bearbeitung auf. Der Errorcode wurde entsprechend gesetzt.

Zeiger auf resultierende Zeichenkette

Die Funktion wurde mit gültigen Werten aufgerufen und es trat kein Fehler während der Bearbeitung auf.

2.4.6 UTF8_Find


int UTF8_Find( const char *src, const char *toFind, int *error );


In der übergebenen Zeichenkette wird ein übergebener Teilstring gesucht. Die Funktion liefert die Position der ersten Übereinstimmung mit toFind in der Zeichenkette src, beginnend mit dem Wert 1 für das erste Zeichen. Wird keine Übereinstimmung gefunden, liefert die Funktion den Wert 0. Beispiel: Es soll in der Zeichenkette "Der Apfel fällt nicht weit vom Stamm!"



int UTF8_Find( const char *src, const char *toFind, int *error );

nach "weit" gesucht werden. Dazu wird der Funktion die Zeichenkette in der gesucht werden soll sowie das Wort bzw. die Zeichenkette, nach der gesucht werden soll, übergeben. Codefragment: #include <AprolStringUtf8.h> int error = 0; char *quelle = "Der Apfel fällt nicht weit vom Stamm!"; int pos = UTF8_Find(quelle, "weit", &error); if(error) { /* Fehlerbehandlung ... */ }

Ausgabe: Das Resultat ist der Wert: "23"


src const char*

IN Zeichenkette in der gesucht wird.

toFind const char*

IN Zeichenkette die gesucht wird.





UTF8_NULLSTR toFind ist ein NULL-Zeiger.



UTF8 NOERRORFLAG error ist ein NULL-Zeiger 0 Keine Übereinstimmung. >= 1 Position der ersten Übereinstimmung,

beginnend mit dem Wert 1 für das erste Zeichen.


2.4.7 UTF8_Insert


char* UTF8_Insert( const char *src, const char *ins, int start, int *error );


Diese Funktion dient zum Einfügen von Strings in eine bestehende Zeichenkette. Fügt in die Zeichenkette src ab Position start, die in ins enthaltene Zeichenkette ein. Die Funktion liefert einen Zeiger auf die resultierende Zeichenkette. Der gelieferte Zeiger, zeigt auf ein statisches ByteArray in der die resultierende Zeichenkette liegt. Die Größe des statischen ByteArrays beträgt 65 Bytes, inklusive abschließendes '\0'. Beispiel: Es soll in der Zeichenkette "Der Apfel fällt weit vom Stamm!" das Wort "nicht" eingefügt werden, so dass als resultierende Zeichenkette "Der Apfel fällt nicht weit vom Stamm!" geliefert wird. Dazu wird die Funktion mit der Original-Zeichenkette, der einzufügenden Zeichenkette und der Startposition 17 aufgerufen. Codefragment: #include <AprolStringUtf8.h> int error = 0; const char *quelle = "Der Apfel fällt weit vom Stamm!"; const char *insert = "nicht "; char ziel[65] = {0}; char *temp = UTF8_Insert(quelle, insert, 17, &error); if(error) { /* Fehlerbehandlung ... */ } else { strcpy(ziel, temp); }

Ausgabe: Das Resultat entspricht der Zeichenkette: "Der Apfel fällt nicht weit vom Stamm!" Bei Überschreitung der max. zulässigen Stringlänge wird die resultierende Zeichenkette auf das letzte gültige UTF8-Zeichen abgeschnitten.


src const char*

IN Zeichenkette in die eingefügt werden soll.

ins const char*

IN Zeichenkette die eingefügt werden soll.

start int IN Gibt die Startposition in der Zeichenkette an, beginnend mit 1 ab dem ersten Zeichen



char* UTF8_Insert( const char *src, const char *ins, int start, int *error );





UTF8_NULLSTR ins ist ein NULL-Zeiger.

UTF8_START start ist kleiner 1.

UTF8_STARTFOLLOW start liegt nicht angrenzend hinter dem Ende des Strings von src

UTF8_MAXSTARTLEN Die resultierende Zeichenkette überschreitet die maximale Stringlänge








2.4.8 UTF8_Left


char* UTF8_Left( const char *src, int len, int *error );


Diese Funktion extrahiert einen linken Teilstring aus der übergebenen Zeichenkette. Es werden len Zeichen ab der ersten Position in der Zeichenkette src extrahiert. Geliefert wird ein Zeiger auf die resultierende Zeichenkette. Der gelieferte Zeiger, zeigt auf ein statisches ByteArray in der die resultierende Zeichenkette liegt. Die Größe des statischen ByteArrays beträgt 65 Bytes, inklusive abschließendes '\0'.




Beispiel: Es sollen aus der Zeichenkette "Der Apfel fällt nicht weit vom Stamm!" die ersten 9 Zeichen extrahiert werden. Codefragment: #include <AprolStringUtf8.h> int error = 0; const char *quelle = "Der Apfel fällt nicht weit vom Stamm!" char ziel[65] = {0}; char *temp = UTF8_Left(quelle, 9, &error); if(error) { /* Fehlerbehandlung ... */ } else { strcpy(ziel, temp); }

Ausgabe: Das Resultat entspricht der Zeichenkette: "Der Apfel" Hinweis: Überschreitet len die maximale Stringlänge, wird die Zeichenkette entsprechend dem letzten legalen UTF8-Zeichen abgeschnitten.


src const char*

IN Zeichenkette aus der extrahiert wird.

len int IN Anzahl Zeichen die extrahiert werden sollen.





UTF8_LEN len ist kleiner 0.

UTF8_HIGHSTART len ist größer als die Anzahl Zeichen von src.




UTF8_MAXSTARTLEN len überschreitet die maximale Stringlänge.




Zeiger auf Kopie der übergebenen Zeichenkette




2.4.9 UTF8_Mid


char* UTF8_Mid( const char *src, int start, int len, int *error );


Diese Funktion extrahiert einen mittleren Teilstring aus der übergebenen Zeichenkette. Es werden len Zeichen ab der Position start aus der Zeichenkette src extrahiert. Geliefert wird ein Zeiger auf die resultierende Zeichenkette. Der gelieferte Zeiger, zeigt auf ein statisches ByteArray in der die resultierende Zeichenkette liegt. Die Größe des statischen ByteArrays beträgt 65 Bytes, inklusive abschließendes '\0'. Beispiel: Es soll aus der Zeichenkette "Der Apfel fällt nicht weit vom Stamm!" die Zeichenkette "fällt nicht weit" extrahiert werden. Dazu wird die Funktion mit der Original Zeichenkette, der Startposition 11 und der Länge von 16 Zeichen aufgerufen. Codefragment: #include <AprolStringUtf8.h> int error = 0; const char *quelle = "Der Apfel fällt nicht weit vom Stamm!" char ziel[65] = {0}; char *temp = UTF8_Mid(quelle, 11, 16, &error); if(error) { /* Fehlerbehandlung ... */ } else { strcpy(ziel, temp);




}

Ausgabe: Das Resultat entspricht der Zeichenkette: fällt nicht weit Hinweis: Überschreitet start + len die maximale Stringlänge oder die Länge von src, wird die Zeichenkette entsprechend dem letzten legalen UTF8-Zeichen abgeschnitten.


src const char*

IN Zeichenkette aus der extrahiert wird.









UTF8_HIGHSTARTLEN start + len ist größer als die Länge von src.

UTF8_MAXSTARTLEN start + len überschreitet die maximale Stringlänge.











2.4.10 UTF8_Replace


char* UTF8_Replace( const char *src, const char *rep, int start, int len, int *error );


Diese Funktion dient zum Ersetzen von Teilstrings in einer bestehende Zeichenkette. Ersetzt in der Zeichenkette src ab Position start, len Zeichen mit dem in rep enthaltenem String. Die Funktion liefert einen Zeiger auf die resultierende Zeichenkette. Der gelieferte Zeiger, zeigt auf ein statisches ByteArray in der die resultierende Zeichenkette liegt. Die Größe des statischen ByteArrays beträgt 65 Bytes, inklusive abschließendes '\0'. Beispiel: Es soll in der Zeichenkette "Der Apfel fällt nicht nah vom Stamm!" das Wort "nah" durch das Wort "weit" ersetzt werden, so dass als resultierende Zeichenkette "Der Apfel fällt nicht weit vom Stamm!" geliefert wird. Dazu wird die Funktion mit der Original-Zeichenkette, der einzufügenden Zeichenkette, der Startposition 23 und der Anzahl Zeichen, len 3, die ersetzt werden soll, aufgerufen. Codefragment: #include <AprolStringUtf8.h> int error = 0; const char *quelle = "Der Apfel fällt nicht nah vom Stamm!"; const char *replace = "weit"; char ziel[65] = {0}; char *temp = UTF8_Replace(quelle, replace, 23, 3, &error); if(error) { /* Fehlerbehandlung ... */ } else { strcpy(ziel, temp); }

Ausgabe: Das Resultat entspricht der Zeichenkette: Der Apfel fällt nicht weit vom Stamm! Bei Überschreitung der maximal zulässigen Stringlänge wird die resultierende Zeichenkette entsprechend dem letzten legalen UTF8-




Zeichen abgeschnitten.


src const char*

IN Zeichenkette in die eingefügt werden soll.

rep const char*

IN Zeichenkette die eingefügt werden soll.


len int IN Anzahl Zeichen die ersetzt werden sollen.





UTF8_NULLSTR rep ist ein NULL-Zeiger.


UTF8_MAXSTARTLEN start überschreitet maximale Stringlänge.

UTF8_STARTFOLLOW start liegt nicht angrenzend hinter dem Ende des Strings von src.

UTF8_MAXSTARTLEN Resultierende Zeichenkette überschreitet max. Stringlänge.











2.4.11 UTF8_Right


char* UTF8_Right( const char *src, int len, int *error );


Diese Funktion extrahiert einen rechten Teilstring aus der übergebenen Zeichenkette. Es werden die letzten len Zeichen aus der Zeichenkette src extrahiert. Geliefert wird ein Zeiger auf die resultierende Zeichenkette. Der gelieferte Zeiger, zeigt auf ein statisches ByteArray in der die resultierende Zeichenkette liegt. Die Größe des statischen ByteArrays beträgt 65 Bytes, inklusive abschließendes '\0'. Beispiel: Es sollen aus der Zeichenkette "Der Apfel fällt nicht weit vom Stamm!" die letzten 10 Zeichen extrahiert werden. Codefragment: #include <AprolStringUtf8.h> int error = 0; const char *quelle = "Der Apfel fällt nicht weit vom Stamm!" char ziel[65] = {0}; char *temp = UTF8_Right(quelle, 10, &error); if(error) { /* Fehlerbehandlung ... */ } else { strcpy(ziel, temp); }

Ausgabe: Das Resultat entspricht der Zeichenkette: vom Stamm! Überschreitet len die maximale Stringlänge oder die Länge von src, wird die Zeichenkette entsprechend dem letzten legalen UTF8-Zeichen abgeschnitten.


src const char* IN Zeichenkette aus der extrahiert wird.

len int IN Anzahl Zeichen die extrahiert



char* UTF8_Right( const char *src, int len, int *error );

werden sollen.





UTF8_HIGHSTART len ist größer als die Länge von src.









1] Weitere Beispiele, sowie Informationen zu UTF8: http://de.wikipedia.org/wiki/UTF-8


2.5 Abbildungen

Abbildung 18: Baustein 'FIND_STRING_INT'


Abbildung 19: Baustein 'RIGHT_STRING'


Abbildung 20: 'REPLACE_STRING'

2.6 Allgemeines zum Datentyp LSTRING

APROL unterstützt die Verwendung von Strings, die länger als 64 Bytes sind, durch die Bereitstellung des zusätzlichen IEC-Typs LSTRING. Dieser neue IEC-Typ kann ausschließlich für Logik auf dem Control Computer verwendet werden. Anhand durchgehender Plausibilitätskontrollen sowie expliziter Fehlerhinweise beim Kompilieren der Projektierungsteile wird eine Verwendung für Bausteine, die auch für den Controller freigegeben sind, unterbunden.

2.7 Verwendung des Datentyps LSTRING Der Datentyp LSTRING ist an den Eingangs- und Ausgangspins der unterstützten Baustein-Typen auswählbar. Beim Bausteintyp "Funktion" ist der neue IEC-Typ ausschließlich an Eingangspins konfigurierbar. Darüber hinaus können Konnektoren vom Typ LSTRING angelegt werden. Variablen vom Typ LSTRING sind dynamisch, d. h. ihr Speicherbedarf entspricht der Länge des Strings in Bytes. Ein Bausteinpin von Typ LSTRING kann mit einem Defaultwert der Länge max. 32767 Bytes initialisiert werden.


Bei Verwendung der LSTRING_UFT8-Funktionen ist bei den Bausteintypen "Funktion" und "Funktionsbaustein" die Länge für den Datentyp LSTRING auf maximal 32767 Bytes begrenzt. Bausteinpins des Datentyps STRING können mit Bausteinpins des Datentyps LSTRING verbunden werden (Typ-Konvertierung).

Bitte beachten Sie, dass als Eingangspin konfigurierte LSTRINGs nicht modifiziert werden dürfen, d. h. auch nicht mit LSTRING_free freigegeben werden!

Die Verantwortung für den Speicher der im C-Code angelegten automatischen Variablen vom Typ LSTRING liegt ausschließlich auf Seiten des Erstellers des C-Codes!

Alle automatisch angelegten Variablen vom Typ LSTRING müssen zu Beginn initialisiert werden, da sonst der erste Zugriff zu einem Speicherfehler führt. Weiterhin müssen vor dem Verlassen des Bausteins (d.h. in jedem Zyklus) alle automatisch angelegten Variablen wieder freigegeben werden (LSTRING_free(xx)), ansonsten entstehen Speicherlecks! Die Initialisierung muss wie folgt vorgenommen werden: LSTRING variable = {{0}};

2.8 Funktionsbeschreibung zum Datentyp LSTRING B&R stellt Ihnen Funktionen zur sicheren Bearbeitung von LStrings zur Verfügung.

Das API dieser Funktionen wird hier beschrieben. Die Funktionen sind in der APROL-PccStd-Bibliothek implementiert und können somit durch Inkludieren des Headers "AprolStringUtf8.h" und Hinzulinken der Bibliothek "libPccStd" innerhalb von APROL überall verwendet werden.

In der Bibliothek "IEC61131_3" in der Gruppe "StringFunctions" wurden für den Datantyp LSTRING neue Funktionen angelegt, welche dieses API nutzen.

Die Funktionen können ohne weiteren Aufwand, d.h. ohne Einbindung des Headers "AprolStringUtf8.h", in jedem Funktionsbaustein bzw. jeder Funktion verwendet werden.

Fehlerbehandlung: Die angebotenen API Funktionen besitzen als letzten Parameter einen Zeiger auf eine Variable vom Typ "int". Jeder API Funktion muss ein entsprechend initialisierter Zeiger übergeben werden, da sonst keine Bearbeitung stattfindet. Innerhalb jeder Funktionsbeschreibung findet sich ein Code-Beispiel aus dem ersichtlich ist, wie mit diesem Zeiger umzugehen ist. Abweichend von den Code-Beispielen muss bei Verwendung der API Funktionen immer auf den Errorcode geprüft werden, nicht auf den Wert. Folgende Fehlercodes werden von dem API übergeben:






UTF8_NULLSRC Ein NULL-Zeiger für src wurde übergeben.

UTF8_NULLSTR Ein NULL-Zeiger für ins / rep / toFind wurde übergeben.

UTF8_NULLDEST Ein NULL-Zeiger für dest wurde übergeben.

UTF8_START Der Wert für start wurde mit kleiner 1 übergeben.

UTF8_LEN Der Wert für len wurde mit kleiner gleich 0 übergeben.

UTF8_HIGHSTART Der Wert für start ist größer als die Anzahl Zeichen in src.

UTF8_HIGHLEN Der Wert für len ist größer als die Anzahl Zeichen in src.

UTF8_HIGHSTARTLEN Der Wert der Summe start + len ist größer als die Anzahl Zeichen in src.

UTF8_MAXSTARTLEN Der Wert der Summe start + len ist größer als die maximale Stringlänge.


UTF8_STARTFOLLOW Der Wert für start liegt nicht angrenzend hinter der letzten Zeichenposition in src.

UTF8_NULLLSTRING Ein NULL-Zeiger für den LString src wurde übergeben.

UTF8_NOBUFFER Für den internen Buffer wurde ein NULL-Zeiger übergeben (interne Fehlermeldung)

UTF8_EXCEEDBUFFER Der String ist größer als der interne Buffer, (interne Fehlermeldung)

Es stehen die nachfolgenden Funktionen zur Verfügung:

2.8.1 LSTRING_val


char* LSTRING_val( LSTRING lstr );


Macht den im LSTRING lstr enthaltenen String als C-String verfügbar, d.h. es wird ein Zeiger auf den internen String herausgegeben. Beispiel: Es soll auf den String des Input-Pins IN (vom Typ LSTRING) zugegriffen werden. Codefragment: char *s = LSTRING_val( IN );




char* LSTRING_val( LSTRING lstr );

lstr LSTRING OUT LString, dem ein Wert zugewiesen werden soll.


Zeiger auf C-String.

Interne, im LSTRING gehaltene Zeichenkette

2.8.2 LSTRING_setc


int LSTRING_setc( LSTRING lstr, const char *cstr );


Diese Funktion weist dem LSTRING lstr den Wert der Zeichenkette cstr zu. Beispiel: Der Output-Pin OUT vom Typ LSTRING eines Funktionsbausteins soll den Wert "Der Apfel fällt nicht weit vom Stamm!" erhalten. Codefragment: LSTRING_setc( OUT, "Der Apfel fällt nicht weit vom Stamm!" );



cstr const char * IN Der C-String, der dem LString zugewiesen werden soll.


0 Kein Fehler.

1 Der Zeiger auf den Wert des C-Strings cstr ist exakt derjenige, der im LString schon gespeichert ist. Diese Fehlermeldung kann beim normalen Arbeiten mit dieser Funktion ignoriert werden.

2.8.3 LSTRING_set


int LSTRING_set( LSTRING dest, LSTRING src );


Diese Funktion weist den Wert des LSTRINGs src dem LSTRING lstr zu. Beispiel:



int LSTRING_set( LSTRING dest, LSTRING src );

Der Output-Pin OUT vom Typ LSTRING eines Funktionsbausteins soll den Wert des Input-Pins IN vom Typ LSTRING erhalten. Codefragment: LSTRING_set( OUT, IN );



cstr LSTRING IN LString, dessen Wert zugewiesen werden soll.


0 Kein Fehler.

1 Die internen Zeiger auf den Wert der beiden LStrings sind identisch!

2.8.4 LSTRING_free


int LSTRING_free( LSTRING lstr );


Diese Funktion gibt dem im LString lstr enthaltenen Speicher für die Zeichenkette frei. Codefragment: LSTRING_free( lstr );


lstr LSTRING IN/ OUT LString, dessen interner Speicher freigegeben werden


0 Kein Fehler.

-1 NULL-Zeiger übergeben

2.8.5 LSTRING_sprintf


int LSTRING_sprintf( LSTRING lstr, const char *format, … );


Diese Funktion schreibt mit Hilfe des Formatierungsstrings format die übergebenen Werte (nummerisch, C-String, etc) in den an erster Position



int LSTRING_sprintf( LSTRING lstr, const char *format, … );

übergebenen LString lstr. Diese Funktion ist entspricht der in der C-Bibliothek enthaltenen Funktion sprintf. Intern wird die Funktion vasprintf verwendet. Da LStrings dynamisch sind, können die bei sprintf bekannten Probleme (Schreiben über den allozierten Speicher hinweg) nicht auftreten. Die Fehlerbehandlung sollte analog zu der eines printf erfolgen, d.h. im Normalfall wird sie entfallen. Beispiel: In eine Variable vom Typ LSTRING soll eine Fehlermeldung geschrieben werden, die aus mehreren Teilen generiert werden soll. Codefragment: INT counter = 7; REAL value = 12.5 rc = LSTRING_sprintf( OUT, “Fehler im Durchlauf %d mit Wert %f“, counter, value );


lstr LSTRING OUT LString, dessen Wert geschrieben werden soll.


>=0 Kein Fehler, Anzahl der geschriebenen Bytes

-1 NULL-Zeiger übergeben

2.8.6 LSTRING_UTF8_LengthInCharacters


int LSTRING_UTF8_LengthInCharacters(LSTRING src, int *error);


Diese Funktion liefert die Anzahl Zeichen in dem übergebenen LString. Beispiel: In einem Funktionsblock soll ein unter „lokale Variablen“ deklarierter LSTRING src den Wert "Der Apfel fällt nicht weit vom Stamm!" erhalten und die Anzahl Zeichen dieser Zeichenkette ermittelt werden. Die Funktion liefert den Wert 37. Codefragment: int error = 0;



int LSTRING_UTF8_LengthInCharacters(LSTRING src, int *error);

LSTRING_setc( src, "Der Apfel fällt nicht weit vom Stamm!" ); int len = LSTRING_UTF8_LengthInCharacters(src, &error); if(error) { /* Fehlerbehandlung ... */ }


src LSTRING IN LString, dessen Anzahl Zeichen

error int* OUT Der Errorcode der

Funktion wird an diesen Parameter übergeben. ACHTUNG: Es handelt sich hierbei um einen Zeiger der auf eine Variable vom Typ 'int' zeigen muss!







>= 0 Die Anzahl Zeichen in der übergebenen Zeichenkette

2.8.7 LSTRING_UTF8_LengthInBytes

Funktionsdeklaration: int LSTRING_UTF8_LengthInBytes( LSTRING src, int *error );

Funktions-beschreibung: Diese Funktion liefert die Anzahl Bytes der im übergebenen LString enthaltenen Zeichenkette, ohne abschließendes '\0'. Beispiel: In einem Funktionsblock soll ein unter „lokale Variablen“ deklarierter



LSTRING src den Wert "Der Apfel fällt nicht weit vom Stamm!" erhalten und die Anzahl Zeichen dieser Zeichenkette ermittelt werden. Die Funktion liefert den Wert 38. Codefragment: int error = 0; LSTRING_setc( src, "Der Apfel fällt nicht weit vom Stamm!" ); int len = LSTRING_UTF8_LengthInBytes(src, &error); if(error) { /* Fehlerbehandlung ... */ }


src LSTRING IN LString, dessen Anzahl Byte, die für die Speicherung der Zeichenkette nötig sind, ermittelt werden soll, ohne abschließendes '\0'.

error int* OUT Der Errorcode der Funktion wird an diesen Parameter übergeben. Achtung: Es handelt sich hierbei um einen Zeiger der auf eine Variable vom Typ 'int' zeigen muss!




Rückgabe-wert: Wert: Bedeutung:




>= 0 Die Anzahl Bytes der übergebenen Zeichenkette.

2.8.8 LSTRING_UTF8_Copy


char* LSTRING_UTF8_Copy( LSTRING dest, LSTRING src, int *error );


Diese Funktion kopiert die in dem LString src enthaltene Zeichenkette in den LString dest und liefert einen Zeiger auf den Inhalt des LStrings dest zurück. Beispiel: In einem Funktionsblock soll ein als LString deklarierter Eingangspin LSTRING src auf einen als LString deklarierten Ausgangspin LSTRING dest kopiert werden. Codefragment: int error = 0; LSTRING_UTF8_Copy( dest, src, &error ); if(error) { /* Fehlerbehandlung ... */ }


dest LSTRING OUT Ziel für die Kopie des übergebenen LStrings.

src LSTRING IN LString, der kopiert werden soll.




UTF8_NULLLSTRING Ein NULL-Zeiger wurde für den LString src oder dest übergeben.



char* LSTRING_UTF8_Copy( LSTRING dest, LSTRING src, int *error );






2.8.9 LSTRING_UTF8_NCopy


char* LSTRING_UTF8_NCopy( LSTRING dest, size_t n, LSTRING src, int *error );


Diese Funktion kopiert die in dem LString src enthaltene Zeichenkette in den LString dest und liefert einen Zeiger auf den Inhalt des LStrings dest zurück. Es werden maximal 'n' Bytes kopiert, inclusive abschließendes '\0' Beispiel: In einem Funktionsblock soll ein als LString deklarierter Eingangspin LSTRING src auf einen als LString deklarierten Ausgangspin LSTRING dest kopiert werden. Codefragment: int error = 0; LSTRING_UTF8_NCopy( dest, 17, src, &error ); if(error) { /* Fehlerbehandlung ... */ }


dest LSTRING OUT Ziel für die Kopie des übergebenen LStrings.

n size_t IN Anzahl Bytes, welche maximal kopiert werden



char* LSTRING_UTF8_NCopy( LSTRING dest, size_t n, LSTRING src, int *error );

src LSTRING IN LString, der kopiert werden soll.




UTF8_NULLLSTRING Ein NULL-Zeiger wurde für den LString src oder dest übergeben.






2.8.10 LSTRING_UTF8_Delete


char* LSTRING_UTF8_Delete( LSTRING src, int start, int len, int *error);

Funktions- beschreibung:

Diese Funktion löscht einen Teilstring aus dem übergebenen LString. Aus der mit dem LString src übergebenen Zeichenkette werden len Zeichen ab der Position start herausgelöscht und ein Zeiger auf die resultierende Zeichenkette zurückgeliefert. Der gelieferte Zeiger zeigt auf ein statisches Byte-Array in der die resultierende Zeichenkette liegt. Die Größe des statischen Byte-Arrays beträgt 32768 Bytes, inklusive abschließendes '\0'. Beispiel: In einem Funktionsblock soll ein unter „lokale Variablen“ deklarierter LSTRING src den Wert "Der Apfel fällt nicht weit vom Stamm!" erhalten. Aus dieser Zeichenkette soll das Wort "nicht", inklusive folgendem




Leerzeichen, herauslöschen. Dazu wird der Funktion die Startposition 17 und als Anzahl Zeichen die gelöscht werden sollen 6 übergeben. Die erhaltene Zeichenkette soll in dem Output-Pin dest vom Typ LSTRING gespeichert werden. Codefragment: int error = 0; LSTRING_setc( src, "Der Apfel fällt nicht weit vom Stamm!" ); char *temp = LSTRING_UTF8_Delete( src, 17, 6, &error); if(error) { /* Fehlerbehandlung ... */ } else { LSTRING_setc( dest, temp ); }

Ausgabe: Das Resultat ist die Zeichenkette: "Der Apfel fällt weit vom Stamm!" Es ist auch möglich ab dem Zeichen start, ohne Kenntnis der Anzahl Zeichen in src, alle Zeichen zu löschen. Dazu muss der Wert von len in jedem Fall größer sein als die Länge der restlichen Zeichenkette in src.


src LSTRING IN Enthält die zu bearbeitende

start Int IN Gibt die Startposition in der Zeichenkette an, beginnend mit 1 ab dem

len Int IN Gibt an, wie viele Zeichen ab der Startposition gelöscht werden sollen.







UTF8_NULLLSTRING Ein NULL-Zeiger wurde für den LString src übergeben.

UTF8_START Der übergebene Wert für start ist kleiner 1.

UTF8_LEN Der übergebene Wert für len ist kleiner 0.

UTF8_HIGHSTART Der übergebene Wert für start ist größer als die Anzahl Zeichen in src.








2.8.11 LSTRING_UTF8_Find


int LSTRING_UTF8_Find( LSTRING src, LSTRING toFind, int *error );


In der Zeichenkette des übergebenen LStrings wird ein übergebener Teilstring gesucht. Die Funktion liefert die Position der ersten Übereinstimmung mit toFind in der Zeichenkette src, beginnend mit dem Wert 1 für das erste Zeichen. Wird keine Übereinstimmung gefunden, liefert die Funktion den Wert 0. Beispiel: In einem Funktionsblock soll ein unter „lokale Variablen“ deklarierter LSTRING src den Wert "Der Apfel fällt nicht weit vom Stamm!" erhalten. Aus dieser Zeichenkette soll das Wort "weit" gesucht werden. Dazu wird der Funktion die Zeichenkette in der gesucht werden soll sowie das Wort bzw. die Zeichenkette, nach der gesucht werden soll, übergeben. Codefragment: int error = 0; LSTRING_setc( src, "Der Apfel fällt nicht weit vom Stamm!" );



int LSTRING_UTF8_Find( LSTRING src, LSTRING toFind, int *error );

int pos = UTF8_Find( src, "weit", &error ); if(error) { /* Fehlerbehandlung ... */ }

Ausgabe: Das Resultat ist der Wert: "23"


src LSTRING IN Zeichenkette in der gesucht wird.

toFind LSTRING IN Zeichenkette die gesucht wird.




UTF8_NULLLSTRING Ein NULL-Zeiger wurde für den LString src oder toFind übergeben.



UTF8 NOERRORFLAG error ist ein NULL-Zeiger 0 Keine Übereinstimmung. >= 1 Position der ersten Übereinstimmung,

beginnend mit dem Wert 1 für das erste Zeichen.


2.8.12 LSTRING_UTF8_Insert


char* LSTRING_UTF8_Insert( LSTRING src, LSTRING ins, int start, int *error );


Diese Funktion dient zum Einfügen von Strings in die Zeichenkette eines bestehenen LStrings. Sie fügt in die Zeichenkette src ab Position start die in ins enthaltene Zeichenkette ein. Die Funktion liefert einen Zeiger auf die resultierende Zeichenkette. Der gelieferte Zeiger zeigt auf ein statisches Byte-Array in der die resultierende Zeichenkette liegt. Die Größe des statischen Byte-Arrays beträgt 32768 Bytes, inklusive abschließendes '\0'. Beispiel: In einem Funktionsblock soll ein unter „lokale Variablen“ deklarierter LSTRING src den Wert "Der Apfel fällt weit vom Stamm!" erhalten. Aus dieser Zeichenkette soll das Wort "nicht" eingefügt werden, so dass als resultierende Zeichenkette "Der Apfel fällt nicht weit vom Stamm!" geliefert wird. Dazu wird die Funktion mit der Original-Zeichenkette, der einzufügenden Zeichenkette und der Startposition 17 aufgerufen. Das Ergebnis soll auf den als LSTRING deklarierten Output-Pin OUT geschrieben werden. Codefragment: int error = 0; LSTRING_setc( src, "Der Apfel fällt weit vom Stamm!" ); char *temp = LSTRING_UTF8_Insert( src, "nicht ", 17, &error ); if(error) { /* Fehlerbehandlung ... */ } else { LSTRING_setc( OUT, temp ); }

Ausgabe: Das Resultat entspricht der Zeichenkette: "Der Apfel fällt nicht weit vom Stamm!"


src LSTRING IN Zeichenkette in die eingefügt werden soll.

ins LSTRING IN Zeichenkette die eingefügt werden soll.



char* LSTRING_UTF8_Insert( LSTRING src, LSTRING ins, int start, int *error );

start Int IN Gibt die Startposition in der Zeichenkette an, beginnend mit 1 ab dem ersten Zeichen.




UTF8_NULLLSTRING Ein NULL-Zeiger wurde für den LString src oder ins übergeben.


UTF8_STARTFOLLOW start liegt nicht angrenzend hinter dem Ende des Strings von src

UTF8_MAXSTARTLEN Die resultierende Zeichenkette überschreitet die maximale Stringlänge








2.8.13 LSTRING_UTF8_Left


char* LSTRING_UTF8_Left( LSTRING src, int len, int *error );


Diese Funktion extrahiert einen linken Teilstring aus der Zeichenkette des übergebenen LStrings. Es werden len Zeichen ab der ersten Position in der Zeichenkette src




extrahiert. Geliefert wird ein Zeiger auf die resultierende Zeichenkette. Der gelieferte Zeiger zeigt auf ein statisches Byte-Array in der die resultierende Zeichenkette liegt. Die Größe des statischen Byte-Arrays beträgt 32768 Bytes, inklusive abschließendes '\0'. Beispiel: In einem Funktionsblock soll ein unter „lokale Variablen“ deklarierter LSTRING src den Wert "Der Apfel fällt nicht weit vom Stamm!" erhalten. Aus dieser Zeichenkette sollen die ersten 9 Zeichen extrahiert werden. Das Ergebnis soll auf den als LSTRING deklarierten Output-Pin OUT geschrieben werden. Codefragment: int error = 0; LSTRING_setc( src, "Der Apfel fällt weit vom Stamm!" ); char *temp = LSTRING_UTF8_Left( src, 9, &error ); if(error) { /* Fehlerbehandlung ... */ } else { LSTRING_setc( OUT, temp ); }

Ausgabe: Das Resultat entspricht der Zeichenkette: "Der Apfel" Hinweis: Überschreitet len die maximale Länge von 32767 Zeichen, wird die Zeichenkette entsprechend dem letzten legalen UTF8-Zeichen abgeschnitten.


src LSTRING IN Zeichenkette aus der extrahiert wird.










UTF8_HIGHSTART len ist größer als die Anzahl Zeichen von src.









2.8.14 LSTRING_UTF8_Mid


char* LSTRING_UTF8_Mid( LSTRING src, int start, int len, int *error );


Diese Funktion extrahiert einen mittleren Teilstring aus der Zeichenkette des übergebenen LStrings. Es werden len Zeichen ab der Position start aus der Zeichenkette src extrahiert. Geliefert wird ein Zeiger auf die resultierende Zeichenkette. Der gelieferte Zeiger zeigt auf ein statisches Byte-Array in der die resultierende Zeichenkette liegt. Die Größe des statischen Byte-Arrays beträgt 32768 Bytes, inklusive abschließendes '\0'.




Beispiel: In einem Funktionsblock soll ein unter „lokale Variablen“ deklarierter LSTRING src den Wert "Der Apfel fällt nicht weit vom Stamm!" erhalten. Aus dieser Zeichenkette soll die Zeichenkette "fällt nicht weit" extrahiert werden. Dazu wird die Funktion mit der Original Zeichenkette, der Startposition 11 und der Länge von 16 Zeichen aufgerufen. Das Ergebnis soll auf den als LSTRING deklarierten Output-Pin OUT geschrieben werden. Codefragment: int error = 0; LSTRING_setc( src, "Der Apfel fällt nicht weit vom Stamm!" ); char *temp = LSTRING_UTF8_Mid( src, 11, 16, &error ); if(error) { /* Fehlerbehandlung ... */ } else { LSTRING_setc( OUT, temp ); }

Ausgabe: Das Resultat entspricht der Zeichenkette: fällt nicht weit Hinweis: Überschreitet len die maximale Länge von 32767 Zeichen, wird die Zeichenkette entsprechend dem letzten legalen UTF8-Zeichen abgeschnitten.



start int IN Gibt die Startposition in der Zeichenkette an, beginnend mit 1 ab dem











UTF8_HIGHSTARTLEN start + len ist größer als die Länge von src.

UTF8_MAXSTARTLEN start + len überschreitet die maximale Stringlänge.


Rückgabe-wert:

Wert: Bedeutung:






2.8.15 LSTRING_UTF8_Replace


char* LSTRING_UTF8_Replace( LSTRING src, LSTRING rep, int start, int len, int *error );


Die Funktion dient zum Ersetzen von Teilstrings in einer bestehende Zeichenkette. Ersetzt in der Zeichenkette des LStrings src ab Position start, len Zeichen mit dem in rep enthaltenem String. Die Funktion liefert einen Zeiger auf die




resultierende Zeichenkette. Der gelieferte Zeiger, zeigt auf ein statisches ByteArray in der die resultierende Zeichenkette liegt. Die Größe des statischen ByteArrays beträgt 32768 Bytes, inklusive abschließendes '\0'. Beispiel: In einem Funktionsblock soll ein unter „lokale Variablen“ deklarierter LSTRING src den Wert "Der Apfel fällt nicht nah vom Stamm!" erhalten. In dieser Zeichenkette soll das Wort "nah" durch das Wort "weit" ersetzt werden, so dass als resultierende Zeichenkette "Der Apfel fällt nicht weit vom Stamm!" geliefert wird. Dazu wird die Funktion mit der Original-Zeichenkette, der einzufügenden Zeichenkette, der Startposition 23 und der Anzahl Zeichen, len 3, die ersetzt werden soll, aufgerufen. Das Ergebnis soll auf den als LSTRING deklarierten Output-Pin OUT geschrieben werden. Codefragment: int error = 0; LSTRING_setc( src, "Der Apfel fällt nicht nah vom Stamm!" ); char *temp = LSTRING_UTF8_Replace( src, “weit”, 23, 3, &error ); if(error) { /* Fehlerbehandlung ... */ } else { LSTRING_setc( OUT, temp ); }

Ausgabe: Das Resultat entspricht der Zeichenkette: Der Apfel fällt nicht weit vom Stamm! Bei Überschreitung der maximal Länge 32767 wird die resultierende Zeichenkette entsprechend dem letzten legalen UTF8-Zeichen abgeschnitten.


src LSTRING IN Zeichenkette in die eingefügt werden soll.

rep LSTRING IN Zeichenkette die eingefügt werden soll.





len int IN Anzahl Zeichen die ersetzt werden sollen.




UTF8_NULLLSTRING Ein NULL-Zeiger wurde für den LString src oder rep übergeben.


UTF8_MAXSTARTLEN start überschreitet maximale Stringlänge.

UTF8_STARTFOLLOW start liegt nicht angrenzend hinter dem Ende des Strings von src.

UTF8_MAXSTARTLEN Resultierende Zeichenkette überschreitet max. Stringlänge.








2.8.16 LSTRING_UTF8_Right


char* LSTRING_UTF8_Right( LSTRING src, int len, int *error );


Diese Funktion extrahiert einen rechten Teilstring aus der übergebenen Zeichenkette. Es werden die letzten len Zeichen aus der Zeichenkette src extrahiert.




Geliefert wird ein Zeiger auf die resultierende Zeichenkette. Der gelieferte Zeiger zeigt auf ein statisches Byte-Array in der die resultierende Zeichenkette liegt. Die Größe des statischen Byte-Arrays beträgt 32768 Bytes, inklusive abschließendes '\0'. Beispiel: In einem Funktionsblock soll ein unter „lokale Variablen“ deklarierter LSTRING src den Wert "Der Apfel fällt nicht weit vom Stamm!" erhalten. Aus dieser Zeichenkette sollen die letzten 10 Zeichen extrahiert werden. Das Ergebnis soll auf den als LSTRING deklarierten Output-Pin OUT geschrieben werden. Codefragment: int error = 0; LSTRING_setc( src, "Der Apfel fällt nicht weit vom Stamm!" ); char *temp = LSTRING_UTF8_Right( src, 10, &error ); if(error) { /* Fehlerbehandlung ... */ } else { LSTRING_setc( OUT, temp ); }

Ausgabe: Das Resultat entspricht der Zeichenkette: vom Stamm! Hinweis: Überschreitet len die maximale Länge von 32767 Zeichen, wird die Zeichenkette entsprechend dem letzten legalen UTF8-Zeichen abgeschnitten.




error int* OUT Der Errorcode der Funktion wird an diesen Parameter übergeben. ACHTUNG:




Es handelt sich hierbei um einen Zeiger der auf eine Variable vom Typ 'int' zeigen muss!



UTF8_NULLLSTRING Ein NULL-Zeiger wurde für den LString src übergeben.

UTF8_HIGHSTART len ist größer als die Länge von src.









2.9 Beispiele für die Bausteine Charge und Splitter .


2.9.1 Beispiel Baustein Charge

Abbildung 21: Funktions-Baustein Charge (Pinlayout)

Abbildung 22: Funktions-Baustein Charge (I/O)

Abbildung 23: Funktions-Baustein Charge (Lokale Variablen)


Funktions-Baustein Charge Programm-Code /* Dieser Funktionsblock schreibt bei Beginn einer */ /* neuen Charge eine Statusmeldung in den Ausgangs-Pin */ /* "Meldung" */ /* und in jedem Zyklus die Charge, die Gruppe, den Zaehler */ /* und den Messwert formatiert in den Ausgangs-Pin "Werte" */ /* */ /* Sonderbehandlung: */ /* Ist die Charge eine Reinigungscharge, erkennbar daran, */ /* dass das Wort "cleaner" in der ChargenId vorkommt, wird */ /* "Werte" nicht geschrieben und "Reinigung" gesetzt. */ /* */ /* Ist die Charge nicht angegeben bzw. der Nummer der Gruppe */ /* nicht positiv, wird ein Fehler in "Gueltig" gemeldet */ BOOL charge_legal = 0; BOOL gruppe_legal = 0; BOOL einheit_legal = 0; BOOL reinigung = 0; BOOL chargenwechsel = 0; BOOL erstecharge = 0; BOOL interner_fehler = 0; LSTRING clean = {{0}}; LSTRING_setc( clean, "cleaner" ); /* if ( !init ) { LSTRING_setc( alteCharge, "" ); init = 1; } */ /* Die Charge muss übergeben werden */ charge_legal = Charge && LSTRING_val( Charge ) && (strcmp( LSTRING_val( Charge ), "" ) != 0 ); /* Die Gruppennummer muss größer als 0 sein */ gruppe_legal = Gruppe > 0; /* Einheit darf auch leer sein */ einheit_legal = Einheit && LSTRING_val( Einheit ); if ( charge_legal ) { int error = 0; int pos = LSTRING_UTF8_Find( Charge, clean, &error ); if ( error != UTF8_NOERROR ) { interner_fehler = 1; } else { Reinigung = (pos > 0); if ( strcmp( LSTRING_val( Charge ), LSTRING_val( alteCharge ) ) != 0 ) { chargenwechsel = 1; if ( strcmp( "", LSTRING_val( alteCharge ) ) != 0 ) { erstecharge = 1; } } } } if ( charge_legal && !interner_fehler ) { if ( gruppe_legal )


Gueltig = 1; LSTRING beendet = {{0}}; LSTRING laeuft = {{0}}; if ( chargenwechsel && !erstecharge ) { LSTRING_sprintf( beendet, "Charge '%s' beendet,", LSTRING_val( alteCharge ) ); LSTRING_sprintf( laeuft, "%s '%s' gestartet", (reinigung) ? "Reinigungscharge" : "Charge", LSTRING_val( Charge ) ); LSTRING_set( alteCharge, Charge ); } else { LSTRING_setc( beendet, "" ); LSTRING_sprintf( laeuft, "%s '%s' läuft", (reinigung) ? "Reinigungscharge" : "Charge", LSTRING_val( Charge ) ); } if (Gueltig) { LSTRING_sprintf( Meldung, "%s%s", LSTRING_val( beendet ), LSTRING_val( laeuft ) ); LSTRING_sprintf( Werte, "%s;%d;%d;%f%s%s", LSTRING_val( Charge ), (gruppe_legal) ? Gruppe : -1, Zaehler, Messwert, (einheit_legal) ? ";" : "", (einheit_legal) ? LSTRING_val( Einheit ) : "" ); } else { LSTRING_setc( Meldung, "Fehler" ); LSTRING_setc( Werte, "" ); Gueltig = 0; Reinigung = 0; } LSTRING_free( beendet ); LSTRING_free( laeuft ); } else { Gueltig = 0; Reinigung = 0; LSTRING_setc( Meldung, "Fehlerhafte Charge" ); LSTRING_setc( Werte, "" ); } LSTRING_free( clean );


2.9.2 Beispiel Baustein Splitter

Abbildung 24: Funktions-Baustein Splitter (Pinlayout)

Abbildung 25: Funktions-Baustein Splitter (I/O)

Abbildung 26: Funktions-Baustein Splitter (Lokale Variablen)

Funktions-Baustein Splitter Programm-Code /* Dieser Funktionsblock liest über den Eingangs-Pin */ /* "Woerter" Woerter ein und fügt sie an den lokal */ /* gehaltenen "Speicher" an. */


/* Zyklus für Zyklus wird Wort für Wort aus diesem */ /* "Speicher" in die Ausgangs-Variable "Wort" */ /* ausgegeben. */ int error = 0; LSTRING leer = {{0}}; LSTRING_setc( leer, " " ); if ( Lies && !Gelesen ) { /* Neue Woerter */ Gelesen = 1; LSTRING temp = {{0}}; LSTRING_set( temp, Speicher ); if (!strcmp( LSTRING_val( temp ), "" ) ) LSTRING_set( Speicher, Woerter ); else LSTRING_sprintf( Speicher, "%s %s", LSTRING_val( temp ), LSTRING_val( Woerter ) ); LSTRING_set( alteWoerter, Woerter ); LSTRING_free( temp ); } else { if (!Lies) Gelesen = 0; } int pos = LSTRING_UTF8_Find( Speicher, leer, &error ); if ( pos > 0 ) { char *w = LSTRING_UTF8_Left( Speicher, pos-1, &error ); LSTRING_setc( Wort, w ); int len = LSTRING_UTF8_LengthInCharacters( Speicher, &error ); char *p = LSTRING_UTF8_Mid( Speicher, pos+1, len-2, &error ); LSTRING_setc( Speicher, p ); } else { LSTRING_set( Wort, Speicher ); LSTRING_setc( alteWoerter, "" ); LSTRING_setc( Speicher, "" ); } LSTRING_free( leer );

Konfiguration des AlarmMonitors via XML 3-1

3 Konfiguration des AlarmMonitors via XML

Abbildung 27: Verbindung eines AlarmMonitors zu mehreren CC-Accounts

Innerhalb eines projektierten CC-Accounts (Linux-Login) kann maximal eine AlarmServer-Instanz laufen. Ein DisplayCenter auf einer Operator-Station verbindet sich mit einem oder mehreren CC-Accounts, d.h. mit den darin enthaltenen System-Diensten AlarmServer und Iosys.

3.1 Konfiguration der AlarmMonitor via XML

Mit dem AlarmMonitor stellt APROL Ihnen ein interaktives System zur Verfügung, welches dem Operator ermöglicht, alle Alarm-Zustandsparameter rasch zu erfassen und entsprechend zu reagieren. Schnell und einfach können Sie via XML sowohl Look&Feel als auch Funktionalitäten des AlarmMonitors frei konfigurieren und damit an firmenspezifische Bedienphilosophien anpassen. Die folgenden Kapitel geben Ihnen eine Anleitung für diese Konfiguration des AlarmMonitors.

Detail-Informationen zu den Funktionalitäten und zur Bedienung des AlarmMonitors entnehmen Sie bitte dem Handbuch "C1 Interaktive Prozessführung", Kapitel Alarm-System. Hinweise zur Verwendung von Alarmbausteine finden Sie im Handbuch "B2 Project Engineering", Kapitel Alarmbausteine im CFC. Einzelheiten zu den Aufrufoptionen des DisplayCenter entnehmen Sie dem Handbuch 'X99 Handbuch CC-Module'.

APROL ermöglicht die Einrichtung einer zentralen Übersicht über die Alarme aus verschiedenen Automatisierungsbereichen.


Ein Operator hat somit die Möglichkeit, Alarmereignisse aus einem oder mehreren CC-Accounts in einen AlarmMonitor zu beobachten und zu bearbeiten. Mehrere AlarmMonitore können hierbei in einem DisplayCenter gestartet werden.

Die Systemsoftware aller angebundenen CC-Accounts muss mindestens den Stand des APROL R 3.6 haben. Bei Betrieb mit APROL-Versionen < R 3.6 kann es zu einer nicht korrekten Anzeige führen!

3.2 Allgemeines zur Konfiguration des AlarmMonitors Folgende Abbildung zeigt Ihnen den grundsätzlichen Aufbau des AlarmMonitors:

Abbildung 28: Bezeichnungen im AlarmMonitor

Die Alarme werden anhand der Alarmbausteine konfiguriert. Im AlarmMonitor werden dagegen die Alarmereignisse angezeigt.

Sie können die jeweilige Darstellung der Alarmzeile und der Alarmliste wie folgt anpassen:

Schriftformatierungen und farbliche Gestaltung der Alarmzeile/Alarmliste,

Anzeige signifikanter Informationen zu den Alarmereignissen,

Platzierung und Konfiguration der Buttons in der Alarmzeile/Alarmliste,

Geometrie-Management der Alarmzeile und der Alarmliste,

Definition und Konfiguration mehrerer AlarmMonitore

Anbinden mehrerer CC-Accounts an ein oder mehrere AlarmMonitore

Hierbei können Sie beispielsweise die Anzahl und die Reihenfolge der sichtbaren Alarmereignisse vorgeben und festlegen, welche Buttons an welcher Stelle angezeigt werden. Die Informationen zu einem angezeigten Alarmereignis können in einer oder mehreren Zeilen angeordnet werden, wobei die einzelnen Zeilen aus unterschiedlichen Feldern zusammengesetzt werden. Diese Felder können Text oder Alarminformationen enthalten und in


beliebiger Reihenfolge angeordnet werden. Des Weiteren ist es möglich, den Feldern und Informationen verschiedene Schriftformatierungen, Vorder- und Hintergrundfarben zuzuweisen.

Abbildung 29: Beispiel einer individuell gestalteten Alarmzeile

Abbildung 30: Beispiel einer via XML konfigurierten Alarmliste

Die Konfiguration des AlarmMonitors wird durch zwei XML-Dateien festgelegt. Zur Definition des Layouts dient eine Layout-Datei. Die Definition der Kommunikation erfolgt via Monitor-Datei. Durch B&R werden verschiedene standardmäßige XML-Konfigurationsdateien mitgeliefert. Um die Konfiguration des AlarmMonitors an die Firmen-Standards anzupassen, erstellen Sie bitte Kopien der mitgelieferten XML-Dateien, die Sie dann modifizieren und verwenden können.

Die Dateien sind unter /opt/aprol/cnf/DisplayCenter/alarm_layout und /opt/aprol/cnf/DisplayCenter/monitor_layout zu finden. Die Regeln zur Erstellung von gültigen XML-Konfigurationsdateien für den AlarmMonitor sind in einer DTD-Datei (DTD - Document Type Definition) hinterlegt. Weitere Erläuterungen hierzu finden Sie im Kapitel Die Layout- und Monitor-DTD-Dateien.

Für jede Instanz des DisplayCenters kann anhand der CC-Module ausgewählt werden, welche Konfigurationsdateien genutzt werden soll. Hierzu ist jeweils eine explizite Zuweisung einer Layout-Konfigurationsdatei zu einer Instanz des DisplayCenters notwendig. Ein Vorteil dieser Vorgehensweise liegt darin, dass durch Zuweisen einer anderen Datei sehr schnell eine andere Konfiguration verwendet werden kann.

Aus der Kommandozeile können Sie im Runtime-System das DisplayCenter sofort mit der gewünschten Konfigurationsdatei starten. Verwenden Sie für diese temporäre Verwendung der XML-Datei bitte den Befehl: AprolStartDisplayCenter -start 01 --replace_args -alarmLayout|alarmMonitor <XML-Dateiname>

Die dauerhafte Zuweisung einer XML-Datei erfolgt im Konfigurations-Dialog der CC-Module mit der Option -alarmLayout|alarmMonitor für das DisplayCenter.


Um eine XML-Konfigurationsdatei anzupassen oder neu erstellen zu können, müssen zunächst einige Grundlagen zur Struktur und Syntax von XML- und DTD-Dateien bekannt sein. Weiterführende Informationen entnehmen Sie bitte in nachfolgende Kapiteln und aus dem Handbuch 'X6-SelfHTML' auf der Startseite der APROL Dokumentation.

3.2.1 Besonderheiten beim Betrieb mit mehreren CC-Accounts Für die Konfiguration der Multi-AlarmServer-Fähigkeit des AlarmMonitors muss dem DisplayCenter über die Option '-alarmMonitor' eine XML-Datei zugewiesen werden, welche die Anzahl der anzuzeigenden AlarmMonitore sowie die Verbindungsinformationen zu den CC-Accounts enthält.

Es können maximal 63 CC-Accounts und somit AlarmServer angebunden werden. Eine höhere Anzahl der angebundenen CC-Accounts wirkt sich u. a. auf längere Antwortzeiten sowie eine höhere System- und Netzwerklast aus.

Einzelheiten zu den Aufrufoptionen des DisplayCenter entnehmen Sie dem Handbuch 'X99 Handbuch CC-Module'.

Falls die Option nicht 'verwendet' wird, so erfolgt ausschließlich eine Verbindung mit dem Default- CC-Accounts. Default-Einstellungen bei Verwendung der Option ist ein AlarmMonitor und das Default- CC-Accounts (via Datei: am_1local_monitor.xml).

Es ist möglich, von einer Operator-Station auf mehrere Projekte auf einem APROL-Server Zugriffe zu tätigen.

Noch zusätzlich ist es möglich von einer Operator-Station auf mehrere APROL-Server Zugriffe zu tätigen.

Dies hat nachfolgende Konsequenzen für die Interpretation der Operator-Rechte sowie für die Interpretation der Alarm-Filter.

Gleiche Operatornamen auf verschiedenen CC-Accounts sind aus Sicht des Alarm-Systems identisch.

Zugriffsrechte auf Alarmgruppen (Sehen/Quittieren/Sperren) werden ausschließlich auf Basis der lokalen Runtime-Datenbank ermittelt und gelten für den Zugriff auf alle kontaktierten Runtime-Systeme. Falls auf eine Alarmgruppe zugegriffen werden soll, die in der lokalen Datenbank nicht vorhanden ist, so wird standardmäßig das Zugriffsrecht gewährt (Tri-State-Prinzip).


Ist ein gleicher Alarmgruppen-Name auf mehreren Runtime-Systemen vorhanden, wird dieser als eine Gruppe interpretiert. Ein eingestellter Alarmgruppen-Filter wird immer für alle, dem AlarmMonitor zugeordneten Runtime-Systeme gleich gesetzt. Das gleiche Verhalten gilt für alle anderen Filterparameter (z. B. PV, Priorität).

Darüber hinaus sind bei der Verbindung zu mehreren CC-Accounts für den Alarm-System folgende Hinweise zu beachten:

Historische Darstellung (AlarmViewer) Für eine korrekte Darstellung der Alarm-Historie müssen die Alarme aller beteiligten CC-Accounts auf den Protokollserver des CAE-Projektes weitergeleitet werden. Nur so können auch in der Historie die Alarmereignisse von verschiedenen CC-Accounts in einer kombinierten Liste angezeigt werden.

Online Trends der AlarmParameter Der Online-Trend für die Zustandsparameter des Alarmereignis kann auch bei Alarmen von einem 'fremden' APROL-System aufgerufen werden. Es wird hierbei der Iosys auf dem entfernten System kontaktiert. Ein Zugriff auf die historische Aufzeichnung zur Anzeige des weiter zurückliegenden Verlaufs erfolgt jedoch nicht.

Interventionstexte: Ein Aufschalten des Interventionstextes ist bei Alarmereignisse vom 'fremden' APROL-Systemen nicht möglich.

Bild zum Alarm: Ein Aufschalten der 'Prozessgrafik zum Alarm' ist bei Alarmereignisse von einem 'fremden' APROL-System nicht möglich.

Im Folgenden werden nähere Informationen zu den für die AlarmMonitor-Konfiguration verwendeten XML-Dateien und der DTD-Datei sowie deren Zusammenspiel gegeben. Hierbei wird ein Überblick gegeben, in welcher Art Änderungen an den Konfigurationen vorgenommen werden können.

3.3 Die XML-Konfigurationsdateien für den AlarmMonitor Eine wohlgeformte und gültige XML-Konfigurationsdatei beinhaltet die konkreten Informationen zu Darstellung und Verhalten der Alarmzeile und der Alarmliste im DisplayCenter. Durch B&R werden verschiedene XML-Konfigurationsdateien mitgeliefert, die unterschiedliche Standardkonfigurationen in verschiedenen Sprachen zur Verfügung stellen. Die Layout-Konfigurationsdateien, die das Erscheinungsbild steuern, sind nach der APROL-Installation im Verzeichnis /opt/aprol/cnf/DisplayCenter/alarm_layout abgelegt und können direkt gewählt oder als Vorlage kopiert und angepasst werden:

Konfiguration Erläuterung



al_1alarm_1line_<Language-Code>.xml Alarmzeile: 1 Alarmereignis, einzeilig Alarmliste: einzeilig, frei positionierbar

al_1alarm_2lines_<Language-Code>.xml Alarmzeile: 1 Alarmereignis, zweizeilig Alarmliste: zweizeilig, nicht frei positionierbar

al_3alarms_1line_<Language-Code>.xml Alarmzeile: 3 Alarmereignisse, einzeilig Alarmliste: einzeilig, frei positionierbar

al_old_style_1line_<Language-Code>.xml Alarmzeile: 1 Alarmereignis, einzeilig Alarmliste: einzeilig, nicht frei positionierbar

al_old_style_2lines_<Language-Code>.xml Alarmzeile: 1 Alarmereignis, einzeilig Alarmliste: zweizeilig, nicht frei positionierbar

Nachfolgende Language-Codes stehen zur Verfügung: 001, 007, 031, 033, 034, 049, 086

Die Monitor-Konfigurationsdateien, die Verbindungen steuern, sind nach der APROL-Installation im Verzeichnis /opt/aprol/cnf/DisplayCenter/alarm_monitor abgelegt und können direkt gewählt oder als Vorlage kopiert und angepasst werden:


am_1local_monitor.xml Ein AlarmMonitor verbunden mit dem Default- CC-Accounts

am_2_monitor.xml Zwei AlarmMonitore jeweils verbunden mit dem Default- CC-Accounts

3.3.1 Iosys- und CC-Account Einstellungen

Anhand der Monitor-Konfigurationsdatei 'monitor.xml' werden die Verbindungen zu den gewünschten CC-Accounts (einer oder mehrere) konfiguriert.

Zu diesem Zweck müssen die gewünschten CC-Accounts im Element 'system' in der Monitor-Konfigurationsdatei angegeben werden.

Dies kann sowohl anhand der Attribute 'iosys', 'al_server_selfid' und 'name' als auch anhand des Attributs 'inst_ref' erfolgen.


Durch eine explizite Angabe der Verbindungsparameter (Iosys, AlarmServer Self-ID) sowie des Namens der Instanz und der Beschreibung werden diese Parameter verwendet um direkt mit dem CC-Account zu verbinden.

Eine Angabe des Attributes 'inst_ref' () wird immer zuerst interpretiert und bewirkt eine Abfrage der restliche Daten aus der lokalen Runtime-Datenbank. Für jeden AlarmMonitor, welcher dargestellt werden soll, wird ein separater Eintrag zu dem Element 'alarmmonitor' notwendig.

Attribute Beschreibung

alarmview_id Der Wert des Attributs 'id' des Elements 'alarmview' in der Layout-Konfigurationsdatei. Hierdurch wird dem Monitor das gewünschte Layout von der Layout-Datei zugewiesen.

name<Language-Code> Frei gewählter Name des AlarmMonitors, der im DisplayCenter dargestellt wird. Dies dient zur Differenzierung bei mehreren CC-Accounts.

Das Element 'system' ist ein Unter-Element des Elements 'alarmmonitor'.

Attribute Beschreibung

inst_ref Instanzname eines APROL-Systems mit konfiguriertem AlarmServer aus der lokalen Runtime-Datenbank. Das Schlüsselwort 'DEFAULT_CC' kann verwendet werden. Dies dient als Platzhalter für den Default Control Computer des CAE-Projekts.

iosys Nur, falls 'inst_ref' nicht verwendet wird: Liste der Hostnamen und Iosys-Ports durch Kommata getrennt. z.B. iosys="host1:1, host2:1" (Bei Verwendung mit redundanten Systeme)

al_server_selfid Nur, falls 'inst_ref' nicht verwendet wird: Die Self-ID der AlarmServer (Eintrag in den CC-Modulen des APROL-Systems)

name Nur, falls 'inst_ref' nicht verwendet wird:

Name des Projektierungsteils APROL-System

inst Nur, falls 'inst_ref' nicht verwendet wird:

Instanzname des APROL-Systems

desc<Language-Code> Nur, falls 'inst_ref' nicht verwendet wird: Beschreibung in der jeweiligen Landessprache

Nachfolgende Länder-Codes stehen zur Verfügung: 001, 007, 031, 033, 034, 049, 086 Beispiel 1


<alarmmonitor_cnf> <alarmmonitor alarmview_id="1" name001="power supply Plant 1-6" name049="Stromversorgung Anlage 1-6"> <system inst_ref="CC01"/> </alarmmonitor> </alarmmonitor_cnf> Beispiel 2 <alarmmonitor_cnf> <system iosys="host1:1,host2:1" al_server_selfid="dem1" name="name of aprolsystem" inst="Inst of aprolsystem" desc001="Desc" desc049="Beschreibung" /> <system iosys="host3:1,host4:1" al_server_selfid="dem3" name="name of aprolsystem" inst="Inst of aprolsystem" desc001="Desc" desc049="Beschreibung" /> </alarmmonitor_cnf>

Bei einem Update bzw. Upgrade der APROL-Systemsoftware werden die oben genanten Verzeichnisse 'alarm_layout' und 'alarm_monitor' vollständig überschrieben, da die mitgelieferten Konfigurationen immer an die jeweils erweiterten Funktionalitäten des Alarm-Systems angepasst, d. h. erweitert werden. Verwenden Sie statt der von B&R mitgelieferten Standardkonfigurationen eigene XML-Dateien, müssen Sie diese entsprechend anpassen, damit Ihnen die neuen Funktionalitäten in der Visualisierung zur Verfügung stehen.

In der Engineering- und der Runtime-Umgebung stehen Ihnen die Verzeichnisse /home/<CC-Account>/ENGIN/cnf/DisplayCenter/alarm_layout und /home/<CC-Account>/RUNTIME/cnf/DisplayCenter/alarm_layout zur Verfügung. In diesen Verzeichnissen können globale XML-Layout-Konfigurationsdateien abgelegt werden.

Beim Download eines CAE-Projekts werden die Konfigurationsdateien aus den Verzeichnissen 'alarm_layout' und 'alarm_monitor' des Engineering-Systems in die jeweiligen Verzeichnisse des Runtime-Systems kopiert. Der bisherige Inhalt dieses Verzeichnisses wird dabei überschrieben. Das bedeutet, dass Dateien, die nach einem Download erhalten bleiben sollen, im Engineering-System abgelegt werden müssen.

Änderungen der Konfiguration des AlarmMonitors können wie folgt durchgeführt werden:

durch Kopieren und Modifizieren der aktuell zugewiesenen XML-Datei im Engineering-System

durch Zuweisen einer Standardkonfiguration

oder durch Zuweisen einer anderen XML-Datei

3.3.2 Modifikation einer XML-Konfigurationsdatei


In den meisten Fällen ist es nicht nötig eine Datei aufwendig neu zu erstellen. Die Modifikation einer bestehenden XML-Datei ist praktikabler. Modifikationen einer XML-Datei müssen mit den Regeln der Datei layout.dtd bzw. monitor.dtd kompatibel sein (siehe Kapitel Die Layout- und Monitor-DTD-Dateien).

Die veränderte Darstellung im DisplayCenter durch eine modifizierte XML-Datei können Sie in der Runtime-Umgebung sehr schnell und einfach testen. Starten Sie dazu bitte das DisplayCenter aus der Kommandozeile mit dem Befehl: AprolStartDisplayCenter -start 01 --replace_args -alarmLayout|alarmMonitor <XML-Dateiname>

Um eine Datei zu modifizieren, sollte diese in einem XML-Editor geöffnet werden. Hierzu steht Ihnen der kxmleditor zur Verfügung, den Sie aus dem KDE-Menü über "APROL/Werkzeuge/XML-Editor (kxmleditor)" starten. Nach den vorgenommenen Änderungen speichern Sie die Datei bitte unter einem neuen Namen. Die Benennung kann grundsätzlich frei erfolgen. Ein sinnvoller Name sollte jedoch Hinweise auf die konkreten Konfigurationen geben. Achten Sie bitte ebenfalls darauf, für eine Layout-Datei, den entsprechenden Ländercode in den Dateinamen zu integrieren (<dateiname>_<Language-Code>.xml). Dies entspricht den APROL-weiten Konventionen und hilft Ihnen, den multilingualen Einsatz von APROL zu optimieren.

Beim Start des DisplayCenters wird geprüft, ob die zugewiesene Layoutdatei in der richtigen Sprachversion (entsprechend der APROL Spracheinstellungen) vorliegt und gegebenenfalls eine andere Sprachversion verwendet. In einer entsprechenden Meldung wird auf diese automatische Korrektur hingewiesen. Bei einer Benennung ohne Sprachkürzel erfolgt diese Überprüfung nicht.

Auch die sprachenspezifische Darstellung im DisplayCenter können Sie im Runtime-System schnell überprüfen. Aus der Kommandozeile starten Sie das DisplayCenter in der gewünschten Sprache mit dem Befehl AprolStartDisplayCenter -start 01 --add_args -languageCode <Language-Code>

Das DisplayCenter wird automatisch mit der Konfigurationsdatei in der richtigen Sprache gestartet. Bei Sprachen außer deutsch und englisch setzt dies natürlich voraus, dass die entsprechende Sprache mit der Language-DVD installiert wurde.

Abbildung 31: Automatische Wahl der Sprachversion einer Layoutdatei

Im AlarmMonitor (Zeilen- oder Listenansicht) können Sie jederzeit über das Kontextmenü "Konfigurationsdatei" den Namen der aktuellen Layoutdatei sowie das Verzeichnis, aus dem die Datei geladen wurde, überprüfen.


Einfache Änderungen der Layout-Konfiguration, die zum Beispiel Farben oder Schriften betreffen, können durch Änderung von Attributwerten (XML-Tag) erfolgen. Es können gegebenenfalls weitere Attribute hinzugefügt oder gelöscht werden. Welche Möglichkeiten hierbei genau gegeben sind (zum Beispiel Eingabe von Zeichendaten oder Auswahl einer vorgegebenen Option), ist in der DTD-Datei zu ersehen. Wird ein Attribut nicht angegeben oder kein Attributwert zugewiesen, so wird, wenn in der DTD-Datei angegeben, automatisch der Standardwert angenommen. Weiterreichende Änderungen sind mit dem Anordnen (Umsortieren, Hinzufügen, Löschen) von Elementen sowie der Anpassung der entsprechenden Inhalte und Attribute verbunden. Dies ist zum Beispiel für eine Umstrukturierung der Zeilen und Felder der Statuszeilen oder Alarmereignisse bedeutsam, wobei unter anderem die Anordnung und Reihenfolge der Alarminformationen oder Texte festgelegt werden kann.

Sind Änderungen an den Verzeichnissen alarm_layout oder monitor_layout im Engineering-System vorgenommen worden, so ist das Build der CC-Task und ein Download zum Runtime-System erforderlich, damit die Konfiguration auf das Operator-System verteilt wird.

3.3.3 Zuweisen der Konfigurationsdateien Jeder Instanz des DisplayCenters muss eine Layout-Konfigurationsdatei zugewiesen werden, aus der die Anweisungen zum Layout des AlarmMonitors entnommen werden. Eine Monitor-Konfigurationsdatei muss nicht zwingend zugewiesen werden. In der Engineering-Umgebung erfolgt die Zuweisung anhand der CC-Module des Control Computers (via Optionen '-alarmLayout' und '-alarmMonitor' des DisplayCenters). Zur Auswahl stehen die XML-Dateien aus den Verzeichnissen /home/<CC-Account>/ENGIN/cnf/DisplayCenter/alarm_layout und opt/aprol/cnf/DisplayCenter/alarm_layout.

Liegen in beiden Verzeichnissen XML-Dateien mit identischem Namen vor, so wird die Datei unter /home/<CC-Account>/ENGIN/cnf/DisplayCenter/alarm_layout verwendet. Die Verzeichnisstruktur sowie das Fallbackverhalten der Monitor-Konfigurationsdateien sind analog hierzu.

Ist eine Änderung der Zuweisung vorgenommen worden, so ist das Generieren der CC-Task erforderlich. Durch einen Download auf das Runtime-System werden die Einstellungen aus dem Engineering-System übernommen.

Mit Hilfe des StartManagers kann ebenfalls die Zuweisung von Konfigurationsdateien zu einem DisplayCenter erfolgen. Hierzu wird in der Option '-alarmLayout' oder '-alarmMonitor' des DisplayCenters aus der vorgegebener Liste eine Konfigurationsdatei ausgewählt und im StartManager abgespeichert. In diesem Fall kann aus den Dateien des Verzeichnisses /home/<CC-Account>/RUNTIME/cnf/DisplayCenter/alarm_<layout|monitor>

und aus dem APROL-globalen Verzeichnis /opt/aprol/cnf/DisplayCenter/alarm_<layout|monitor> ausgewählt werden.


Die Zuweisung über den StartManager ist temporär und wird durch einen Download vom Engineering-System überschrieben. Auf diesen Sachverhalt weist Sie der StartManager durch eine entsprechende Meldung hin.

Hinweise zur Verwendung des StartManagers finden Sie im Handbuch "B5 Download & Debugging", Kapitel System-Management.


3.4 Beschreibung der Konfigurationsmöglichkeiten Im Folgenden werden die Konfigurations-Möglichkeiten des AlarmMonitors beschrieben. Die DTD-Datei legt sämtliche mögliche Elemente, deren Anordnung, Attribute und mögliche Attributwerte fest. Aus der DTD-Datei kann der Aufbau und Inhalt gültiger XML-Dateien abgeleitet werden. (Siehe Kapitel Die DTD-Datei). Zu den einzelnen Elementen wird erläutert, welche Funktion sie in der Konfiguration haben, wobei auf einige Attribute näher eingegangen wird. Zur prinzipiellen Verdeutlichung werden Beispiele aus XML-Dateien sowie Bilder der Baumstrukturdarstellung von XML-Dateien gegeben. Diese Strukturdarstellungen werden Sie in dem mit APROL installierten kxmleditor wiederfinden.

3.4.1 Aufbau der Layout-Konfigurationsdateien

Die Elementdefinition des Wurzel-Elements alarmlayout in der Layout-Konfigurationsdatei bestimmt den grundlegenden Aufbau einer gültigen XML-Datei. Zunächst werden Schriften (fontlist) definiert. In der folgenden Konfiguration des AlarmMonitors (alarmview) werden erst allgemeine Einstellungen vorgenommen und anschließend Darstellungsstile (styles), die Darstellung von Alarmzeile (linelayout) und Alarmliste (listlayout) festgelegt. Für eine beschleunigte, einheitliche Konfiguration können Sie hierbei auf die vordefinierten Schriften und Darstellungsstile zurückgreifen.

Abbildung 32: Grobe Struktur von alarmlayout im kxmleditor

(Siehe DTD-Datei, alarmlayout). Folgende Abbildung stellt den Aufbau einer XML-Datei detaillierter dar und dient Ihnen zur Orientierung in die Dateistruktur:



Abbildung 33: Detaillierte Struktur der XML-Datei

3.4.2 Geometrie-Management Via XML können Sie schnell und unkompliziert das Geometrie-Management der Zeilendarstellung und der Listendarstellung definieren. Da die Struktur der XML-Datei für diese beiden Darstellungsarten identisch ist, werden Sie sich in dem übersichtlich strukturierten Aufbau der Elemente schnell zurechtfinden. Sie können ein differenziertes Geometrie-Management für Alarmzeile und Alarmliste sofort erkennen und modifizieren. Auf diese Weise sind die nachfolgenden Punkte rasch zu realisieren.

eine bedarfsgerechte Konfiguration für die Verwendung des Multiscreenings

das Definieren von Layout und Inhalt der Statuszeile

die Platzierung und Konfiguration der Buttons in der Alarmzeile/Alarmliste

ein optimales Layout für die Darstellung in unterschiedlichen Sprachen

3.4.2.1 Positionierung der Alarmzeile

Die Alarmzeile kann mithilfe des Elements alarmview in der Layout-Konfigurationsdatei oberhalb, unterhalb, links oder rechts der Prozessgrafik im DisplayCenter angezeigt werden. Modifizieren Sie dazu bitte das Attribut location (siehe DTD-Datei, alarmview).

Bei Verwendung der Optionen left und right ist zu beachten, dass sich durch die Breite der konfigurierten Statuszeile bzw. Alarmereignisse sowie durch die Anordnung der Buttons die Breite der Alarmzeile ergibt. Um die Lesbarkeit der Anzeige zu gewährleisten, sind notwendige Modifikationen in den Elementen linelayout/statusline und linelayout/line vorzunehmen. Bei unpassender Konfiguration ist die Alarmanzeige zu breit und schränkt die angezeigte Prozessgrafik erheblich ein.

3.4.2.2 Variable Feldbreiten

Mit dem Attribut use_splitter in der Layout-Konfigurationsdatei kann festgelegt werden, ob die Breite einzelner Felder in angezeigten Alarmen durch Ziehen der Ränder manipuliert werden kann. Wird ein Feld in eine bestimmte Breite gezogen (Links-Klick auf Rand des Feldes, halten und ziehen), wird automatisch versucht, die Ränder der entsprechenden Felder aller Alarme als eine senkrechte, gerade Linie auszurichten. Dies ist nur bedingt möglich, da die Breiten der betroffenen Felder und ihrer angrenzenden Felder nur den Konfigurationen entsprechend variiert werden können (minimale und maximale Breite, stretchfactor). Weitere Einschränkungen ergeben sich daraus, dass die Länge des Inhalts von Feldern in unterschiedlichen Alarmen variieren kann. Die Option ist standardmäßig aktiviert und an grauen Linien zwischen Feldern erkennbar. In Kombination mit der Angabe von Stretchfaktoren ist diese Option nur eingeschränkt nutzbar (siehe Dynamische Feldbreiten). In den Elementen linelayout und listlayout kann das Attribut für Alarmzeile und Alarmliste auch separat konfiguriert werden.


3.4.2.3 Konfiguration der Alarmzeile und Alarmliste

Mit den Elementen linelayout und listlayout in der Layout-Konfigurationsdatei können Sie den AlarmMonitor für die Operator-Stationen individuell konfigurieren und erzielen schnell eine optimale Darstellung der Alarmzeile/-liste in Kombination mit der Prozessgrafik. Dies ermöglicht dem Operator eine schnelle Beurteilung der Anlagenzustände und der Alarme sowie eine intuitive Bedienung des AlarmMonitors. Alarmzeile und Alarmliste werden getrennt konfiguriert, sind jedoch prinzipiell in derselben Art aufgebaut. Sie enthalten jeweils Unterelemente für die Darstellung der Buttons, der Statuszeile und einer oder mehrerer Zeilen der Alarmereignisse.

Mit den Attributen font, style, backgroundcolor, foregroundcolor, und mouseover_color können Sie Schrift- und Farbformatierungen definieren. Weitere Hinweise hierzu finden Sie im Kapitel Schriftformatierungen und Farben.

Abbildung 34: Struktur von linelayout und listlayout im kxmleditor

(Siehe DTD-Datei, linelayout, listlayout). Optionales Attribut 'paddingframe_color': Mit dem optionalen Attribut paddingframe_color kann für die Elemente 'linelayout', 'listlayout' und 'statusline' die Farbe des äußeren Rahmens der Alarm- bzw. Status-Feldelemente definiert werden. Die Eigenschaft wird vom 'linelayout' bzw. 'listlayout' auf die beinhaltete 'statusline' vererbt. Das heißt, die Farbe muss somit dort nicht explizit gesetzt werden, falls die im übergeordneten Element definierte Farbe verwendet werden soll. Falls das Attribut nicht gesetzt wird, so wird die Standardfarbe für Fensterhintergründe verwendet.


Abbildung 35: Attribut 'paddingframe_color' für die Alarmzeile

Abbildung 36: Attribut 'paddingframe_color' für die Statuszeile (abweichend)

Abbildung 37: Resultierende Farbgebung der Alarm- und Stratuszeile

3.4.2.4 Anzahl der angezeigten Alarmereignisse


Die Anzahl der angezeigten Alarmereignisse definieren Sie mit dem Attribut number_of_alarms in der Layout-Konfigurationsdatei. Für die Alarmzeile (linelayout) sind 1-3 angezeigte Alarmereignisse sinnvoll, um die Größe der Prozessgrafik nicht unnötig einzuschränken. Für die Alarmliste (listlayout) kann die Anzahl deutlich größer gewählt werden, da diese im gesamten Fenster des DisplayCenters dargestellt wird oder im Multiscreening-Betrieb auf einem anderen Bildschirm dargestellt werden kann.

Abbildung 38: Alarmzeile mit einem angezeigten Alarmereignis

Abbildung 39: Alarmzeile mit zwei angezeigten Alarmereignissen

3.4.2.5 Frei positionierbare Alarmzeile

Mit dem Attribut movable im Element linelayout in der Layout-Konfigurationsdatei kann eine frei positionierbare Alarmzeile konfiguriert werden. Diese kann in der Visualisierung durch Doppelklick auf den Greifer der Alarmzeile bzw. durch Ziehen am Greifer von der festen Position gelöst werden. Das Andocken an die konfigurierte Position im Hauptfenster erfolgt durch Doppelklick auf die Titelzeile der Alarmzeile.

Abbildung 40: Greifer der Alarmzeile


Abbildung 41: Frei positionierte Alarmzeile

Bitte konfigurieren Sie eine frei positionierbare Alarmliste nicht in Kombination mit deaktiviertem WindowManager (Aufrufoption -noWindowManager für das DisplayCenter), um sicherzustellen, dass die Alarmliste im obersten Fenster angezeigt wird.

Weitere Information zur Verwendung der frei positionierbaren Alarmzeile/ -liste finden Sie in dem Handbuch "C1 Interaktive Prozessführung".

3.4.2.6 Verhalten aufgeschalteter Makros bei geöffneter Alarmliste Um Zustände von Anlagenteilen bei geöffneter Alarmliste weiter beobachten und bedienen zu können, modifizieren Sie bitte das Element listlayout. Über das Attribut unmap_makros können Sie festlegen, ob die in der Prozessgrafik aufgeschalteten Makros bei Öffnen der Alarmliste weiterhin im Vordergrund zu sehen sind oder von der Alarmliste verdeckt werden.

Abbildung 42: Im Vordergrund liegendes Makro

3.4.2.7 Verhalten der Alarmliste beim Wechsel der Prozessgrafik Ist einem angezeigten Alarmereignis eine Prozessgrafik zugewiesen, so besteht die Möglichkeit, über ein Icon in die entsprechende Prozessgrafik zu springen. Informationen über die Konfiguration dieser Funktionalität in der Layout-Konfigurationsdatei finden Sie im Kapitel Alarminformationen (alarminfo). Mit dem Attribut auto_close kann festgelegt werden, ob die geöffnete Alarmliste beim Wechseln der Prozessgrafik ausgeblendet wird oder weiterhin im Vordergrund angezeigt wird.


Ist eine bewegliche Alarmliste konfiguriert (Attribut movable), um diese in einer Multiscreening-Umgebung auf einen anderen Bildschirm zu legen, so sollte das Attribut auto_close nicht gleichzeitig auf true gesetzt werden. Die Alarmliste verdeckt in diesem Fall die Prozessgrafik nicht, würde aber beim Aufruf des "Bild-zum-Alarm" trotzdem geschlossen werden.

3.4.2.8 Buttons, Statuszeile und Zeilen der Alarmereignisse Um die Bedienbarkeit des AlarmMonitors optimal zu konfigurieren, können Sie zulässige interaktive Eingriffe und anzuzeigende Informationen in der Layout-Konfigurationsdatei definieren, die dem Operator helfen, sich auf wichtige Aspekte der Prozessführung zu konzentrieren. Alarmzeile und Alarmliste setzten sich jeweils aus einer Statuszeile, den Buttons und einem oder mehreren Alarmereignissen zusammen. Die Anzeige der Statuszeile und der Buttons ist optional. Buttons (buttons) Ihnen stehen sieben verschiedene Buttons zur Verfügung, die in der Alarmzeile und Alarmliste angezeigt werden können. Die Ausrichtung der ausgewählten Buttons erfolgt mit den Attributen orientation und position.

Abbildung 43: Horizontal angeordnete Buttons links neben Statuszeile

Abbildung 44: Vertikal angeordnete Buttons rechts neben Statuszeile

Für jeden Button ist anzugeben, ob er angezeigt werden soll (enable) und ob der entsprechende Funktionsaufruf per Funktionstaste möglich sein soll (key). Der Aufruf per Funktionstaste kann zum Beispiel unterbunden werden, um ein versehentliches Quittieren von Alarmen zu verhindern. Weitere Hinweise zur Verwendung der Buttons im AlarmMonitor finden Sie im Handbuch "C1 Interaktive Prozessführung", Kapitel AlarmMonitor. In der Alarmliste werden automatisch vier weitere Buttons für die Navigation innerhalb der Alarmliste und ein fünfter Button zum Verlassen der Liste angezeigt:

Abbildung 45: Zusätzliche, automatisch angezeigte Buttons für die Alarmliste

(Siehe auch DTD-Datei, buttons).


Statuszeile (statusline) und Zeilen der Alarmereignisse (line) Bei der Gestaltung der Statuszeile und der Zeilen der Alarmereignisse können Sie Icons und Zustandsinformationen der Alarmereignisse kombinieren. Des Weiteren haben Sie die Möglichkeit, Felder mit statischem Text an beliebiger Stelle in diese Zeilen zu integrieren. Über die Konfiguration der Statuszeile und der Zeilen der Alarmereignisse definieren Sie, welche relevanten Informationen dem Operator im AlarmMonitor angezeigt werden, sowie in welchem Layout sie dargestellt werden. Welche Informationen dargestellt werden können und wie Sie dies konfigurieren, ist im Kapitel Informationen zu den Alarmereignissen beschrieben. Hinweise zur Konfigurationen von Schriften und Farben finden Sie im Kapitel Schriftformatierungen und Farben. In den nun folgenden Absätzen erfahren Sie, wie Sie das Geometrie-Management innerhalb der Statuszeile sowie der Zeilen der Alarmereignisse beeinflussen (z. B. ob die Statuszeile angezeigt wird oder wie viel Platz für die einzelnen Informationen zur Verfügung steht). Die Statuszeile und die Zeilen der Alarmereignisse können Sie flexibel und individuell aus einzelnen nebeneinander liegenden Feldern zusammensetzen, die durch die Unterelemente alarminfo, text und spacer gebildet werden. Diese können in beliebiger Anzahl und Reihenfolge aufgeführt werden.

Alle auftretenden Alarme werden nach den Vorgaben der Elemente line angezeigt. In jedem Element line wird eine Zeile konfiguriert. Es muss mindestens eine Zeile des Alarmereignisses angegeben werden, bei Bedarf können jedoch auch weitere hinzugefügt werden. An den Anfang jedes Alarmereignisses wird automatisch eine Checkbox zur Auswahl des Alarmereignisses gesetzt, dies ist nicht konfigurierbar.

Abbildung 46: Struktur von statusline und line im kxmleditor

(Siehe DTD-Datei, statusline, line).

Anzeigen der Statuszeile Für die Statuszeile (statusline) wird mit dem Attribut enable definiert, ob sie angezeigt werden soll. Für die Alarmzeile (Oberelement linelayout) und die Alarmliste (Oberelement listlayout) können Sie eine differenzierte Darstellung konfigurieren. Definieren der Feldbreiten für alarminfo, text und spacer Um dem Operator eine übersichtliche Darstellung aller relevanten Informationen zu ermöglichen, achten Sie bitte auf die Konfiguration der einzelnen Feldbreiten. In den Zeilen der Alarmereignisse werden zwischen den Feldern keine Zwischenräume eingefügt. Der gesamte zur Verfügung stehende Platz muss aufgeteilt werden; anderenfalls werden die Felder zentriert, wobei am Anfang und Ende graue Bereiche eingefügt werden. In der Statuszeile werden die Felder auf die gesamte Zeilenbreite aufgeteilt. Nicht ausgefüllte Bereiche vor, nach und zwischen den Feldern werden dabei ebenfalls grau dargestellt.


Abbildung 47: Nicht ausgenutzter Platz wird durch graue Bereiche ergänzt

Der zur Verfügung stehende Platz ändert sich zum Beispiel in Abhängigkeit von der Bildschirmauflösung und der Breite des Fensters, in dem die Alarmzeile bzw. Alarmliste erscheint.

Bei der Konfiguration der Feldbreiten ist zu berücksichtigen, dass die Alarminformationen in der Länge variieren können. Außerdem ist es für die Übersichtlichkeit sinnvoll, dass innerhalb mehrzeiliger Alarmereignisse und über alle Alarmereignisse gesehen Spalten mit gradlinigen senkrechten Grenzen ausgebildet werden. Dies geschieht nicht automatisch.

Die Breite lässt sich mit verschiedenen Methoden fest oder dynamisch konfigurieren. Hierzu stehen in allen drei Elementen die Attribute minimum_width, maximum_width und stretchfactor zur Verfügung.

Die minimale Breite eines Feldes kann mit minimum_width angegeben werden. Das Attribut maximum_width legt die maximale Breites eines Feldes fest. Inhalt, der über die maximale Breite hinausgeht, wird im AlarmMonitor abgeschnitten und mit „...“ dargestellt. Liegt der Mauszeiger über dem Text, so wird der gesamte Text als Tooltipp angezeigt. Wird keine maximale Breite definiert, so wird immer der gesamte Inhalt im betreffenden Feld angezeigt. Bei langen Inhalten kann dies dazu führen, dass in der Ansicht horizontal gescrollt werden muss. Die Werte beider Attribute werden in Pixel angegeben.

Bitte beachten Sie, dass es sich um tatsächliche Pixel handelt, was unterschiedliche Darstellungen auf Monitoren mit verschiedenen Bildschirmauflösungen zur Folge hat.

Mit dem Attribut stretchfactor steht Ihnen die Möglichkeit zur Verfügung, die Breiten von Feldern dynamisch anzupassen. Hierbei wird ein angestrebtes Verhältnis der Feldbreiten durch ein Verhältnis der Stretchfaktoren vorgegeben. Die Attributwerte können ganze positive Zahlen einschließlich 0 umfassen.

Wird für mehrere Elemente das Attribut stretchfactor definiert, so wird die Breite der betreffenden Felder zunächst durch die Breite der Inhalte bestimmt (wenn keine Einschränkungen vorgenommen werden). Darüber hinaus zur Verfügung stehender Platz wird derart auf die Felder verteilt, dass eine Anpassung der Breitenverhältnisse an das Verhältnis der Stretchfaktoren angestrebt wird. Kann das Verhältnis mit dem zur Verfügung stehenden Platz nicht erreicht werden, so wird zunächst das Feld mit dem größten Stretchfaktor breiter. Ist das Breitenverhältnis erfüllt und steht noch Platz zur Verfügung, so wird dieser direkt anteilig auf die übrigen Felder mit einem Stretchfaktor aufgeteilt. Die Breiten der Felder, die keinen Stretchfaktor oder den Wert 0 angegeben haben, werden von diesem Mechanismus nicht beeinflusst. Die folgenden Beispiele zeigen übliche Konfigurationen für die Breite von Feldern, in denen die Attribute miteinander kombiniert werden. Feste Feldbreiten:


Eine feste Feldbreite kann durch die Vergabe desselben Wertes für minimale und maximale Breite erzielt werden. Beispiel: <alarminfo maximum_width="210" minimum_width="210" font="helvetica12"> Quittierpflichtig: </alarminfo>

Abbildung 48: Konfiguration mit festen Feldbreiten

Hierbei ist zu beachten, dass sich beispielsweise durch einen anderen Font der Platzbedarf des Inhalts ändert. Somit reicht die vorgegebene Breite eventuell nicht mehr aus, um den gesamten Text anzuzeigen. Dies können Sie vermeiden, indem Sie für das entsprechende Feld weder minimale noch maximale Breite definieren. In diesem Fall wird die Breite des Feldes durch die Breite des Inhalts bestimmt und somit automatisch an variierenden Platzbedarf angepasst.

Dynamische Feldbreiten: Mit Angabe der Stretchfaktoren und minimalen Breiten wird der zur Verfügung stehende Platz dynamisch unter den betreffenden Feldern aufgeteilt. Dabei sind die Felder mindestens so breit wie der Inhalt, wobei die minimale Breite nicht unterschritten wird. Beispiel: <alarminfo stretchfactor="1" minimum_width="200" > ALIAS </alarminfo> <alarminfo stretchfactor="2" minimum_width="400" > ALARMTEXT </alarminfo>

Sie können die Feldbreite dem anzuzeigenden Inhalt dynamisch anpassen und dabei die Breite sowohl auf einen Minimal- als auch auf einen Maximalwert begrenzen. Hierbei wird mindestens die minimale Breite angezeigt. Ist der Inhalt jedoch breiter, so wird auch das Feld automatisch breiter, wächst jedoch nicht über die maximale Breite hinaus. Beispiel: <alarminfo maximum_width="210" minimum_width="80" > ALARMTEXT </alarminfo>

Abbildung 49: Konfiguration mit variablen Feldbreiten


Abbildung 50: Konfiguration mit teils festen, teils variablen Feldbreiten

Innerhalb einer Zeile dürfen die Elemente alarminfo und text nicht gleichzeitig einen Stretchfaktor > 0 haben.

Den Inhalt der Felder alarminfo und text können Sie mit dem Attribut align ausrichten.

Die Verwendung des Attributs use_splitter kann in Kombination mit der Verwendung von Stretchfaktoren zu Problemen in der Darstellung führen. Wenn innerhalb einer Zeile ein Element alarminfo und ein Element text gleichzeitig einen Stretchfaktoren > 0 besitzen, kann es helfen, das Attribut use_splitter auf "false" zu setzen.

3.4.3 Informationen zu den Alarmereignissen Die Layout-Konfiguration via XML ermöglicht es Ihnen, gezielt und schnell zu definieren, welche Informationen und Schaltflächen im AlarmMonitor angezeigt werden und wo diese dargestellt werden. Auf diese Weise können Sie die visuelle Darstellung ohne viel Aufwand so konfigurieren, dass die Prioritäten und Zustände der Alarme vom Operator sofort erfasst und richtig beurteilt werden können. Die Konfiguration folgender Informationen und Objekte ist beispielsweise möglich:

interaktive Icons,

Meldetexte Alarm-Zustandsparameter,

Anzahl der anstehenden, gesperrten und quittierpflichtigen Alarme,

Unterdrückung gesetzter Alarmfilter,

erweiterte Zeitanzeigen,

automatische Sortierung der Alarmereignisse nach Priorität oder Kommen-Zeit,

statischer Text

Der gleiche strukturelle Aufbau von Alarmzeile (Element linelayout) und Alarmliste (Element listlayout) im XML-Code ermöglicht Ihnen ein schnelles und komfortables Modifizieren der Datei. Zeitsparend können Sie globale Darstellungsstile (styles) für den AlarmMonitor definieren, die Sie für die Alarmzeile und die Alarmliste differenziert genauer spezifizieren können (siehe Kapitel Schriftformatierungen und Farben). Eine individuelle Konfiguration für die Darstellung im Multiscreening ist ebenfalls möglich. Hinweise hierzu finden Sie im Kapitel Geometrie-Management.


Abbildung 51: Struktur von alarmview im kxmleditor

(Siehe DTD-Datei, alarmview)

3.4.3.1 Lokaler Warnton

Mit dem Attribut activate_alarmbell in der Layout-Konfigurationsdatei definieren Sie für das Element alarmview, ob bei Auftreten eines Alarms lokal ein Warnton ertönen soll. Der lokale Warnton wird am entsprechenden Rechner erzeugt, auf dem der DisplayCenter gestartet ist und kann auch nur für diesen durch das Attribut ausgeschaltet werden. Der globale Warnton hingegen, der zum Beispiel durch eine Hupe in einer Halle und an anderen Operator-Stationen ertönt, wird auf diese Art nicht beeinflusst, sondern kann mit dem Button „Warnton quittieren“ im DisplayCenter für den aktuellen Alarm ausgeschaltet werden. Beispiel: <alarmview activate_alarmbell="true" location="top" >

3.4.3.2 Positionierung der Alarmzeile und Anzahl der angezeigten Alarmereignisse

Sie können die Alarmzeile mithilfe des Attributes location (Element alarmview) in der Layout-Konfigurationsdatei positionieren. Für die Elemente linelayout und listlayout wird mit dem Attribut number_of_alarms die Anzahl der angezeigten Alarmereignisse angegeben. Bitte beachten Sie dazu die Hinweise im Kapitel Geometrie-Management.

3.4.3.3 Unterdrückung der Alarmfilter Um sicherzustellen, dass in der Alarmzeile bzw. der Alarmliste kein Alarm durch einen Filter ausgeblendet wird, modifizieren Sie bitte die Elemente linelayout und listlayout in der Layout-Konfigurationsdatei. Durch das Attribut ignore_alarmfilter kann erzwungen werden, dass grundsätzlich kein Alarmfilter in der jeweiligen Darstellung angewendet wird.

3.4.3.4 Zeitdarstellung Eine genauere Fehleranalyse wird ermöglicht, wenn Sie die Kommen- und Gehen-Zeiten der Alarme um zusätzliche Informationen erweitern. Mit dem Attribut show_milliseconds in der Layout-Konfigurationsdatei kann im Element alarmview für Alarmzeile und Alarmliste gleichzeitig angegeben werden, ob zusätzlich die Millisekunden angezeigt werden sollen. Diese Einstellung kann in den Elementen linelayout und listlayout


auch getrennt für Alarmzeile und Alarmliste vorgenommen werden. (Die Attribute der Unterelemente haben Vorrang vor denen der Oberelemente). Außerdem können Sie in den Elementen linelayout und listlayout die Anzeige der Zeitzone konfigurieren. Verwenden Sie dazu bitte das Attribut show_timezone.

Abbildung 52: Einfache Zeitanzeige

Abbildung 53: Erweiterte Zeitanzeige

3.4.3.5 Sortierung der Alarmereignisse Durch eine automatische Sortierung der Alarmereignisse können Sie den Operator darin unterstützen, die angezeigten Alarme, sowie die Reihenfolge der notwendigen Aktionen richtig zu beurteilen. Die Sortierung der angezeigten Alarmereignisse in der Alarmzeile (wenn mehrzeilig) und der Alarmliste kann mit Hilfe des Attributes sorting entweder nach den Zeiten des Auftretens der Alarme oder nach den Prioritäten erfolgen. Diese Sortierung konfigurieren Sie mit dem Element alarmview in der Layout-Konfigurationsdatei sowohl für die Alarmzeile als auch für die Alarmliste. Wird nach der Zeit sortiert, so steht das zuletzt aufgetretene Alarmereignis oben. Bei einer Sortierung nach Prioritäten werden die Alarmereignisse von oben nach unten aufsteigend sortiert (wobei "0" als höchste Priorität betrachtet wird).

Abbildung 54: Sortierung nach Kommen-Zeiten

Abbildung 55: Sortierung nach Prioritäten

3.4.3.6 Informationen in der Statuszeile und in den Zeilen der Alarmereignisse

Durch eine entsprechende Konfiguration des AlarmMonitors stellen Sie sicher, dass dem Operator in der Visualisierung alle relevanten Informationen zu den Alarmen zur Verfügung stehen. Darüber hinaus können Sie ihm ausgewählte Funktionalitäten über Icons zur Verfügung stellen.


Sowohl die Gestaltung der Statuszeile (Element statusline) als auch der Zeilen der Alarmereignisse (Element line) erfolgt durch die Anordnung folgender Elemente in der Layout-Konfigurationsdatei:

alarminfo

spacer

text

Diese Elemente können Sie in beliebiger Anzahl und Reihenfolge kombinieren. Für jedes Feld können Attribute zur Darstellung des Inhaltes und zur Breite angegeben werden. Weitere Informationen hierzu finden Sie in den Kapiteln Geometrie-Management und Schriftformatierungen und Farben.

Folgende Stile können als Wert des 'style' Attributes der Elemente 'alarminfo', 'text' und 'spacer' verwendet werden:

Style Erläuterung

alarm_top_priority Zeige Feld im Stil der höchsten Priorität der anstehenden Alarme an. (kleinere Zahl entspricht höherer Priorität)

alarm_top_priority_ack Zeige Feld im Stil der höchsten Priorität der anstehenden, nicht quittierten, quittierpflichtigen Alarme an.

Abbildung 56: Prioritätsbedingtes Zuweisen von Stil-Attributen in der Statuszeile

Diese Stil-Schlüsselwörter referenzieren keinen eigenen Stil, sondern nehmen Bezug auf den Stil 'alarm_priority' von alarmlayout/alarmview/styles/data/, durch den eine Zuordnung von Priorität zu Farbe bereits definiert wurde.

Die zuvor genannten Schlüsselwörter wurden von B&R exemplarisch in die alarmLayout-Konfigurationen 'al_1alarm_2lines_001.xml' und 'al_1alarm_2lines_049.xml' implementiert.

3.4.3.7 Alarminformation (alarminfo)

Mit dem Element alarminfo in der Layout-Konfigurationsdatei wird ein Feld eingefügt, das für die Statuszeile aktuelle Informationen des Systems und für die Zeilen der Alarmereignisse aktuelle Informationen des Alarms anzeigt. Als Inhalt der alarminfo- Elemente in der XML-Datei sind nur die in den Tabellen aufgeführten Schlüsselwörter zulässig.


Abbildung 57: Struktur von alarminfo im kxmleditor

(Siehe DTD-Datei, alarminfo) Konfiguration einer Zeile des Alarmereignisses: Folgende Schlüsselwörter stehen Ihnen dabei innerhalb eines Elements alarminfo zur Verfügung:

Die angezeigten Informationen gelten immer für den momentan im AlarmMonitor aktivierten Filter

Schlüsselwort (Zeile des Alarmereignisses)

Erläuterung

ACKN ["QUITTIERBERECHTIGT" |"IST QUITTIERT" | "NICHT QUITTIERBAR" |"NICHT QUITTIERBERECHTIGT"]

ACKNSTATE Typ des Alarms (MODE in Alarmkonfiguration)["QP" | "QTP" | " " ] (QP= quittierpflichtig; QTP= quittiertextpflichtig)

ALARMTEXT Meldungstexttext (Wert von TEXT aus der Alarmkonfiguration)

ALIAS Alias (Wert aus der Alarmkonfiguration)

GROUP Gruppe des Alarms (Wert aus der Alarmkonfiguration)

GROUPDESC Beschreibung der Alarmgruppe

LOCKED Zeigt mit einem Icon an, ob ein Alarm gesperrt ist. Für aktuell gesperrte Alarme wird das informative Icon eingeblendet; für nicht gesperrte Alarme wird es ausgeblendet.

MULTI Anzahl des nicht quittierten Auftretens des Alarms ("-" wenn Alarm nicht quittierpflichtig)

NAME Name der auslösenden PV

NUMBER Laufende Nummer des aktuellen Alarms im AlarmServer

PICAVAIL Zeigt mit einem Icon an, ob ein "Bild zum Alarm" für diesen Alarm konfiguriert wurde. Gegebenenfalls kann über das Icon ein Sprung in die entsprechende Prozessgrafik erfolgen.

Icon, wenn " Prozessgrafik zum Alarm " vorhanden ist:

PRIORITY Priorität des Alarms (Wert PRIO aus der Alarmkonfiguration)

SYSTEMNAME Name des APROL-Systems, von dem der Alarm kommt. Dies ist entweder der Name aus der lokalen Runtime-Datenbank (bei Verwendung von 'inst_ref') oder der Wert des Attributs 'name' des Elements 'system' in der Monitor-Konfigurationsdatei.


Schlüsselwort (Zeile des Alarmereignisses)

Erläuterung

TEXTAVAIL Zeigt mit einem Icon an, ob ein Interventionstext für diesen Alarm konfiguriert wurde. Gegebenenfalls kann über das Icon der Interventionstext als Pop-up geöffnet werden.

Icon, wenn ein Interventionstext vorhanden ist:

Icon für gesperrte Alarme:

TIMEACKN Quittier-Zeit oder ["NICHT QUITTIERT"]

TIMECOME Kommen-Zeit des Alarms

TIMEGO Gehen-Zeit des Alarms oder ["ANSTEHEND"]

Hinweise zur Alarmkonfiguration finden Sie im Handbuch "B2 Projekt Engineering", Kapitel Alarmbausteine im CFC.

Konfiguration der Statuszeile Die folgenden Schlüsselwörter sind für alarminfo in der Konfiguration der Statuszeile vorgesehen. Sie können jedoch auch in der Zeile des Alarmereignisses verwendet werden:

Schlüsselwort Erläuterung

FILTER Kurze Beschreibung der wichtigsten Filtereinstellungen

MONITORIOSYSLIST Durch Kommata getrennte Liste der Hostnamen mit Angabe des Iosys-Ports z.B.: <Name>:<Port>; <Name>:<Port> Dies sind entweder der Name aus der lokalen Runtime-Datenbank (Verwendung von 'inst_ref') oder die Werte des Attributs 'iosys' des Elements 'system' in der Monitor-Konfigurationsdatei.

MONITORNAME Name des Monitors

Sprachabhängigkeit des Attributs 'name<Language-Code>' des Elementes 'alarmmonitor' aus der Layout-Konfigurationsdatei oder des Attributs 'id' des Elements 'alarmview' aus der Layout-Konfigurationsdatei

MONITORSYSNAMELIST Liste mit den Namen der APROL-Systeme

Dies sind entweder der Name aus der lokalen Runtime-Datenbank (Verwendung von 'inst_ref') oder die Werte des Attributs 'name' des Elements 'system' in der Monitor-Konfigurationsdatei.

NRLOCKED Anzahl der gesperrten Alarme

NRMSG Anzahl der anstehenden Alarme


Schlüsselwort Erläuterung

NRQMSG Anzahl der quittierpflichtigen Alarme

TOPPRIO Höchste Priorität aller anstehenden Alarme (kleinere Zahl entspricht höherer Priorität)

TOPPRIOACK Höchste Priorität unter den anstehenden, nicht quittierten Alarmen

Abbildung 58: Für die Statuszeile vorgesehene Schlüsselwörter können auch für das Alarmereignis verwendet werden.

3.4.3.8 Text (text) Sie können Felder mit statischem Text einfügen, beispielsweise um den Alarminformationen Erläuterungen voranzustellen. Als Inhalt der text- Elemente in der Layout-Konfigurationsdatei müssen Zeichendaten (Text oder Zahlen) angegeben werden.

Abbildung 59: Struktur von text im kxmleditor

(Siehe DTD-Datei, text)

3.4.3.9 Trennfelder (spacer) Die Übersichtlichkeit der dargestellten Informationen im AlarmMonitor können Sie durch den Einsatz von Trennfeldern in der Layout-Konfigurationsdatei erheblich erhöhen. Um Abstände zwischen Informations- und Textfelder zu definieren, verwenden Sie bitte das Element spacer. Mit den entsprechenden Attributen können Farbe und Breite der einzelnen Felder konfiguriert werden. Detailinformationen hierzu entnehmen Sie bitte den Kapiteln Geometrie-Management sowie Schriftformatierungen und Farben.

(Siehe auch DTD-Datei, spacer)

3.4.4 Schriftformatierungen und Farben Durch Layoutkonfigurationen bezüglich Schrift und Farbe helfen Sie dem Operator, die verschiedenen Alarm- und Systeminformationen schnell zu unterscheiden und auszuwerten. Die


Konfiguration können Sie außerdem auf Umgebungsbedingungen abstimmen, die das Arbeiten mit dem AlarmMonitor beeinflussen (beispielsweise Lichtverhältnisse oder Umgebungsgeräusche). Eine schnelle und übersichtliche Konfiguration wird Ihnen durch folgende Mechanismen ermöglicht:

Vordefinieren bestimmter Formatierungen, auf die referenziert werden kann

Globales Definieren bestimmter Formatierungen für untergeordnete Elemente

Attributwerte für Farben können im Hexadezimalcode des RGB-Farbwerts oder durch Angaben eines standardisierten Farbnamens (zum Beispiel VGA-Standards oder CSS-Spezifikationen des W3C) eingegeben werden. Eine Liste der erlaubten Farbnamen finden Sie in der Datei usr/share/X11/rgb.txt.

3.4.4.1 Hervorhebung der Mauszeiger-Position Durch eine einfache Modifizierung der Layout-Konfigurationsdatei können Sie dem Operator eine optimale Bedienung des AlarmMonitors ermöglichen und dabei spezielle Lichtverhältnisse berücksichtigen. Mit dem Attribut mouseover_color können Sie definieren, in welcher Farbe der Rahmen eines Alarmereignisses dargestellt wird, solange sich der Mauszeiger über diesem Alarmereignis befindet.

Für die Alarmzeile (Element linelayout) und die Alarmliste (Element listlayout) sind dabei differenzierte Konfigurationen möglich.

3.4.4.2 Schriftformatierungen (fontlist, font) Die Verwendung von Schriftformatierungen in der Layout-Konfigurationsdatei ermöglicht Ihnen die beschleunigte Konfiguration eines einheitlichen Erscheinungsbildes. Für die Prozessführung relevante Daten des Alarm-Systems können dabei optisch hervorgehoben werden.

Unter dem Element fontlist können Sie Schriftformatierungen (Element font) mit unterschiedlichen Eigenschaften definieren. Mindestens ein Element font muss definiert werden; bei Bedarf können es auch mehr sein. An anderen Stellen können Attributen font die Werte der hier definierten Attribute alias zugewiesen werden. Hierbei werden die Eigenschaften wie Größe, Schriftart, etc. entsprechend der Definition übernommen und angezeigt. Der Vorteil dieser Vorgehensweise liegt darin, dass die Änderung von Attributwerten einer Schriftformatierung sich direkt an allen Stellen auswirkt, an denen diese referenziert wird. Eine aufwendige und fehleranfällige Suchprozedur in der gesamten XML-Datei entfällt somit.

Des Weiteren können Sie durch Modifizieren des Elements font beschleunigt sprachenspezifische Konfigurationen erstellen.


Abbildung 60: Struktur von fontlist im kxmleditor

Beispiele für Definition von Schriften in der XML-Datei: <fontlist> <font size="10" family="Adobe Helvetica" alias="helvetica10" /> <font size="12" family="Adobe Helvetica" alias="helvetica12i" italic="1" /> <font size="16" family="Adobe Helvetica" bold="1" alias="helvetica16bi" italic="1" /> </fontlist>

Beispiel für Referenzierung auf Schriften in der XML-Datei: <inactive_alarm> <unconfirmed foregroundcolor="black" font="helvetica10" /> <text_unconfirmed foregroundcolor="black" font="helvetica16bi" /> </inactive_alarm>

Hinweis: Attributwerte für Schriftarten (family) müssen mit einem standardisierten Schriftnamen (zum Beispiel Courier) angegeben werden. Die Angabe der Schriftgröße (size) erfolgt in Punkten.

Im DisplayCenter sollten Sie über das Kontextmenü "Fontcheck" prüfen, ob alle angegebenen Schriftarten zur Verfügung stehen. Nicht vorhandene Schriftarten werden automatisch ersetzt.

Abbildung 61: Meldung zur Korrektur von Schriftarten

(Siehe auch DTD-Datei, fontlist, font)

3.4.4.3 Darstellungsstile (styles)

Mit dem Element styles in der Layout-Konfigurationsdatei erstellen Sie Konfigurationen zur Darstellung von Systemmeldungen sowie zur zustands- und prioritätsabhängigen Darstellung von Alarmereignissen.


Das Element styles hat an sich keine eigenen Attribute. Es gliedert sich in die zwei Unterelemente system und data.

Abbildung 62: Struktur von alarmlayout im kxmleditor

(Siehe DTD-Datei, styles) Für die Elemente linelayout, listlayout, line, alarminfo, spacer und text kann mit dem Attribut style auf einen im Element styles/data definierten Darstellungsstil referenziert werden (alarm_state oder alarm_priority). Das entsprechende Feld wird dann in Abhängigkeit vom Alarmzustand oder der Priorität veränderlich dargestellt. Individuelle Veränderungen bezüglich Schrift und Farben können Sie in jedem Element mit den Attributen font, backgroundcolor und foregroundcolor einzeln definieren.

3.4.4.4 Darstellung von Systemmeldungen (system) Die Darstellung bestimmter Systemmeldungen können Sie rasch in der Layout-Konfigurationsdatei so konfigurieren, dass der Operator veränderte Systemzustände schnell und eindeutig erkennt (z. B. den Verlust der Verbindung zum APROL-System). Das Element system legt die Darstellung von Systemmeldungen fest. Es muss genau einmal in jedem Element styles aufgeführt werden und hat an sich keine eigenen Attribute. Es gliedert sich in die zwei Unterelemente blinking und error.

Abbildung 63: Struktur von system im kxmleditor

(Siehe DTD-Datei, system) Blinken bei anstehenden Alarmen (blinking) Die Darstellung anstehender Alarme können Sie individuell an Umgebungseinflüsse wie Lichtverhältnisse oder Umgebungsgeräusche anpassen. Dadurch unterstützen Sie den Operator zusätzlich darin, aktuelle Anlagenzustände schnell zu erfassen. Durch die Attribute des Elements blinking kann eingestellt werden, dass beim Auftreten von Alarmen der Rahmen der Alarmzeile bzw. die Statuszeile der Alarmliste in den angegebenen Farben blinkt. Dies kann mit dem Button „Warnton quittieren“ im DisplayCenter ausgeschaltet werden.

(Siehe auch DTD-Datei, blinking)


Darstellung unterschiedlicher Fehlermeldungen (error) Bestimmte Systemzustände beeinflussen sowohl die Anzeige der Prozessgrafik als auch die Darstellung der Alarmereignisse. Die Ursache kann beispielsweise der Verbindungsverlust zum Iosys aufgrund eines Downloads oder einer Redundanzumschaltung sein. Auch wenn der AlarmServer nicht gestartet ist oder die Verbindung zum APROL-System unterbrochen ist, sowie während der Synchronisation mit dem APROL-System nach dem Starten des DisplayCenters liegen besondere Systemzustände vor. Um dem Operator bestimmte Systemzustände eindeutig zu signalisieren, ist es Ihnen möglich, folgende Zustände durch Schrift- und Farbformatierungen differenziert darzustellen:

fehlende Verbindung zum Iosys

fehlende Verbindung zum APROL-System

fehlgeschlagene Synchronisation mit dem AlarmServer Das Element error gliedert sich folglich in drei Unterelemente für die unterschiedlichen Systemfehler: noiosysconnection

noalarmserverconnection

noalarmserversyschronisation

Mit den Attributen des Elements error können für alle untergeordneten Fehlermeldungen dieselbe Formatierung bezüglich eines oder mehrerer Attribute (Vordergrundfarbe/Schriftfarbe, Hintergrundfarbe, Schrift) vorgeben werden. Es ist jedoch auch möglich den unterschiedlichen Fehlermeldungen jeweils einzeln einen Attributwert zuweisen (zum Beispiel gleiche Schrift für alle Fehlermeldung, aber unterschiedliche Farben).

Abbildung 64: Anzeige der Systemfehlermeldung noiosysconnection


Abbildung 65: Anzeige der Systemfehlermeldung noalarmserverconnection

Abbildung 66: Anzeige der Systemfehlermeldung noalarmserversyschronisation

(Siehe auch DTD-Datei, error)

3.4.4.5 Alarmdatenabhängige Darstellung (data) Schnell können Sie den AlarmMonitor in der Layout-Konfigurationsdatei so konfigurieren, dass die Prioritäten und die Zustände der Alarme vom Operator sofort erfasst und beurteilt werden können. Die zustands- und prioritätsabhängige Darstellung ist bezüglich

Vordergrundfarbe/Schriftfarbe

Hintergrundfarbe

Schrift

konfigurierbar. Das Element data muss genau einmal in der XML-Datei aufgeführt werden und hat an sich keine eigenen Attribute. Es gliedert sich in die zwei Unterelemente alarm_state und alarm_priority. Diese beiden Darstellungsstile können an anderen Stellen durch Referenzieren im Attribut style der gesamten Alarmzeile (linelayout), der gesamten Alarmliste (listlayout), einzelnen Zeilen von Alarmereignissen (line ) und einzelnen Feldern (alarminfo, text, spacer) zugewiesen werden. Die Darstellung der betreffenden Elemente erfolgt dann in Abhängigkeit vom Alarmzustand oder der Priorität. Werden sowohl Style- als auch Farb- oder Schriftangaben für


ein Element gleichzeitig vorgenommen, so sind die lokalen Farb- bzw. Schriftangaben vorrangig gültig. Durch Modifizieren der Darstellungsstile können Sie zeitsparend alle Elemente, die auf diese Stile referenzieren, anpassen.

Abbildung 67: Struktur von data im kxmleditor

(Siehe DTD-Datei, data)

Zustandsabhängige Darstellung (alarm_state) Möchten Sie die visuelle Darstellung der Alarmereignisse mit dem Zustand der Alarme verknüpfen, modifizieren Sie bitte das Element alarm_state. Dieses Element unterteilt sich in zwei Unterelemente und hat an sich keine Attribute. Es werden anstehende (active_alarm) und nicht anstehende (inactive_alarm) Alarme unterschieden, die wiederum in weitere Zustände unterteilt sind. Ein anstehender Alarm kann fünf verschiedene Zustände annehmen. Nicht quittierpflichtige Alarme werden nicht mehr angezeigt, wenn sie nicht mehr anstehen. Daher kann ein nicht anstehender Alarm nur zwei verschiedene Zustände annehmen.

Abbildung 68: Struktur von alarm_state im kxmleditor

Folgende Tabelle erläutert die Elemente:

Elemente Alarmzustand

standard anstehend, nicht quittierpflichtig

confirmed anstehend, quittiert

unconfirmed nicht quittiert

text_confirmed anstehend, mit Text quittiert

text_unconfirmed quittiertextpflichtig, nicht quittiert

Über die Elemente active_alarm und inactive_alarm können Sie für alle untergeordneten Alarmzustände dieselbe Formatierung bezüglich eines oder mehrerer Attribute vorgeben. Es können jedoch auch den unterschiedlichen Zuständen jeweils einzeln Attributwerte zugewiesen werden (zum Beispiel gleiche Schrift für alle Alarmzustände, aber unterschiedliche Farben).

(Siehe DTD-Datei, alarm_state, active_alarm, inactive_alarm)


Abbildung 69: Alarmzustand durch Farbkodierung einzelner Felder dargestellt

Abbildung 70: Alarmzustand durch Schriftfarbe und farbigen Balken dargestellt

Abbildung 71: Alarmzustand durch Hintergrundfarbe der Alarmeereignisse dargestellt

Beispiel aus XML-Datei: <alarm_state> <active_alarm> <standard backgroundcolor="white" foregroundcolor="black" font="helvetica12b" /> <confirmed backgroundcolor="orange" /> <unconfirmed backgroundcolor="red" /> <text_confirmed backgroundcolor="orange" /> <text_unconfirmed backgroundcolor="red" /> </active_alarm> <inactive_alarm> <unconfirmed backgroundcolor="yellow" /> <text_unconfirmed backgroundcolor="yellow" /> </inactive_alarm> </alarm_state>

Beispiel für die Referenzierung auf einen Darstellungsstil: <line backgroundcolor="white" foregroundcolor="black" font="helvetica12"> <spacer backgroundcolor="white" maximum_width="2" minimum_width="2"/> <spacer maximum_width="15" minimum_width="15" style="alarm_state" /> <spacer backgroundcolor="white" maximum_width="2" minimum_width="2"/> </line>...

Prioritätsabhängige Darstellung (alarm_priority): Eine prioritätsabhängige Darstellung der Alarmereignisse konfigurieren Sie mit dem Element alarm_priority. Dieses kann beliebig viele Elemente range enthalten, es muss jedoch mindestens ein Unterelement angegeben werden.

Es besteht die Möglichkeit, entweder durch die Attribute des Elements alarm_priority für alle Prioritäten dieselbe Formatierung bezüglich eines oder mehrerer Attribute vorzugeben (Vordergrundfarbe/ Schriftfarbe, Hintergrundfarbe, Schrift). Es können jedoch auch unterschiedlichen Prioritäten oder Prioritätsbereichen jeweils einzeln Attributwerte zugewiesen werden (zum Beispiel gleiche Schrift für alle Prioritäten, aber unterschiedliche Farben).


Bitte legen Sie für jeden Prioritätsbereich, der definiert werden soll, ein Element range an. Durch das Attribut value können Sie jeweils den entsprechenden Wert (zum Beispiel value="1") oder Wertebereich (zum Beispiel value="4-25", value="3-", value="-3") festlegen.

Abbildung 72: Struktur von alarm_priority im kxmleditor

(Siehe DTD-Datei, alarm_priority, range) Beispiele aus XML-Datei: <alarm_priority font="helvetica12b" foregroundcolor="black"> <range backgroundcolor="red" value="0" /> <range backgroundcolor="orange" value="1" /> <range backgroundcolor="yellow" value="2" /> </alarm_priority>

Abbildung 73: Farbliche Darstellung der Alarmpriorität

Bitte beachten Sie, dass eine niedrigere Zahl eine höhere Priorität darstellt.

Anwendungsbeispiel: Im AlarmMonitor soll der zu einem Alarmereignis gehörende Eintrag vollständig mit der für die Priorität des Alarms vorgesehenen Hintergrundfarbe dargestellt werden. Umsetzung: Definieren Sie zunächst mit dem Element 'alarm_priority' die gewünschte Hintergrundfarbe (backroundcolour) in Abhängigkeit der Alarmpriorität. Setzen Sie anschließend im Element 'listlayout' oder 'linelayout' das Attribut 'style' auf den Wert 'alarm_priority'. Setzten Sie in den untergeordneten Elementen keine weiteren Attribute für die Hintergrundfarbe. Dadurch wirken sich die Farbgebungen auf alle im jeweiligen Layout definierten kompletten Zeilen aus.

Abbildung 74: Definition für 'alarm_priority'


Abbildung 75: Übernahme des 'style' von 'alarm_priority' im 'List_layout'

Abbildung 76: Einfärben des Alarm-Ereignisses mit der Farbe der Alarmpriorität

3.4.4.6 Festes Zuweisen von Schriftformatierungen und Farben Das Referenzieren auf vordefinierte Formatierungen und Stile in der Layout-Konfigurationsdatei sowie das globale Definieren von Schriftformatierungen und Farben ermöglicht es Ihnen, schnell und komfortabel Konfigurationen zu erstellen. Darüber hinaus haben Sie die Möglichkeit, diese Formatierungen folgenden Elementen fest zuzuweisen:

linelayout, listlayout, statusline, line, alarminfo, text und spacer. (Da das Element spacer keinen Inhalt hat, entfallen für dieses die Attribute font, align und foregroundcolor).

3.5 Die Layout- und Monitor-DTD-Dateien Die von B&R definierten DTD-Dateien sollen sicherzustellen, dass die von Ihnen erstellten XML-Konfigurationen syntaktisch korrekt sind (DTD - Document Type Definition). In der DTD-Datei


werden Regeln für den Aufbau der XML-Datei festgelegt. Wohlgeformte XML-Dateien werden somit zusätzlich auf eine bestimmte Struktur und bestimmte Inhalte beschränkt. Die DTD-Datei regelt unter anderen nachfolgenden Angaben:

welche Elemente in der XML-Datei zwingend enthalten sein müssen oder optional aufgeführt werden können

in welcher Reihenfolge und Schachtelungs-Struktur die Elemente anzuordnen sind

welche Attribute notwendig oder erlaubt sind und welche Attributwerte angenommen werden können

gegebenenfalls Standardwerte für Attribute

Jede XML-Datei, die zur Konfiguration des AlarmMonitors dienen soll, muss dieser DTD-Datei zugewiesen sein. (Dies ist sichergestellt, wenn Sie die mit APROL mitgelieferten Standard-Konfigurationen verwenden bzw. Kopien dieser Dateien im kxmleditor bezüglich Elemente und Attribute modifizieren).

Die für das Erscheinungsbild zuständige Datei 'layout.dtd' und die für das Verbinden der APROL-Systeme zuständige Datei 'monitor.dtd' sind im Verzeichnis /opt/aprol/cnf/DisplayCenter/ abgelegt. Beim Starten eines DisplayCenters findet eine Validierung anhand der zugewiesenen DTD-Datei statt, um die Gültigkeit der Konfiguration zu prüfen. Ist die Gültigkeit der XML-Datei nicht gegeben, so wird eine Fehlermeldung angezeigt und die Visualisierung (das DisplayCenter) sicherheitshalber nicht gestartet.

Abbildung 77: Meldung beim Verwenden einer fehlerhaften Konfigurationsdatei

Ist man mit der Syntax von DTD-Dateien vertraut, können in einer DTD-Datei die Regeln für die Konfigurationsdateien eingesehen werden.

Es dürfen jedoch in keinem Fall Änderungen an der DTD-Datei vorgenommen werden. Änderungen an der Konfiguration dürfen ausschließlich mittels der XML-Dateien durchgeführt werden.

Zum Aufbau der DTD-Datei siehe Kapitel Inhalt der DTD-Datei.


Bereits im Engineering-System haben Sie die Möglichkeit, eine XML-Konfigurationsdatei auf Basis der DTD-Datei layout.dtd zu überprüfen. Führen Sie dazu bitte auf Kommandozeilen-Ebene den Befehl xmllint <XML-Dateiname> --valid --noout

in dem Verzeichnis aus, in dem sich die zu überprüfende XML-Datei befindet. Daraufhin werden fehlerhafte Zeilen der XML-Datei mit der Spezifizierung des betroffenen Attributs / Wertes angezeigt.

3.5.1 Kurzinformation zur Anzahl und Reihenfolge der Elemente

Die folgenden Grundinformationen zum Aufbau einer DTD-Datei gilt für alle in APROL verwendeten DTDs. Bei der Definition eines Elements (Oberelement) in der DTD-Datei wird aufgeführt, welche Unterelemente Sie in welcher Anzahl und Reihenfolge in der XML-Datei eintragen müssen oder können. Eine Elementdefinition ist nach folgendem Schema aufgebaut: <!ELEMENT nameOberelement (element1, element2?)>

In der Tabelle sind andere mögliche Definitionen aufgeführt und erläutert.

DTD Bedeutung in XML

(element) Element muss genau einmal vorkommen

(element+) Element muss mindestens einmal oder öfter vorkommen

(element?) Element kann keinmal oder einmal vorkommen

(element*) Element kann keinmal oder so oft wie nötig vorkommen

(element1, element2) fest vorgeschriebene Reihenfolge

(element1| element2)* Elemente beider Typen können in beliebig Anzahl und in beliebiger Reihenfolge vorkommen

EMPTY Oberelement hat keinen Inhalt

#PCDATA Oberelement hat nur Textinhalt

3.5.2 Kurzinformation zu Attributen Bei der Definition von Attributen und Attributwerten eines Elements in der DTD-Datei wird aufgeführt, welche Attribute in der XML-Datei zwingend oder optional anzugeben sind. Zusätzlich wird angegeben, aus welchem Wertebereich die Attributwerte zu wählen sind. Ist CDATA als Wertebereich angegeben, so können Zeichendaten wie Text, Zahlen oder Sonderzeichen verwendet werden. Sind Optionen wie zum Beispiel (option1 | option2) vorgegeben, so darf ein Attributwert nur aus diesen Werten gewählt werden. Im Folgenden ist ein Beispiel für eine Attributdefinition gegeben. In der Tabelle sind andere mögliche Definitionen aufgeführt und erläutert.


Beispiel: <!ATTLIST elementName attribut1 CDATA #IMPLIED attribut2 (1 | 2) #IMPLIED >

DTD Bedeutung in XML

CDATA #REQUIRED oder (option1 | option2) #REQUIRED

Attribut muss vorkommen, Angabe eines nicht vorher festgelegten Wertes bzw. eines Wertes aus den Optionen ist erforderlich

CDATA #IMPLIED oder (option1 | option2) #IMPLIED

Attribut kann bei Bedarf weggelassen werden, es besitzt keinen Standardwert

CDATA "standardwert" oder (option1 | option2) "standardwert"

Attribut wird auf den Standardwert gesetzt, kann mit einem nicht vorher festgelegten Wert bzw. einem Wert aus den Optionen überschrieben werden

3.5.3 Inhalt der Monitor-DTD-Datei

Nachfolgend wird der Aufbau der DTD-Datei 'monitor.dtd' dargestellt:

<?xml version="1.0" encoding="ISO-8859-15"?> <!ELEMENT alarmmonitor_cnf ( alarmmonitor+ )> <!ELEMENT alarmmonitor ( system+ ) > <!ATTLIST alarmmonitor alarmview_id CDATA #REQUIRED name001 CDATA #IMPLIED name007 CDATA #IMPLIED name031 CDATA #IMPLIED name033 CDATA #IMPLIED name034 CDATA #IMPLIED name036 CDATA #IMPLIED name039 CDATA #IMPLIED name040 CDATA #IMPLIED name048 CDATA #IMPLIED name049 CDATA #IMPLIED name086 CDATA #IMPLIED name420 CDATA #IMPLIED name421 CDATA #IMPLIED > <!ELEMENT system EMPTY> <!ATTLIST system iosys CDATA #IMPLIED al_server_selfid CDATA #IMPLIED name CDATA #IMPLIED inst CDATA #IMPLIED inst_ref CDATA #IMPLIED desc001 CDATA #IMPLIED desc007 CDATA #IMPLIED desc031 CDATA #IMPLIED


desc033 CDATA #IMPLIED desc034 CDATA #IMPLIED desc036 CDATA #IMPLIED desc039 CDATA #IMPLIED desc040 CDATA #IMPLIED desc048 CDATA #IMPLIED desc049 CDATA #IMPLIED desc086 CDATA #IMPLIED desc420 CDATA #IMPLIED desc421 CDATA #IMPLIED active (true|false|TRUE|FALSE|1|0) "true" >

3.5.4 Inhalt der Layout-DTD-Datei

Folgendes zeigt den Aufbau der DTD-Datei 'layout.dtd':

<?xml version="1.0" encoding="ISO-8859-15"?> <!ELEMENT alarmlayout ( (fontlist+, styles?, alarmview+) )> <!ELEMENT fontlist ( font+ )> <!ELEMENT font EMPTY> <!ATTLIST font alias CDATA #REQUIRED family CDATA #REQUIRED size CDATA #REQUIRED italic (true|false|TRUE|FALSE|1|0) "false" bold (true|false|TRUE|FALSE|1|0) "false" underline (true|false|TRUE|FALSE|1|0) "false" strike_out (true|false|TRUE|FALSE|1|0) "false" > <!ELEMENT alarmview ( styles?, linelayout, listlayout )> <!ATTLIST alarmview location (top|bottom|left|right|TOP|BOTTOM|LEFT|RIGHT) "top" show_milliseconds (true|false|TRUE|FALSE|1|0) "true" activate_alarmbell (true|false|TRUE|FALSE|1|0) "true" sorting (time|priority|TIME|PRIORITY) "TIME" use_splitter (true|false|TRUE|FALSE|1|0) "true" id CDATA #IMPLIED iosys CDATA #IMPLIED host_alias CDATA #IMPLIED reconnect (true|false|TRUE|FALSE|1|0) "true" >    <!ELEMENT styles ( system, data )> <!ELEMENT system ( blinking?, error? )> <!ELEMENT blinking EMPTY> <!ATTLIST blinking backgroundcolor CDATA #REQUIRED foregroundcolor CDATA #REQUIRED > <!ELEMENT error ( noiosysconnection?, noalarmserverconnection?, noalarmserversynchronisation? )> <!ATTLIST error font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED > <!ELEMENT noiosysconnection EMPTY>


<!ATTLIST noiosysconnection font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED > <!ELEMENT noalarmserverconnection EMPTY> <!ATTLIST noalarmserverconnection font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED > <!ELEMENT noalarmserversynchronisation EMPTY> <!ATTLIST noalarmserversynchronisation font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED > <!ELEMENT data ( alarm_state?, alarm_priority? )> <!ELEMENT alarm_state ( active_alarm?, inactive_alarm? )> <!ELEMENT active_alarm ( standard?, confirmed?, unconfirmed?, text_confirmed?, text_unconfirmed? )> <!ATTLIST active_alarm font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED > <!ELEMENT inactive_alarm ( unconfirmed?, text_unconfirmed? )> <!ATTLIST inactive_alarm font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED > <!ELEMENT standard EMPTY> <!ATTLIST standard font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED > <!ELEMENT confirmed EMPTY> <!ATTLIST confirmed font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED > <!ELEMENT unconfirmed EMPTY> <!ATTLIST unconfirmed font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED > <!ELEMENT text_confirmed EMPTY> <!ATTLIST text_confirmed font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED > <!ELEMENT text_unconfirmed EMPTY> <!ATTLIST text_unconfirmed font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED


foregroundcolor CDATA #IMPLIED > <!ELEMENT alarm_priority ( range+ )> <!ATTLIST alarm_priority font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED > <!ELEMENT range EMPTY> <!ATTLIST range value CDATA #REQUIRED font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED > <!ELEMENT linelayout ( buttons, statusline?, line+ )> <!ATTLIST linelayout number_of_alarms CDATA #REQUIRED movable (true|false|TRUE|FALSE|1|0) "false" use_splitter (true|false|TRUE|FALSE|1|0) "true" ignore_alarmfilter (true|false|TRUE|FALSE|1|0) "false" show_milliseconds (true|false|TRUE|FALSE|1|0) "true" show_timezone (true|false|TRUE|FALSE|1|0) "true" style (alarm_state|alarm_priority|ALARM_STATE|ALARM_PRIORITY) #IMPLIED font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED mouseover_color CDATA "yellow" > <!ELEMENT listlayout ( buttons, statusline?, line+ )> <!ATTLIST listlayout number_of_alarms CDATA #REQUIRED unmap_makros (true|false|TRUE|FALSE|1|0) "true" auto_close (true|false|TRUE|FALSE|1|0) "true" movable (true|false|TRUE|FALSE|1|0) "false" use_splitter (true|false|TRUE|FALSE|1|0) "true" ignore_alarmfilter (true|false|TRUE|FALSE|1|0) "false" show_milliseconds (true|false|TRUE|FALSE|1|0) "true" show_timezone (true|false|TRUE|FALSE|1|0) "true" style (alarm_state|alarm_priority|ALARM_STATE|ALARM_PRIORITY) #IMPLIED font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED mouseover_color CDATA "yellow" > <!ELEMENT buttons ( confirm_selected_alarms, confirm_visible_alarms, confirm_all_alarms, confirm_bell, activate_filter, filter_dialog, locking_dialog )> <!ATTLIST buttons orientation (horizontal|vertical|inline|HORIZONTAL|VERTICAL|INLINE) #REQUIRED position (left|right|LEFT|RIGHT) #REQUIRED > <!ELEMENT confirm_selected_alarms EMPTY> <!ATTLIST confirm_selected_alarms enable (true|false|TRUE|FALSE|1|0) #REQUIRED key (true|false|TRUE|FALSE|1|0) #REQUIRED > <!ELEMENT confirm_visible_alarms EMPTY> <!ATTLIST confirm_visible_alarms enable (true|false|TRUE|FALSE|1|0) #REQUIRED key (true|false|TRUE|FALSE|1|0) #REQUIRED > <!ELEMENT confirm_all_alarms EMPTY>


<!ATTLIST confirm_all_alarms enable (true|false|TRUE|FALSE|1|0) #REQUIRED key (true|false|TRUE|FALSE|1|0) #REQUIRED > <!ELEMENT confirm_bell EMPTY> <!ATTLIST confirm_bell enable (true|false|TRUE|FALSE|1|0) #REQUIRED key (true|false|TRUE|FALSE|1|0) #REQUIRED > <!ELEMENT activate_filter EMPTY> <!ATTLIST activate_filter enable (true|false|TRUE|FALSE|1|0) #REQUIRED key (true|false|TRUE|FALSE|1|0) #REQUIRED > <!ELEMENT filter_dialog EMPTY> <!ATTLIST filter_dialog enable (true|false|TRUE|FALSE|1|0) #REQUIRED key (true|false|TRUE|FALSE|1|0) #REQUIRED > <!ELEMENT locking_dialog EMPTY> <!ATTLIST locking_dialog enable (true|false|TRUE|FALSE|1|0) #REQUIRED key (true|false|TRUE|FALSE|1|0) #REQUIRED > <!ELEMENT statusline ( (alarminfo|spacer|text)* )> <!ATTLIST statusline enable (true|false|TRUE|FALSE|1|0) #REQUIRED font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED > <!ELEMENT line ( (alarminfo|spacer|text)* )> <!ATTLIST line style (alarm_state|alarm_priority|ALARM_STATE|ALARM_PRIORITY) #IMPLIED font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED > <!ELEMENT alarminfo ( #PCDATA )> <!ATTLIST alarminfo style (alarm_state|alarm_priority|ALARM_STATE|ALARM_PRIORITY) #IMPLIED align (left|right|center|LEFT|RIGHT|CENTER) "left" font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED minimum_width CDATA #IMPLIED maximum_width CDATA #IMPLIED stretchfactor CDATA #IMPLIED >  !-- Die folgenden Schlüsselworte können innerhalb eines alarminfo Tags verwendet werden-->    


                         <!ELEMENT text ( #PCDATA )> <!ATTLIST text style (alarm_state|alarm_priority|ALARM_STATE|ALARM_PRIORITY) #IMPLIED align (left|right|center|LEFT|RIGHT|CENTER) "left" font CDATA #IMPLIED backgroundcolor CDATA #IMPLIED foregroundcolor CDATA #IMPLIED


minimum_width CDATA #IMPLIED maximum_width CDATA #IMPLIED stretchfactor CDATA #IMPLIED > <!ELEMENT spacer EMPTY> <!ATTLIST spacer style (alarm_state|alarm_priority|ALARM_STATE|ALARM_PRIORITY) #IMPLIED backgroundcolor CDATA #IMPLIED minimum_width CDATA #IMPLIED maximum_width CDATA #IMPLIED stretchfactor CDATA #IMPLIED >

3.6 Neue Funktionalitäten in den APROL-Releases Sie können den AlarmMonitor via XML bedarfsgerecht konfigurieren. Im Rahmen neuerer Releases stehen Ihnen immer wieder erweiterte Funktionalitäten zur Verfügung.

Verwenden Sie statt der von B&R mitgelieferten Standardkonfigurationen eigene XML-Dateien, müssen Sie diese entsprechend anpassen, damit Sie die neuen Funktionalitäten in der Visualisierung auch nutzen können.

Folgende Tabelle gibt Ihnen einen Überblick, in welchem APROL Release der Umfang der Funktionalitäten erweitert wurde:

APROL-Release Neue Funktionalitäten

Pre - R 3.2 neues optionales Attribut show_timezone für die Elemente linelayout und listlayout

Siehe Kapitel Alarminformationen (alarminfo).

neues optionales Attribut mouseover_color für die Elemente linelayout und listlayout

Siehe Kapitel Hervorhebung der Mauszeiger-Position.

neues Pflichtelement filter_dialog für das Element buttons Siehe Kapitel Buttons, Statuszeile und Zeilen der Alarmereignisse.

neues Pflichtelement locking_dialog für das Element buttons Siehe Kapitel Buttons, Statuszeile und Zeilen der Alarmereignisse.

neues Schlüsselwort MULTI für das Element alarminfo Siehe Kapitel Alarminformationen (alarminfo).

entfallene Schlüsselwort ACT und VALUE für das Element alarminfo

R 3.2-02 neues Schlüsselwort LOCKED für das Element alarminfo Siehe Kapitel Alarminformationen (alarminfo).

R 3.4 neues Attribut use_splitter für die Elemente alarmview, linelayout und listlayout

Siehe Kapitel (Variable Feldbreiten).

neues Schlüsselwort GROUPDESC für das Element alarminfo Siehe Kapitel Alarminformationen (alarminfo).


APROL-Release Neue Funktionalitäten

R 3.6 neue Schlüsselwörter TOPPRIO und TOPPPRIOACK für das Element alarmlayout.

neues Schlüsselwort SYSTEMNAME für das Element alarminfo. neues Schlüsselwort MONITORIOSYSLIST, MONITORNAME und MONITORSYSNAMELIST für das Element statusline.

neues Stille alarm_top_priority und alarm_top_priority_ack für die Attribute alarminfo, text und spacer von Element statusline. neues Attribut id für die Elemente alarmview in die Layout-Datei.

neue DisplayCenter-Optionen '-alarmRepack', '-alarmMonitor' und '-showTopOnNewAlarmTimeout'.

Option '-alarmCnf' in '-alarmLayout' umbenannt.

neue Monitor-XML-Dateien zur Konfiguration eingeführt.

3.7 Sprachausgabe für Alarme

Das APROL AlarmSystem bietet über den AlarmMonitor des DisplayCenters die Möglichkeit zur

Sprachausgabe einzelner selektiv gewählter Alarme - via Kontext-Menü auf dem Alarmereignis,

Sprachausgabe aller in der Alarmzeile oder im AlarmMonitor angezeigten Alarme (Kontextmenü) oder

automatischen Sprachausgabe aller neuen Alarme, die in der Alarmzeile oder im AlarmMonitor angezeigt werden.

Für die Verwendung dieser Funktionalität ist die 3rd Party Software Loquendo TTS 7 (einschließlich der zugehörigen Lizenz) notwendig, welche die Text-Informationen in eine synthetische Sprachausgabe wandelt. Unterstützt werden derzeit Sprachausgaben in den Sprachen Deutsch, Englisch und Chinesisch (Mandarin). Die Installation der Loquendo TTS 7 Software erfolgt automatisch im Rahmen der Installation der APROL Systemsoftware.

Die Lizenzierungsdatei 'TTSLicense.txt' muss sich auf dem APROL-Server in dem Verzeichnis /home/aprolsys/APROL/license/LTTS7/ befinden.

Informationen zur Loquendo-Lizenzierung entnehmen Sie bitte dem Kapitel Lizenzierung der Loquendo TTS7 Software zur Sprachausgabe von Alarmen.

3.7.1 Erweiterung der Alarm-Layout-Konfiguration Anhand der Layout-Datei des AlarmMonitors kann konfiguriert werden, wie und mit welchen Informationen der Text zur Sprachausgabe zusammengestellt werden soll. Dabei werden freie Texte und alle in der Alarmzeile verwendbaren Alarminformationen, wie Alarmtext, ALIAS-Text, Priorität, Zeit des Auftretens etc. unterstützt.


Um die Sprachausgabe von Alarmen zu ermöglichen, wurde das XML-Format der Layout-Konfiguration des AlarmMonitors erweitert. Innerhalb des Elements 'alarmview' kann als erstes Unterelement das Element <speech> definiert werden. In der nächsten Strukturebene können die Elemente <statusline> (Statuszeile des AlarmMonitors) und <line> (Ausgabe eines Alarmes) verwendet werden. Für die Elemente <line> und <statusline> wiederum können die Unterelemente <alarminfo> und <text> eingesetzt werden. Das Element <alarminfo> kann die Schlüsselwörter (siehe layout.dtd) für die Alarm-Informationen bzw. für die Status-Informationen erhalten. Die Verwendung der Schlüsselwörter 'PICAVAIL' und 'TEXTAVAIL' ist hier nicht zulässig.

Detail-Informationen entnehmen Sie bitte den Kapiteln Alarminformation (alarminfo) und Text (text).

Wird in der Layout-Konfigurationsdatei für das Element <speech> das Attribut speak_new_alarms=true gesetzt, wird das automatische Vorlesen neuer Alarme beim Start des DisplayCenters aktiviert. Durch Setzen des Attributs enable=true im Element <statusline> wird veranlasst, dass beim automatischen Vorlesen jedes mal nach der Abarbeitung der Liste eine Statusmeldung ausgegeben wird. Der Inhalt dieser Meldung kann entsprechend konfiguriert werden.

Abbildung 78: Element <statusline> in der Layout-Konfiguration des AlarmMonitors


Abbildung 79: Element <line> in der Layout-Datei des AlarmMonitors

B&R stellt Ihnen beispielhafte Konfigurationsdateien 'al_1alarm_2lines_049.xml' und 'al_1alarm_2lines_001.xml' im Verzeichnis /opt/aprol/cnf/DisplayCenter/alarm_layout/ zur Verfügung.

Diese XML-Datei kann als Vorlage verwendet werden. Nach Ablage der modifizierten Datei im Verzeichnis /home/<CC-Account>/ENGIN/cnf/DisplayCenter/alarm_layout/ steht Ihnen diese nach einem Download im Runtime-System im korrespondierenden Verzeichnis zur Verfügung.

3.7.2 Verwendung der Loquendo-Controls Zur Optimierung und individuellen Anpassung der sprachlichen Ausgabe können an beliebiger Stelle des Textes Sprechpausen, Anpassungen der Lautstärke, der Sprechgeschwindigkeit oder der Intonation vorgenommen werden. Hierzu können alle Controls des TTS-Systems in das Textformat zur Alarmausgabe eingefügt werden. Diese Controls sind Steuersequenzen, die aus einem Backslash '\' und einem Schlüsselwort bestehen. Die Steuersequenzen können innerhalb des <text> Elements an beliebiger Stelle platziert werden. Nachfolgend wird beispielhaft die Verwendung eines Controls zur Erzeugung einer Sprechpause sowie für die Änderung der Lautstärke aufgezeigt: Mittlere Sprechpause (120 ms) einfügen:

Syntax für Loquendo-Control Beispiel:



\pause <text>Der Alias des Alarmes ist \pause</text><alarminfo>ALIAS<alarminfo>

Lautstärke um 50 Prozent erhöhen:


\volume+50% <text>Dieser Alarm hat die Priorität \volume=+50%</text> <alarminfo>PRIORITY</alarminfo>

Darüber hinaus können anhand der Loquendo Controls die Stimme und die Sprache gewählt oder Audio-Dateien abgespielt werden.

Eine ausführliche Dokumentation der verfügbaren Controls entnehmen Sie bitte der Dokumentation 'X12- Loquendo User's Guide'.

Optionale Verwendung der phonetischen Sprache (Lautschriftsprache) SAMPA: Um die Aussprache ggf. falsch ausgesprochener Texte zu optimieren, kann innerhalb der Elemente <text>der Layout-Konfigurationsdatei das ASCII-basierte phonetische Alphabet SAMPA (Abkürzung für Speech Assessment Methods Phonetic Alphabet) verwendet werden. Für die Übertragung des geschriebenen Texts in die Lautschriftzeichen können im Internet verfügbare Konverter verwendet werden. In der Konfigurationsdatei 'al_1alarm_2lines_049.xml' ist als Beispiel das deutsche Wort 'Alarme' im phonetischen Alphabet SAMPA eingetragen.

Abbildung 80: Verwendung des phonetischen Alphabets 'SAMPA

3.7.3 Sprachausgabe über den TtsServer Das DisplayCenter schickt die auszugebenden Texte an den TtsServer. Der TtsServer synthetisiert die auszugebenden Texte und gibt diese über das lokale Audio-Device aus.

http://de.wikipedia.org/wiki/ASCII

http://de.wikipedia.org/wiki/Phonetisch

http://de.wikipedia.org/wiki/Alphabet


Das DisplayCenter startet den TtsServer in der Sprache (via Option '-languageCode') in der es selbst gestartet wurde. Daraufhin wird durch den TtsServer in Abhängigkeit dieser Spracheinstellung der Sprecher (Stimme) und die Sprache des Sprechers eingestellt. Zu dieser Sprache müssen auf dem Rechner (i. d. R. die Operator-Station) die zugehörigen Lizenzen vorhanden sein. Zuordnung Ländercode / Sprecher und Sprache: 049 Stimme: Stefan, Sprache: Deutsch 086 Stimme: Lisheng, Sprache: Chinesisch 001 sowie alle anderen Ländercodes Stimme: Simon, Sprache Englisch

Ein Wechsel der Sprache des TtsServers zur Laufzeit ist z. Zt. nicht möglich.

Nachdem die Sprache des APROL-Systems geändert wurde, ist es erforderlich vor dem Neustart des DisplayCenters den TtsServer zu beenden (via Linux-Befehl 'kill').

Der TtsServer läuft immer im Operator-System des DisplayCenters, welches mit der Option '-enableAlarmTts' gestartet wurde, und stellt für dieses die Sprachausgabe auf dem lokalen Audio-Device zur Verfügung. Falls im selben Operator-System weitere DisplayCenter-Instanzen mit der Option '-enableAlarmTts' gestartet wurden, wird die gleiche Instanz des TtsServers zur Sprachausgabe verwendet.

Es wird in diesem Fall keine weitere Instanz des TtsServers gestartet.

Falls der TtsServer keine gültige Lizenz-Datei vorfindet, ist keine Sprachausgabe möglich. Die Überprüfung durch den TtsServer erfolgt in Intervallen von 30 Sekunden.

3.7.4 Interaktive und automatische Sprachausgabe von Alarmen im DisplayCenter

Die interaktive Sprachausgabe von Alarmen kann über das Kontextmenü des AlarmMonitors gestartet werden. Sie haben folgende Möglichkeiten:

Sprachausgabe des Alarms unter dem Mauszeiger,

Sprachausgabe der zuvor selektierten Alarme,

Sprachausgabe aller sichtbaren Alarme d. h. alle in der gegenwärtigen Filtereinstellung im AlarmMonitor sichtbaren Alarme werden vorgelesen. Dies ist abhängig von der Anzahl der momentan dargestellten Zeilen.

Die einmal angestoßene Ausgabe einer Liste von Alarmen kann jederzeit über den Menüpunkt 'Alarme / Anstehende Texte der Sprachausgabe überspringen' (bzw. anhand des zugehörigen Icons der Toolbar) sofort gestoppt werden. Hierbei wird die Queue der vorzulesenden Texte geleert.


Abbildung 81

Überspringe alle anstehenden Texte der Sprachausgabe

Automatische Ausgabe von neuen Alarmen Mit dem Menüpunkt 'Alarme / Neue Alarme vorlesen' (bzw. anhand des zugehörigen Icons der Toolbar) kann - ab dem künftigen APROL R 3.6 separat für jeden konfigurierten AlarmMonitor - das automatische Vorlesen neu hinzu gekommener Alarme veranlasst werden.

Abbildung 82

Neue Alarme vorlesen

Sobald im AlarmMonitor eine neue Liste oder Zeile angezeigt wird, werden die darin enthaltenen neuen Alarme in der aktuell gewählten Sortierung von unten beginnend vorgelesen. Bei einer Sortierung Zeit/Priorität werden die Alarme somit in chronologischer Reihenfolge Folge,

Bei einem Alarm-Schwall kann es möglich sein, dass infolge der begrenzten Zeilenanzahl des AlarmMonitors nicht alle neu eingetretenen Alarme zur Darstellung kommen. In diesem Fall werden die nicht dargestellten Alarme auch nicht vorgelesen. Neue Alarme werden nur in dem Fall sofort vorgelesen, sofern die Liste tatsächlich aktualisiert wird.

Für APROL R 3.6 gilt:

Neu aufgetretene Alarme werden nur sofort vorgelesen, a) wenn die Option '-alarmRepack' verwendet wird und die Anzeige auf der ersten Seite (Top) positioniert ist oder b) wenn die Option '-showTopOnNewAlarmTimeout' mit dem Wert '0' konfiguriert wurde, so dass die Liste sofort aktualisiert wird. Die Sprachausgabe kann daher nicht als einziges Überwachungsinstrument des Anlagenzustandes verwendet werden! Sie dient lediglich dazu, auf irreguläre Zustände aufmerksam zu machen, die eine visuelle Analyse am Monitor erfordern!

Wird in der Layout-Konfigurationsdatei für das Element <speech> das Attribut speak_new_alarms=true gesetzt, wird das automatische Vorlesen beim Start des DisplayCenters aktiviert. Durch Setzen des Attributs enable=true im Element <statusline> wird veranlasst, dass beim automatischen Vorlesen jedes mal nach der Abarbeitung der Liste eine Statusmeldung ausgegeben wird. Der Inhalt dieser Meldung kann entsprechend konfiguriert werden.


Abbildung 83: Menüführung im DisplayCenter zur Sprachausgabe von Alarmen

Ist keine Loquendo-Lizenz vorhanden, wird im DisplayCenter beim Aufruf der Sprachausgabe die folgende Meldung ausgegeben:

Abbildung 84: Meldung im DisplayCenter bei fehlender Loquendo-Lizenz In diesem Fall (keine Lizenz) erfolgt statt der Übergabe des Textes vom DisplayCenter zum TtsServer ein Eintrag in den APROL Systemmeldungen, welcher den zu sprechenden Text enthält.

Abbildung 85: APROL Systemmeldungen ,falls die Sprachausgabe nicht möglich ist (z. B. bei fehlender Loquendo LTTS7-Lizenz)

Falls der TtsServer das Audio-Device zum Lesen nicht öffnen kann, wird ebenfalls eine Warnung in die APROL Systemmeldungen geschrieben.

Interne Fehlermeldungen der LTTS7 Bibliothek in die Datei /home/aprolsys/tmp/LTTS7_error.log geschrieben.

3.7.5 Einschränkungen Die Sprachausgabe erfolgt immer auf dem Audio-Device des Rechners, auf dem das DisplayCenter ausgeführt wird.


Die Zugriffsrechte auf das lokale Audio-Device erhält ausschließlich der zuerst auf diesem Rechner in die grafische Oberfläche (KDE) eingeloggte Linux-Benutzer (APROL-System).

Sind mehrere APROL-Systeme auf diesem Rechner vorhanden, kann es u. U. erforderlich sein, sich aus allen Systemen auszuloggen und sich anschließend in dem Operator-System anzumelden, in dem das DisplayCenter für die Sprachausgabe gestartet werden soll. Aus diesem Grunde ist bei einem via Remote-Zugriff gestarteten DisplayCenter keine Sprachausgabe auf dem entfernten System möglich. Das betrifft folgende Situationen:

via StartManager aus einem anderen APROL-System (z. B. aus dem Engineering-System auf demselben Rechner) gestarteten DisplayCenter,

Start des DisplayCenter via krdc oder VNC

Weitere Einschränkungen sind:

Die Aktivierung der automatischen Sprachausgabe neuer Alarmen in mehreren DisplayCenter-Instanzen in einem APROL-System sollte unterbleiben. Die Reihenfolge der Ausgabe bei zeitgleicher Ausgabe beider Instanzen ist nicht vorhersehbar und wird unter bestimmten Umständen unterbrochen.

Die Aktivierung der automatischen Sprachausgabe neuer Alarme bei der Sortierung der Liste nach Priorität ist nicht möglich. In dieser Darstellung ist die zeitliche Sortierung der dargestellten Liste nicht gegeben, sodass systembedingt eine chronologische Sprachausgabe nicht möglich ist.

Falls die Alarmtexte nicht in der Sprache vorliegen, in der das DisplayCenter gestartet wurde, so werden die Texte von sprachfremden Sprechern gelesen. Dies führt naturgemäß zu unverständlichen Sprachausgaben und kann darüber hinaus bei der Interpretation von numerischen Werten zu falschen Ausgaben führen.


3.7.6 Lizenzierung der Loquendo TTS7 Software zur Sprachausgabe von Alarmen

Die Lizenzierung muss einmalig auf jedem Rechner durchgeführt werden, auf dem im DisplayCenter Sprachausgaben des Alarm-Systems erfolgen sollen.

Die vorgenommene Lizenzierung bleibt nach einem Update der APROL Systemsoftware erhalten. Bevor ein bereits lizenzierter Linux-Servers neu aufgesetzt wird (Linux-Betriebssystem), muss die Lizenzierungsdatei zuvor gesichert werden.

Informationen zu Loquendo TTS7 Software, zur Lizenzierung sowie den Lizenzierungsbedingungen finden Sie in der APROL-Systemumgebung unter: 1.KDE-Menü 'Werkzeuge / LoquendoLicenseManager (Lizenzierung Sprachausgabe) -->Loquendo Tool zur Lizenzierung Die vorliegende Beschreibung wird aufgerufen. 2. CaeManager: Menü 'Hilfe / Lizenz Information' -->Lizenzierungsbedingungen 3. Startseite der APROL-Dokumentation: Handbuch 'X12- Loquendo Users Guide' -->Hinweise zur Verwendung der Loquendo Controls zur Steuerung der Sprachausgabe 4. APROL Dokumentation 'D1 System Handbuch', Kapitel Lizenzierung der Loquendo TTS7 Software zur Lizenzierung von Alarmen --> vorliegende Beschreibung zur Lizenzierung

Gehen Sie zur Lizenzierung wie folgt vor:

Schritt: Beschreibung:

1 Rufen Sie bitte den LoquendoLicenceManager über das KDE-Menü 'Werkzeuge / Lizenzierung Sprachausgabe (LoquendoLicenseManager)' auf. Der LoquendoLicenceManager wird in diesem Fall aus einer Konsole heraus aufgerufen.

2 Tragen Sie bitte den Ihnen bekannten PIK (Product Key) gemäß B&R Lizenz-Unterlagen ein. Tragen Sie bitte ihrem E-Mail-Addresse ein.


Abbildung 86

3 In dem Home-Verzeichnis des APROL-Systems wird daraufhin eine Datei 'LoquendoLicenseRequest.txt' erzeugt, die u. a. rechnerspezifische Informationen in verschlüsselter Form enthält.

4 Übertragen Sie bitte die Datei 'LoquendoLicenseRequest.txt' auf einen Rechner mit Internet-Zugang. Dies kann auch einen Rechner mit Windows Betriebssystem sein.

5 Starten Sie einen Web-Browser und geben Sie die folgende URL ein: http://licensing.nuance.com

6 Betätigen Sie den Link 'Loquendo Licensing'. 7 Tragen Sie auf der folgenden Webseite bitte den Ihnen bekannten Product Key

'PIK' (gemäß B&R Lizenz-Unterlagen) ein und bestätigen Sie den Vorgang via [OK].

8 Wählen Sie bitte auf der folgenden Seite über den Button [Durchsuchen] die Datei 'LoquendoLicenseRequest.txt' im Dateisystem aus. Klicken Sie anschließend auf den Button [Load] und danach auf [Get License].

9 Nach einer kurzen Wartezeit werden auf der folgenden Seite unterhalb des Eintrags 'Your License', die zu lizenzierenden Rechner aufgeführt. Klicken Sie bitte in der Spalte 'Download License' auf den zu dem lizenzierenden Rechner gehörenden Eintrag.

10 Via Download wird hierdurch eine Datei *.sh (Shell-Skript) auf den Rechner übertragen. Diese Datei hat folgende Nomenklatur: <Produkt Key>_<Loquendo Release>_<Hostname>_TTS_Shell.sh Transferieren Sie die runtergeladene Datei auf den Rechner (Operator-Station), für den die Lizenz bestimmt ist.

11 Machen Sie die Datei anhand des folgenden Linux-Befehls ausführbar: chmod +x <Dateiname>

12 Führen Sie bitte anschließend diese Datei als Linux-Superuser 'root' aus.

http://licensing.nuance.com/


13 Anhand des Skripts wird eine Lizenzierungsdatei 'TTSLicense.txt' in dem Verzeichnis /opt/Loquendo/LTTS7/ abgelegt.

14 Kopieren Sie die Lizenzierungsdatei 'TTSLicense.txt' in das Verzeichnis /home/aprolsys/APROL/license/LTTS7/.

15 Die Lizenzierung ist abgeschlossen.

Die Loquendo TTS 7 Software-Lizenzen sind über die Material Nr. AP.ACC-1476 bei B&R zu beziehen.

3.7.7 Komponenten eines TTS-Systems TTS (Text-To-Speech)-Systeme bestehen immer aus zwei Komponenten, nachfolgend NLP und DSP genannt:

NLP (Natural Language Processing): = Konversion von Text in Lautschrift und Prosodie-Beschreibung.

DSP (Digital Speech Processing): Sprach-Engine: = ausgehend vom Output der NLP-Komponente erfolgt die Synthese des Sprachsignals.

Prosodie ist die Gesamtheit spezifischer sprachlicher Eigenschaften wie z. B. Akzent, Intonation oder (Sprech-)Pausen.

http://de.wikipedia.org/wiki/Akzent_%28Aussprache%29

http://de.wikipedia.org/wiki/Intonation_%28Phonetik%29

Offline-Engineering 4-1

4 Offline-Engineering .

4.1 Einführung zum Offline-Engineering

Die Installation eines APROL-Patchs ist nur möglich, wenn kein Offline-Stand ausgecheckt ist. Alle ausgecheckten Projektierungsteile müssen eingecheckt werden. Erst danach kann im Online-Modus die Installation eines APROL Patchs erfolgen!

Das Offline-Engineering unterstützt das örtlich und logisch getrennte Engineering eines Benutzer-Teams im Kontext einer APROL CAE-Datenbank.

Zur Einführung des Offline-Engineerings in APROL führten u.a. folgende Anwendungsfälle:

In einem großen Projekt mit mehreren Benutzern kommt es häufig vor, dass während der Projektierungsphase Projektierungsteile aus dem Gesamtprojekt außerhalb des Engineering-Verbundes von einem Benutzer bearbeitet werden müssen.

Auf der Anlage ist das komplette Engineering mit einem Engineering-System zur stufenweisen Inbetriebnahme mit Korrekturmaßnahmen nötig. Von einem mehrköpfigen Benutzerteam muss das Engineering außerhalb der Anlage erweitert werden, um das Ergebnis dann wieder auf der Anlage zur Verfügung zu haben.

In beiden genannten Fällen wäre es möglich, die gesamte Engineering-Umgebung zu kopieren und in den Kopien und Originalen weiterzuarbeiten. Dieses ist aber mit einem großen Aufwand an Absprache zwischen den Benutzern verbunden. Es würde hierfür ein spezielles Wissen der caedb-Zusammenführung vorausgesetzt werden, die so entstandenen Projektierungsteile wieder zusammen zu führen.

4.2 Lösung

Zur Lösung der oben genannten Thematik wurde das Offline-Engineering in APROL entwickelt. Es gibt den Benutzern die Werkzeuge an die Hand, um ein schnelles und problemfreies örtlich getrenntes Bearbeiten von Projektierungsteilen zu ermöglichen. Dies geschieht in der Online-Umgebung durch ein eindeutiges Verriegeln von Projektierungsteilen, die ausgecheckt in der Offline-Umgebung in Bearbeitung genommen werden sollen. In der Offline-Umgebung, werden nur die Teile zur Bearbeitung freigegeben, die auch ausgecheckt wurden. Beim Arbeiten im Offline-Engineering werden folgende Vorteile geboten:

Das Ein- und Auschecken von Projektierungsteilen ist durch das Rechte-System innerhalb von APROL abgesichert und verhindert das unkontrollierte Veräußern von Projekt-Know-how.


Durch eine Statusanzeige wird angezeigt, ob zurzeit Projektierungsteile in der Online-Umgebung ausgecheckt sind, oder ob ein uneingeschränktes Bearbeiten aller Teile im Original möglich ist.

Es können neue Projektierungsteile sowohl im Online- als auch in der Offline-Umgebung hinzugefügt werden.

Das gesamte CAE-Management (Benutzer-Verwaltung, Zuordnung der Benutzerrechte im Projekt, Operator-Verwaltung) ist in beiden Umgebungen vorhanden.

Das gesamte Projekt steht in beiden Umgebungen zur Verfügung. Online-Umgebung: Ausgecheckte Teile nur lesender Zugriff, sonst auch schreibender Zugriff Offline-Umgebung: Lesender Zugriff auf alle Teile, schreibender Zugriff auf ausgecheckte Teile.

Ausgefeiltes Management in APROL für die Wiedervereinigung beider Umgebungen (Offline und Online).

Abbildung 87: Aufruf 'Offline-Engineering'

4.3 Voraussetzungen für Offline-Engineering

Der Benutzer, der in der Online- und Offline-Umgebung aus- oder eincheckt, muss exklusive im Engineering-System für den Zeitpunkt dieser Aktivität eingeloggt sein.

Der Benutzer muss die Rechte für das Offline-Engineering besitzen: Read (R) = Lesen aus der Datenbank (Auschecken) Write (W) = Schreiben in die Datenbank (Einchecken)

Beide Engineering-Systeme von APROL müssen vom gleichem Release und Build sein.


In der Offline-Umgebung muss ein Engineering-System vorhanden sein. Ist nur ein vorkonfiguriertes Engineering-System (erstellt mit AprolConfig) vorhanden, muss Ihnen das Passwort für rot (der Benutzer root im Engineering) bekannt sein. Damit können Sie in einem vorkonfiguriertem Engineering-System die Offline-Umgebung installieren.

Während des Offline-Engineerings darf kein Update bzw. Upgrade in den zusammengehörenden Offline- und Online-Umgebungen vorgenommen werden!

Im Extremfall ist nach entsprechender Rechtevergabe folgendes Szenario möglich:

Umgebung Änderungen Rechte

Online-Engineering Benutzer A ändert einen CFC. Rechte aus Benutzer-Verwaltung und Projekt.

Online-Engineering Benutzer B verriegelt diesen CFC und checkt ihn aus.

Offline-Engineering R

Offline-Engineering Benutzer C startet das Offline- Engineering.

Offline-Engineering W

Offline-Engineering Benutzer A, B, C und D ändern. Rechte aus Benutzer-Verwaltung und Projekt.

Offline-Engineering Benutzer C beendet das Offline-Engineering.

Offline-Engineering R

Online-Engineering Benutzer D checkt ein. Offline-Engineering W Online-Engineering Benutzer A aktiviert alle Änderungen

und fügt diese dem Projekt zu. Rechte aus Benutzer-Verwaltung und Projekt.


4.4 Struktur Offline- und Online-Engineering Die folgende Abbildung zeigt den prinzipiell den Ablauf des Offline- und Online-Engineerings nach und bei der Verteilung:

Online-Umgebung Offline-Umgebung

1

2

3

4b 4a

5

6

7

Abbildung 88: Workflow beim Offline-Engineering

4.5 Vorbereitung für Offline-Engineering und Auschecken .

4.5.1 Verriegeln der benötigten Projektierungsteile: Das Verriegeln von Projektierungsteilen ist die Grundlage für das Offline-Engineering. Hiermit wird festgelegt, welche Teile des Projektes und der Datenbanken für das Offline-Engineering zur Verfügung gestellt werden. Welcher Benutzer das Verriegeln und Auschecken vornimmt, hat für das folgende Offline-Engineering keine Auswirkung. Es ist nur zu beachten, dass alle von diesem Benutzer verriegelten Teile später aus der Offline-Umgebung ausgecheckt und in die Online-Umgebung wieder eingecheckt werden.


Es können Projektierungsteile, Verzeichnisse und das gesamte CAE-Projekt oder eine gesamte Bibliothek verriegelt werden. Um im Offline-Engineering neue Projektierungsteile anzulegen oder mittels Copy&Paste zu erzeugen, muss das übergeordnete Verzeichnis, in dem diese Projektierungsteile erstellt werden sollen, verriegelt sein. Ist ein Verzeichnis verriegelt und ausgecheckt, kann im Online-Engineering kein neues Projektierungsteil erzeugt werden. Das Verriegeln von Verzeichnissen ist notwendig, damit der Namensraum innerhalb des Verzeichnisses geschützt ist. Beim Verriegeln von Verzeichnissen werden optional (explizite Bestätigung erforderlich) alle darunter liegenden Verzeichnisse und Projektierungsteile rekursiv verriegelt!

4.5.2 Auschecken der benötigten Projektierungsteile: Der Vorgang ist unter dem Menüeintrag 'Datei / Offline-Engineering / Projektierungsteile auschecken' zu starten. Bei diesem Vorgang werden alle vorher verriegelten Projektierungsteile des aktuell eingeloggten Benutzers als ausgecheckt markiert. Dies bedeutet, dass alle ausgecheckte Teile nicht mehr in der Online-Umgebung bearbeitet werden dürfen. Das Offline-Engineering von APROL stellt dies sicher.

Der Mechanismus des Auscheckens für das Offline-Engineering greift auf Elemente des Backup-Mechanismus von APROL zurück. Informationen über das zusätzliche Aufnehmen von Engineering-Komponenten für das Backup entnehmen Sie bitte der APROL Dokumentation "B2 Projekt Engineering".

Versionen, die den Versions-Stand Modified haben, können nicht ausgecheckt werden. Das System erkennt diesen Fall und fragt, ob der Stand Modified aller gefundenen Projektierungsteile versioniert werden soll.

Wird die oben gestellte Frage verneint, wird der Vorgang des Auscheckens aus Sicherheitsgründen abgebrochen!

Bedingungen für die Vorbereitungen Erstellung der Import-Datei zum Offline-Engineering:

Besitz der Rechte zum Offline-Engineering

Verriegeln der Projektierungsteile für das Offline-Engineering

Alle Projektierungsteile für das Offline-Engineering müssen versioniert sein.

Sind alle oben aufgeführten Bedingungen für das Auschecken erfüllt, wird dem Benutzer eine eindeutige Signatur zugeordnet. Mit dieser Signatur wird auch die jetzt erzeugte Offline-Datenbank gekennzeichnet. Somit ist eine eindeutige Verbindung zwischen Online- und Offline-Umgebung hergestellt. Mit Projektierungsteile auschecken wird eine Kopie der caedb erzeugt und mit der zugehörigen Engineering-Umgebung in ein Archiv gepackt. Die so entstandene Datei hat den Namen ENGIN_OFFLINE_<APROL-Release/Build>_<Rechnername>_<APROL-System>_<Benutzer>_<Datum>_<Zeitstempel>.tar

und liegt im Verzeichnis


/home/<CC-Account>/APROL_CAE_OFFLINE

Das Archiv kann nun zum Engineering-System der Offline-Umgebung übertragen werden.

Pro Benutzer kann nur einmal ausgecheckt werden! Es kann mehrfach vom gleichen Online-Engineering ausgecheckt werden!

4.6 Arbeiten in der Online-Umgebung .

4.6.1 Kontinuierliche Weiterarbeit in der Engineering-Umgebung: Das Engineering in der Online-Umgebung kann nun - wie gewohnt - weiter erfolgen. Die einzige Einschränkung ist, dass die ausgecheckte Teile nicht für Änderungen zur Verfügung stehen. Funktionalitäten wie diese sind jederzeit möglich.

Hinzufügen von Projektierungsteilen

Rekompilieren

Tasks generieren

Download

Die direkte Arbeit am Projekt ist nicht eingeschränkt.

4.7 Arbeiten im Offline-Engineering und beenden

4.7.1 Offline-Engineering starten Um mit dem Offline-Engineering zu beginnen, muss auf einem Rechner ein Engineering-System mit dem gleichen Release und Build wie das der Online-Umgebung vorhanden sein. Weiterhin muss der bearbeitende Benutzer das Recht W zum Offline-Engineering besitzen. Ist nur ein vorkonfiguriertes Engineering-System (erstellt mit AprolConfig) vorhanden, muss Ihnen das Passwort für root (der Benutzer root im Engineering) bekannt sein. Damit können Sie in einem vorkonfiguriertem Engineering-System die Offline-Umgebung installieren. Der Vorgang ist unter dem Menüeintrag 'Datei / Offline-Engineering / Start Offline-Engineering' zu starten. Nach Auswahl des Offline-Archivs wird der Exklusivzugriff auf das derzeitige Engineering-System (Offline-Umgebung) geprüft. Da die gesamte aktuelle Engineering-Umgebung durch das Offline-Engineering ersetzt wird, darf zu diesem Zeitpunkt keine andere Anwendung auf dieses Engineering-System zugreifen. Nun wird ein Backup des aktuellen Engineerings erstellt und danach das Offline-Archiv entpackt. Kann dieser Vorgang fehlerfrei beendet werden, wird der


CaeManager neu gestartet und es kann im Projekt - nun das Projekt der Offline-Umgebung - gearbeitet werden.

Im Fehlerfall - der Import der Offline-Umgebung schlägt fehl - wird die vorherige Engineering-Umgebung wieder hergestellt.

4.7.2 Offline-Engineering durchführen Das Engineeren in der Offline-Umgebung kann nun wie gewohnt erfolgen. Die einzige Einschränkung ist nun, dass die nicht ausgecheckten Teile zwar zur Verfügung stehen, aber nicht geändert werden dürfen. Funktionalitäten wie diese sind jederzeit möglich.

Bearbeiten der beim Auschecken gekennzeichneten Teile.

Ein Löschen und Wiederherstellen von ausgecheckten Projektierungsteilen ist jederzeit möglich (Papierkorb).

Hinzufügen von Projektierungsteilen

Rekompilieren

Tasks generieren

Die direkte Arbeit am Projekt ist nicht eingeschränkt.

Abbildung 89: Im Offline-Engineering zur Bearbeitung frei / bearbeitet

Alle ausgecheckten Projektierungsteile sind mit einem grünen '!' gekennzeichnet. Werden sie bearbeitet, schaltet das Grün auf Gelb um.

Es dürfen keine Projektierungsteile bearbeitet werden, die nicht explizit gekennzeichnet sind. Bei diesen Teilen ist es nicht möglich, die Änderungen in die Online-Umgebung zurück zuführen. Hierzu gehören z.B. alle anderen nicht versionisierten Teilbereiche im Engineering.

Im Offline-Engineering kann nicht zu einem weiteren Offline-Engineering ausgecheckt werden!

Projektierungs-Tipps weisen Sie auf Besonderheiten hin, die im Offline-Engineering zu beachten sind.

Die nachfolgende Tabelle gibt Ihnen ein Überblick über erlaubte Änderungen in zum Offline-Engineering freigegebenen Projektierungsteilen:

Projektierungsteil Änderungen erlaubt

Anmerkung


Projektierungsteil Änderungen erlaubt

Anmerkung

Hardware CC Ja Wenn für Offline-Engineering gekennzeichnet. Achten Sie bei der Konfiguration von CC-Modulen auf die Einschränkung bei Dateien im Dateisystem!

Hardware Controller Ja Wenn für Offline-Engineering gekennzeichnet. Achten Sie auf bei der Konfiguration von BR-Modul Referenzen in Fremdanbindungen auf die Einschränkung bei Dateien im Dateisystem!

CFCs Ja Wenn für Offline-Engineering gekennzeichnet. Statische Prozessgrafiken Ja Wenn für Offline-Engineering gekennzeichnet. Dynamische Prozessgrafiken

Ja Wenn für Offline-Engineering gekennzeichnet.

Anlagenteile Ja Wenn für Offline-Engineering gekennzeichnet. Parametersatz-Template Ja Wenn für Offline-Engineering gekennzeichnet. Projektmodule Ja Nur Import von Prokjekt-Modulen. Benutzerrechte Nein Änderungen gehen verloren Operatorrechte Nein Änderungen gehen verloren Projektierungsteilname Nein Änderungen nicht möglich Instanzname Nein Änderungen nicht möglich Dateien im Filesystem Nein z.B.

zentrales Python-Modul Alarmzeilenkonfiguration Diese Änderungen sind im Archiv vorhanden, müssen aber manuell ins Engineering eingefügt werden.

Konfigurationen der Anwendungen des Engineering-Systems

Nein z.B. dynamic.list, ControllerManager Konfigurationen Diese Änderungen sind im Archiv vorhanden, müssen aber manuell ins Engineering eingefügt werden.

Die oben angeführte Tabelle erhebt keinen Anspruch auf Vollständigkeit. Es dürfen definitiv nur die mit Ja gekennzeichneten Projektierungsteile geändert werden, wenn sie für das Offline-Engineering ausgecheckt wurden.

Werden im Offline-Engineering neue Projektierungsteile angelegt, ist darauf zu achten, dass es nicht zu Überschneidungen mit dem Online-Engineering kommt. Im Konfliktfall ist eine Rückführung nur durch Änderung einer der beiden Umgebungen möglich.


Im Offline-Engineering wird die Versionierung aus der Online-Umgebung weitergeführt. Das heißt: z. B. für Teil XYZ die Version 2.4 (aus der Online-Umgebung mitgeführt) wird zu 2.5 und zu 2.6 usw.. Wird nun vom Teil XYZ die Version 2.7 eingecheckt, werden die Zwischenversionen nicht mitgeführt. Sie werden beim Einchecken ignoriert. Für das Teil XYZ gilt: Die Version 2.7 von XYZ wird als Modified zu der Version 2.4 in der Online-Umgebung hinzugefügt. Bei der Versionierung bekommt sie die Version 2.5.

4.7.3 Offline-Engineering beenden Um das Offline-Engineering zu beenden muss der Benutzer das Recht R im Offline-Engineering besitzen. Auch hier dürfen keine Arbeitsversionen (Modified) in den zum Offline-Engineering freigegebenen Projektierungsteilen vorliegen. Sollte dieses doch der Fall sein, macht sie das System darauf aufmerksam und nimmt auf Wunsch die Versionierung vor. Der Vorgang ist unter dem Menüeintrag 'Datei / Offline-Engineering / Offline-Engineering beenden' zu starten. Ein Versionieren der Stände Modified ist beim Beenden möglich (siehe Kapitel Vorbereitung für Offline-Engineerings und Auschecken der Punkt Projektierungsteile auschecken). Nach dem Erstellen eines Archivs der bearbeiteten Offline-Umgebung, wird die zuvor gesicherte Engineering-Umgebung des Engineering-Systems wieder hergestellt. Der Vorgang Starten – Bearbeiten – Beenden der Offline-Umgebung kann solange wiederholt werden, bis das Offline-Engineering wieder in die zugehörige Online-Umgebung eingecheckt wurde!

Ist das Ergebnis des Offline-Engineerings wieder der Online-Umgebung zugeführt, darf das Offline-Engineering nicht mehr weiter fortgesetzt werden. Alle dann vorgenommen Änderungen im Offline-Engineering können der Online-Umgebung nicht mehr zugeführt werden.

4.8 Zusammenführung von Offline und Online .

4.8.1 Einchecken der bearbeiteten Projektierungsteile Zum Einchecken muss der Benutzer das Recht W im Offline-Engineering besitzen. Nach Auswahl des Offline-Archivs wird die darin enthaltene Signatur mit der in der Onlinedatenbank enthaltenen verglichen. Stimmen die Signaturen überein, werden, wenn gewünscht, die Änderungen aus dem Offline-Engineering in das Online-Engineering übernommen.

Es können nur alle Änderungen als Gesamtheit übernommen werden. Kommt es beim Einchecken zu einem Fehler, wird der gesamte Vorgang des Eincheckens verworfen.

Alle aus dem Offline-Engineering eingecheckten Projektierungsteile werden unabhängig von der Version im Offline-Engineering als Arbeitsversion Modified in das Online-Engineering eingefügt. Weiterhin bekommen alle Teile einen CAE-Hinweis, dass sie aus einem Offline-Engineering stammen (ein blaues Dreieck). Dieser Hinweis kann bei Bedarf entfernt werden.


Abbildung 90: Offline-Engineering eingecheckt und Arbeitsversion

Siehe auch Kapitel Arbeiten im Offline-Engineering und beenden der Punkt Offline-Engineeringdurchführen.

4.8.2 Prüfen, aktivieren und kompilieren der Projektierungsteile Die Projektierungsteile liegen nun wieder in der Online-Umgebung als Arbeitsversion (Modified) vor. Ihre Aufgabe ist es nun diese Teile mit dem System zu prüfen, eine Version zu erstellen, zu aktivieren und zuletzt zu kompilieren. Wenn nötig sind dann noch Generierungsläufe durchzuführen. Der Abschluss ist dann der Download auf die entsprechenden Systeme und die Controller.

4.9 Offline-Engineering mit projektspezifischer Datenreduktion Die Option "Projektspezifisches CaeBackup mit Datenreduzierung" unterstützt insbesondere die externe Bearbeitung eines CAE-Projektes aus einer Engineering-Datenbank mit mehreren Projekten und/oder Bibliotheken. Bei Verwendung dieser Option werden automatisch die weiteren Optionen "Berücksichtigen der generierten Daten von Projekten und CAE-Bibliotheken" und "Berücksichtigen der As-Built-Dokumentation der CAE-Bibliotheken.und der vorhandenen Projekt-Dokumentation" deaktiviert und zusätzlich insensitiv geschaltet. Diese Daten werden somit von der Sicherung ausgenommen und die CAE-Datenbank in ihrer Größe reduziert.

Abbildung 91: Offline-Engineering mit projektspezifischer Datenreduzierung

Das Archiv, das bei Verwendung der projektspezifischen Datenreduzierung erstellt wird, enthält:

nur das zum Zeitpunkt des Auscheckens der Projektierungsteile gewählte CAE-Projekt,

nur die in diesem Projekt verwendeten CAE-Bibliotheken, (vorhandene Label dieser CAE-Bibliotheken werden nicht mit gesichert)

nur die neueste und/oder aktive Version aller Projektierungsteile,

nur die Projektdaten ohne generierte Anteile und ohne Dokumentation (z. B. ohne Verzeichnis /GENERATED)

Durch die Datenreduktion werden Datenübertragungen an externe Dienstleister ggf. beschleunigt.


Die Reduzierungsrate ist abhängig von der Anzahl der im CAE-Projekt verwendeten Bibliotheken und der Anzahl der vorhandenen Versionen.

IosDiagnosticManager 5-1

5 IosDiagnosticManager Die Analyse der Prozessdatenbasis (Iosys) wird durch den IosDiagnosticManager unterstützt. Diese GUI-basierte Anwendung vereinigt alle Funktionen der 'Iosys-Tools' und bietet darüber hinaus weitere Funktionen (z.B. Signalgeneratoren) zur Beeinflussung von PVs zu Diagnosezwecken. Der Aufruf des IosDiagnosticManager erfolgt über das KDE-Menü 'Diagnose / IosDiagnosticManager'.

Die Verwendung der Konsolenanwendungen 'Iosys-Tools' oder des GUI-basierten IosDiagnosticManager ermöglichen Ihnen einen Einblick in die Iosys-Datenbasis sowie die Manipulation der Daten auf dem lokalen als auch auf einem entfernten Iosys. Somit erhalten Sie einen ggf. notwendigen kurzen Überblick über den aktuellen Systemstatus.

Die Verwendung dieser Iosys-Tools darf nur durch erfahrene Anwender erfolgen. Sie ersetzen nicht den ordnungsgemäßen Betrieb über die GUI-Anwendungen und dürfen nicht für eine reguläre Anlagensteuerung verwendet werden.

5.1 Hinweise zur Unterstützung von Multi-Runtime-Systemen Ein Multi-Runtime-System besteht aus mehreren Runtime-Systemen, die zu einem CAE-Projekt gehören und über dieses konfiguriert werden. Das bedeutet, die PVs verteilen sich innerhalb eines CAE-Projekts auf mehrere Iosys-Systeme.

Detailinformationen zu Multi-Runtime-Systemen finden Sie im Handbuch 'B2 Projekt Engineering', Kapitel Multi-Runtime-Systeme in APROL.

Sowohl die Konsolenanwendungen 'Iosys-Tools' (wie z.B. IosEv) als auch der IosDiagnosticManager können gleichzeitig PVs und Clients unterschiedlicher Runtime-Systeme eines CAE-Projekts erfassen bzw. darstellen.


5.2 Allgemeines zur Verwendung des IosDiagnosticManager Die GUI ist in zwei Teilbereiche gegliedert und bietet Ihnen hier folgende Möglichkeiten:

Der linke Bereich dient der Anzeige der Iosys-Clients und der im Iosys angemeldeten PVs. Sie haben hier die Möglichkeit, anhand von Wildcards eine Filterung der Iosys-Clients bzw. der Iosys-PVS unter Verwendung der Levenshtein-Distanz durchzuführen. Zusätzlich kann hier die Ansicht zwischen einer flachen Liste oder einer Baumstruktur umgeschaltet werden.

Der rechte Bereich dient der Darstellung der Watch-Fenster. In diesen werden die Ereignisse (Change-Events) von eingefügten (beobachteten) PVs dargestellt. Es können grundsätzlich ein oder mehrere Watch-Fenster angelegt werden.

Verwenden Sie den Menüpunkt 'Extras / Ansicht Vertikal ausrichten', um die o. g. Teilbereiche übereinander anzuordnen.

Folgende Aktionen für PVS können im IosDiagnosticManager durchgeführt werden:

Anzeigen aller PVs (die im verbundenen Iosys angemeldet sind)

Ändern der Attribute einer PV (Wert, Typ, Status) per Eigenschafts-Dialog oder Signalgenerator

Anzeigen von Change-Events - im dynamischen Watch - im statischen Watch

Anzeigen des Online-Trends zu einer PV

Aufruf des Audit Trails für eine PV Jede Änderung eines Attributs einer PV, die mit dem IosDiagnosticManager durchgeführt wird, wird im Audit Trail aufgezeichnet. Diese Änderungen werden in der Aktionsgruppe 'Externe Prozessführung' erfasst und ermöglichen somit ein gezieltes Filtern im AuditTrail-Report.

Anlegen von PVs

5.2.1 Iosys-Clients / Iosys-PVs Für jedes 'APROL-System' muss zunächst die Verbindung zum zugehörigen Iosys erstellt werden. Verwenden Sie hierzu den Menüeintrag 'Iosys / Verbindung zum Iosys' oder den gleichnamigen Eintrag im Kontextmenüs des ausgewählten Runtime-Systems. Daraufhin können die Clients eines 'APROL-Systems' (via Kontextmenü) oder alle Clients aller 'APROL-Systeme (Menüpunkt 'Iosys / Alle Clients laden') geladen werden.

Iosys-Clients sind alle Anwendungen (z. B. das DisplayCenter oder Treiber), die in diesem APROL-System laufen und mit dem Iosys verbunden sind.


Analog hierzu erfolgt das Laden der PVS für jedes ''APROL-System' bzw. alle ''APROL-Systeme'.

Abbildung 92: IosDiagnosticManager

Reiter 'Iosys-Clients': Die Ansicht 'Iosys-Clients' ist sehr hilfreich, um herauszufinden, welche bzw. wie viele Anwendungen von welchem Server oder Operator-Station aus (unter Angabe des CC Accounts, Display, Host) auf einen Iosys zugreifen. Die Einträge unter dem Reiter 'Iosys-Clients' können wahlweise in einer Listen- oder einer Baumansicht (Defaulteinstellung) dargestellt werden. In der Baumansicht werden die Clients unterhalb des jeweiligen Runtime-Systems dargestellt. Die Einträge können über das Kontextmenü in unterschiedliche Zielformate (csv-, txt oder xml-Format) exportiert werden.

Auf die exportierte Datei kann anschließend z.B. in einer Windows-basierten Umgebung (z.B. mit Excel) zugegriffen werden. Dies ist sinnvoll z. B. für Inbetriebnahme- und Abnahmedokumente. Somit ist der Umfang der Clients nach der Inbetriebnahme dokumentiert.

Reiter 'Iosys-PVs': Die Einträge unter dem Reiter 'Iosys-PVs' können wahlweise in einer Listen- oder einer Baumansicht (Defaulteinstellung) dargestellt werden. In der Baumansicht werden die PVs unterhalb des jeweiligen Runtime-Systems dargestellt. Nach dem Einlesen der PVs ('PVs laden' oder 'Alle PVs laden') werden ausschließlich die PV-Namen angezeigt. Sollen weitere PV-Attribute dargestellt werden, muss die PV in der Liste selektiert und anschließend über das Kontextmenü 'PV anmelden' oder den Eigenschaftsdialog ('PV wird automatisch angemeldet') angemeldet werden. Daraufhin werden der PV-Status, PV-Typ, Live-Wert und das Signal als weitere PV-Attribute dargestellt.

Beim Drag & Drop einer PV in einen Watch wird diese automatisch angemeldet.


Im Label des Reiters 'Iosys-PVs' wird die Anzahl der aktuell aufgelisteten PVs (unter Berücksichtigung der eingestellten Levenshtein-Distanz) und die Gesamtmenge der eingelesenen PVs angezeigt.

Dies ist analog zum Verhalten im Reiter 'Iosys-Clients' (hinsichtlich der Clients).

Das Verhalten im Reiter 'Iosys-Clients' ist analog hierzu. Der Eigenschafts-Dialog zu einer PV ist dynamisch, d.h. bei einem Change-Event werden die angezeigten Werte im aufgeschalteten Dialog aktualisiert.

Abbildung 93: PV-Eigenschaften

In der Dropdown-Liste 'Werthistorie' werden die letzten zwanzig Werte in einem Ringpuffer aufgezeichnet. Durch Auswahl eines Wertes aus der Liste wird dieser in das Eingabefeld 'Gewünschter Wert' übernommen. Vorgenommene Änderungen werden erst nach bei Betätigung des Buttons [Übernehmen] durchgeführt.

5.2.2 Statischer / dynamischer Watch Das Anlegen eines neuen Watch-Fensters erfolgt über das Menü 'Watch / Neuer <dynamischer | statischer> Watch'.

In einem neuen Watch-Fenster kann eine weitere PV-Zusammenstellung dargestellt werden.


Abbildung 94: Anlegen eines Watch

Der dynamische Watch zeigt für jede eingefügte Prozessvariable ein eintretendes Ereignis als separaten Eintrag innerhalb einer Listenansicht an. Jeder Eintrag enthält die zum Zeitpunkt des Ereignisses aktuellen Attribute und zugehörigen Werte der Prozessvariablen.

Für alle Spaltenüberschriften (z.B. PV-Typ oder PV-Status) sind erklärende Tooltipps vorhanden.

Die Liste wächst entsprechend den eintretenden Ereignissen an. Eintretende Ereignisse werden stets an oberster Stelle eingefügt. Bei dieser Betrachtung steht der zeitliche Aspekt im Vordergrund. Der zugehörige Instanzname des Runtime-Systems wird in der Spalte 'PV-Name' nach dem '@'-Zeichen dargestellt.

Abbildung 95: Dynamische Watch

Über das Kontextmenü zu den Spaltenüberschriften kann eine Auswahl der anzuzeigenden Spalten getroffen werden.


Abbildung 96: Spalten ein- / ausblenden

Der dynamische Watch kann z. B. verwendet werden zur Aufzeichnung und Analyse von Abläufen / Analyse von Abhängigkeiten im Laufzeitverhalten von Signalen.

Der statische Watch stellt für jede eingefügte Prozessvariable genau einen Eintrag innerhalb einer Listenansicht dar. Beim Eintreffen eines Ereignisses auf einer der eingefügten Prozessvariablen, wird dann der bestehende Eintrag innerhalb der Listenansicht mit den Attributen sowie den zugehörigen Werten der Prozessvariablen aktualisiert.

Abbildung 97: Statischer Watch

Der zugehörige Instanzname des Runtime-Systems wird in der Spalte 'PV-Name' nach dem '@'-Zeichen dargestellt.

Der statische Watch kann zur Beobachtung von PVs auch über einen längeren Zeitraum verwendet werden. Er eignet sich z.B. in Kombination mit dem Online-Trend zur Identifikation von Signalsprüngen.

5.2.2.1 Allgemeines zur Bedienung im Watch-Fenster

Umbenennen eines Watch-Fensters: Einem Watch kann ein Name zugewiesen werden (Doppelklick auf dem Watch-Reiter oder über das zugehörige Kontextmenü). Mit dem Umbenennen eines Watch-Fensters kann für die gewählte PV-Zusammenstellung ein sprechender Name für den Diagnosefall gewählt werden.


Ein Watch kann grundsätzlich folgende Zustände annehmen: - aktiv (d. h. gestartet, eintretende Ereignisse werden dargestellt) - inaktiv (d. h. gestoppt, eintretende Ereignisse werden nicht dargestellt) Initial befindet sich ein Watch im Zustand inaktiv. Ein Watch kann nur aktiv werden, wenn mindestens eine PV eingefügt wurde. Im Watch-Reiter werden der Zustand und die Anzahl der im Watch enthaltenen Change-Events angezeigt.

Hinzufügen von PVs: Das Hinzufügen einer PV zu einem Watch kann unter dem Reiter 'Iosys-PVs' sowohl über das Kontextmenü 'PVs beobachten' als auch einen Doppelklick sowie per Drag & Drop der entsprechenden PV erfolgen.

Zusammenstellung speichern: Die Zusammenstellung der Prozessvariablen in einem Watch kann in einer Datei gespeichert werden. Hierbei werden die Namen der enthaltenen Prozessvariablen gespeichert (PV-Subset). Dies bietet die Möglichkeit, die zusammengestellten Prozessvariablen zu einem späteren Zeitpunkt erneut in einem Watch zu laden. Das Laden eines zuvor gespeicherten Watch erfolgt über den Menüpunkt 'Watch / Lade Watchs'. Über einen Dateiauswahldialog kann die im Dateisystem abgelegte Zusammenstellung ausgewählt werden. Beim Speichern (oder Exportieren) des Watch wird der Watchname als Dateiname verwendet und beim Laden entsprechend wiederhergestellt.

Exportieren / Drucken: Die in einem Watch enthaltenen Informationen können über das Kontextmenü oder die Toolbar in eine Datei exportiert und ausgedruckt werden. Für den Export stehen die Ausgabeformate CSV, TXT und XML zur Verfügung. Auf die exportierte Datei kann anschließend z.B. in einer Windows-basierten Umgebung (z.B. mit Excel) zugegriffen werden. Der Export ermöglicht u.a. die Bereitstellung und Übermittlung der Daten für den Support.

Auslösen eines separaten Fensters: Zum Zwecke der Übersichtlichkeit, kann ein Watch-Fenster, wie in APROL üblich, als separates Fenster ausgelöst werden (Toolbar-Button 'Separates Fenster).


5.3 Verwendung eines Signalgenerators

Motivation für die Verwendung eines Signalgenerators: Mit Hilfe eines Signalgenerators kann z. B. in der Inbetriebnahmephase ein Signalverlauf simuliert werden (z. B. Sägezahn).

Signalgeneratoren können unabhängig von den PVs erstellt und konfiguriert werden. Die Konfiguration eines Signalgenerators wird im IosDiagnosticManager mit Hilfe eines Wizzards angeboten. Der Wizzard ist über das Menü 'Signalgenerator / Neuer Signalgenerator' erreichbar.

Abbildung 98: Signalgenerator erstellen 1/2

Abbildung 99: Signalgenerator erstellen 2/2

Diese zuvor konfigurierten oder aus einer Datei geladenen Signalgeneratoren können wahlweise auf eine oder mehrere PVs des gleichen IEC-Datentyps angewandt werden. Die bereits erstellten Signalgeneratoren können in einem Übersichtsdialog dargestellt werden (Menüpunkt 'Signalgenerator / Existierende Signalgeneratoren anzeigen'). Weitere PVs können über das Kontextmenü der PV oder per Drag & Drop im Übersichtsdialog zu einem Signalgenerator hinzugefügt werden (nur bei gleichem IEC-Datentyp der PVs).


Über das Kontextmenü 'PV von Signalgenerator abmelden' können einzelne PVs von dem Signalgenerator abgemeldet werden.

Im Audit Trail werden das Starten / Stoppen und die Konfiguration eines Signalgenerators und jede durch ihn durchgeführte Wertänderung auf einer PV aufgezeichnet (Aktionsgruppe 'Externe Prozessführung'). Bei einer Auswertung des Audit Trails kann somit gezielt nach der Anwendung eines Signalgenerators gefiltert werden.

Abbildung 98: Erfassung im AuditTrail (Aktionsgruppe 'Externe Prozessführung'

Folgende Signaltypen stehen in Abhängigkeit des gewählten Iosys-Typs zur Verfügung:

Zyklisch Treppe Sägezahn

Rampe Toggle Sinus

Zufall Dreieck Historie

5.4 PV-Werte in den Iosys schreiben / aus Iosys ermitteln Über diese Funktionen kann der Inhalt von definierten Prozessvariablen (PVs) eines lokalen oder entfernten Iosys exportiert werden. Es besteht die Möglichkeit, diese (oder eine selbst erzeugte) Liste wieder in das System zu importieren.

Zum Zwecke der Fehleranalyse kann die so erzeugte Liste den Zustand definierter PVs zu einem bestimmten Zeitpunkt darstellen.

Nach dem Aufruf der Funktion über den Menüpunkt müssen nacheinander zwei Dateien ausgewählt werden. Die erste Datei (Listendatei) muss die Namen der relevanten Prozessvariablen enthalten (je Zeile eine PV).


Abbildung 100: PV-Werte in den Iosys schreiben / aus Iosys ermitteln (Schritt 1)

In der zweiten Datei (Datendatei) wird im Falle eines Exports, der Wert der jeweiligen PV gespeichert (je Zeile ein Wert). Handelt es sich um einen Import, so müssen in der zweiten Datei Werte vorhanden sein, die auf die jeweilige PV geschrieben werden.

Diese Funktionalität entspricht der Kommandozeilenanwendung 'IosInOut'.

Beispiele zur Verwendung finden Sie im Kapitel IosInOut.

Abbildung 101: PV-Werte in den Iosys schreiben / aus Iosys ermitteln (Schritt 2)

Iosys HTTP-Schnittstelle 6-1

6 Iosys HTTP-Schnittstelle .

APROL stellt eine Iosys HTTP-Schnittstelle

für den Zugriff auf Iosys-Daten von externen Systemen

für den Zugriff auf Iosys-Daten aus Webseiten

zur Verfügung.

6.1 Allgemeines Die Anwendung IosHttp ist in den CC-Modulen konfigurierbar und wird defaultmäßig auf jedem Runtime-System gestartet.

6.1.1 Anwendung IosHttp Die Anwendung IosHttp nimmt HTTP post-Request auf einem definierten TCP-Port (via Kommandozeilenoption '-portOffset', entgegen. Das vergebene Offset bezieht sich hierbei auf den Defaultport 55590. Mögliche Requests sind Lesen und Schreiben von Iosys-Variablen. Kontaktiert wird immer der Iosys, der beim Start des IosHttp festgelegt wurde (Kommandozeilenoption -iosys <host:port>).

6.1.2 Konfiguration des Webservers Der Zugriff von einem externen Rechner muss über den Apache-Server erfolgen. Dieser fungiert als Proxy-Server für die Requests an den IosHttp und leitet sie an den zuständigen IosHttp weiter.

Für die 'apache2.conf' wird eine Include-Datei '<Projektname>_IosHttp.conf' generiert und auf alle Control Computer geladen, die die Zuordnung vom gewünschten Runtime-Systeme zum Rechner und Port des zugehörigen IosHttp enthält.

Die Include-Datei befindet sich im Verzeichnis /home/aprolsys/APROL/cnf/apache2/.


6.2 Detailinformationen

6.2.1 Request-Spezifikation Folgende Requests werden (auf spezifiziertem Port) vom IosHttp akzeptiert. Als HTTP-Methode kann jeweils sowohl 'get' als auch 'post' verwendet werden. Falls 'post' verwendet wird, so sind die Parameter im MIME-Typ 'application/x-www-form-urlencoded' zu übertragen.

URL Query-Parameter Bedeutung Response Data

/iosys/<Projektname>/<Instanz des Runtime-Systems>/xml/get

id=<pv1>,<pv2>,... oder id=<pv1>&id=<pv2>...;fld=<bit-maske>

Abfrage der Momentanwerte der angegebenen Iosys-Variablen (Daten des letzten Ereignisses)

XML-Format (s.u.)

/iosys/<Projektname>/<Instanz des Runtime-Systems>/json/get

wie bei /iosys/xml/get wie bei /iosys/<Projektname>/<Instanz des Runtime-Systems>/xml/get

json Format (s.u.)

/iosys/<Projektname>/<Instanz des Runtime-Systems>/set

<pv1>=<value1>&<pv2>=<value2>&...

Setzen der angegebenen Iosys-Variablen auf den angegeben Wert. Der Typ wird automatisch aus dem übergebenen Wert ermittelt: Zahl ohne '.' und ohne 'e,E' : IosType_INT (IosVar_set_int), Zahl mit '.' oder mit 'e,E': IosType_REAL(IosVar_set_real), sonst: IosType_REAL (IosVar_set_string)

keine Daten

Der Parameter 'fld' dient zur Steuerung der in der Antwort enthaltenen Attribute (Bit-Maske: Siehe unten stehende Tabelle). Response HTTP-Status Codes und Erklärungen:

Status Erklärung

200 OK 204 OK, no content (immer bei /iosys/set - Requests) 400 bad request (Fehlerhafte Anfrage, z.B. Query-Parameter falsch) 404 not found (Pfad nicht wie oben angegeben) 410 recource timeout (Gültigkeit des Token abgelaufen) , Siehe unten 500 interner Fehler


502, 503 Iosys konnte nicht kontaktiert werden.

6.2.2 Response Formate

6.2.2.1 XML-Format <?xml version="1.0" encoding="UTF-8"?> <points token="<Zeichenkette>"> <point ts="<zeitstring>" id="<pv>" nr="<nr>" uts="<unix-timstamp>" ty-pe="<iosys-type>" val="<wert>" flags="IVSQFP" /> <point .... /> <point .... /> ...... </points>

Für jede in der Abfrage angegebene ID ist ein 'point' Knoten vorhanden. Die Attribute sind der unten stehenden Tabelle zu entnehmen.

6.2.2.2 json-Format Wahlweise kann das json-Format angefordet werden.

Nähere Informationen zum Json-Format finden Sie unter 'www.json.org'.

[ {'token': '<Zeichenkette>' } , [{ 'ts' : 'Zeitstring' , 'id' : '<PV>' , 'nr' : 0 , 'uts' : unix-timestamp , 'type' : iosys-type , 'val' : '<wert>' , 'flags' : 'IVSQFP'} , { .. }, { ..} ] ] Array mit 2 Elementen: 1. Element: Objekt mit dem Namen 'token' und Wert Zeichenkette (s.u.)

2. Element: Array von Objekten. Für jede in der Abfrage angegeben ID ist ein Objekt vor-handen. Die Objekte haben folgende Attribute:

Attribut Bedeutung Default in Response? (ohne 'fld' Attribut im Request)

Steuerbit im Parameter 'fld'

ts Zeitstempel des letzten Iosys-Events in der Form yyyy-mm-dd hh:mm:ss.mmm

x 0

id Name der Iosys - Variablen

x 1

val Wert der Iosys-Variablen (letztes Ereignis)

x 2


flags Status der Flags der Iosys-Variablen. Format: IVSQFP mit idle (I), valid (V), sourced (S), source (Q), force (F), persistent (P)

x 3

type Type der Iosys - Variablen: IosType_NONE = 0 , IosType_INT = 1 , IosType_REAL = 2 , IosType_STRING = 3 ,

- 4

uts Unix-Zeitstempel des letzten Iosys-Events (Mikrosekunden-Genauigkeit)

- 5

nr Position der ID in der Abfrage.

- 6

Hinweise: Es wird kein Fehler gemeldet, falls die Variable bereits versorgt ist, obwohl 'set' in diesem Fall keine Wert-Änderung bewirkt. Attribute können fehlen, falls nicht vorhanden. Z.B. fehlt 'val', falls die Variable nicht vorhanden (Status: idle) ist. HTTP-Status Codes und Erklärungen:

Status Erklärung

200 OK 204 OK, no content (immer bei set - Requests) 400 bad request (Fehlerhafte Anfrage, z.B. Query-Parameter falsch) 404 not found (Pfad nicht wie oben angegeben) 410 recource timeout (Gültigkeit des token ist abgelaufen), siehe unten 500 interner Fehler 502, 503 Iosys konnte nicht kontaktiert werden

Das Attribut 'token': Falls eine feste Liste von Variablen häufig in kurzer Folge abgefragt werden soll, so kann mit der folgenden Technik die Menge der im Request zu übertragenden Daten reduziert werden und die 'Long Polling' Technik verwendet werden. I) Im ersten Request wird die vollständige Liste der abzufragenden Variablen (ID-Liste)

übertragen.


II) Im Response ist der ein Token (Attribut 'token') als Zeichenkette enthalten. Dieses bleibt für eine kurze Zeit (10 s) gültig.

III) In den weiteren Requests sendet der Client nur das Token statt der (ID-Liste). Die Gültigkeit wird verlängert.

IV) Der Response enthält im Normalfall denselben Token. Falls irgendein Fehler Auftritt (HTTP-Status ungleich 200) ist das Token ungültig. Z.B falls mehr als 10s seit der letzten Verwendung des Tokens verstrichen sind. Die ID-Liste muss in einer neuen Anfrage wieder vollständig übertragen werden.

V) Im Response ist ein neues Token enthalten.

'Long Polling' Technik Die Antwort auf einen Request, der einen Token verwendet, erfolgt entweder

sofort, falls sich seit der letzten Verwendung dieses Tokens am Wert oder Status einer der überwachten Variablen eine Änderung ergeben hat,

oder nach Eintreffen des nächsten Iosys-Events auf einer oder mehrerer der überwachten Variablen

jedoch spätestens nach 10 Sekunden

Im Response sind nur die Variablen enthalten, deren Wert sich seit der letzten Abfrage geändert hat! Diese Technik wird als 'Long Polling' bezeichnet und bietet eine Art Event gesteuertes Verhalten.

Bitte beachten Sie, dass jedoch prinzipbedingt nicht garantiert werden kann, dass alle Iosys-Ereignisse der überwachten Variablen gemeldet werden. Für eine Client-Anwendung ist damit eine Registrierung aller Iosys-Ereignisse nicht gesichert!

Beispiel zur Abfrage: wget -q -O - "http://localhost/iosys/<Projektname>/<Instanz des Runtime-Systems>/json/get?id=ottemobil_IdleStatePercent;"

IosHttp Konfigurations-Datei: Bei einem Download wird die Verbindungs-Konfiguration für den IosHttp-Server verteilt. Bei einem Download wird die Konfigurations-Datei '<Projektname>_IosHttp.conf' im Verzeichnis /home/aprolsys/APROL/cnf/apache2 erzeugt. Inhalt der Datei: Für jedes Runtime-System wird eine Zeile der Form ProxyPass/iosys/<Projektname>/<Instanz des Runtime-Systems>/ http://<Hostname des Servers, auf dem das Runtime-System residiert>:<Portnummer>/iosys/


6.2.3 HTML-Testseite mit Systemvariablen

Unter der URL https://<runtimecluster>/ioshttp/iosys.html kann eine Testseite aufgerufen werden. Auf der Testseite sind einige Systemvariablen dargestellt, die über asynchrone Javascript-Abfragen (AJAX) laufend aktualisiert werden.

Iosys-Kopplung 7-1

7 Iosys-Kopplung .

7.1 Konfiguration einer Iosys-Kopplung U. U. kann es erforderlich sein, Prozessvariablen projektübergreifend zur Verfügung zu stellen. Die Iosys-Kopplung ermöglicht einen lesenden und schreibenden Zugriff auf Prozessvariablen eines anderen CAE-Projektes und damit einen Datenaustausch zwischen zwei Iosys verschiedener Projekte. Folgende Schritte sind fürdie Konfiguration einer Iosys-Kopplung erforderlich: Schritt Aktion 1 Definition der Variablen:

Konfiguration von Gateway-Variablen auf beiden Kommunikationspartnern im Projektierungsteil 'APROL-System' / Sektion 'APROL-Kopplungen' / 'Gerätefreie Kopplung' Achtung: Es sind identische Variablennamen in beiden CAE-Projekten zu verwenden.

2 Festlegen der Schreibrichtung: Variablen-Art 'Eingang oder Ausgang' der konfigurierten Gateway-Variablen im Projektierungsteil 'APROL-System'

3 Definition des zu kontaktierenden CAE-Projekts: Konfiguration der Option '-export' des Iosys auf dem Quell oder Ziel-Runtime-System

4 Anlegen der Konfigurationsdatei auf dem Runtime-System, wo zuvor die Option '-export' konfiguriert wurde

7.1.1 Definition der Variablen 1. Konfiguration der Variablen im Quell-System Öffnen Sie auf dem Quell-System das Projektierungsteil 'APROL-System' und selektieren Sie die Sektion 'APROL-Kopplungen'. Legen Sie unter dem Eintrag 'Gerätefreie Kopplung' über das Kontextmenü 'Neu' eine neue Kopplung an. Der Name der Gerätefreien Kopplung kann frei gewählt werden, z.B. 'Iosys2Iosys'. Selektieren Sie den neu angelegten Kopplungseintrag und legen Sie unter dem Eintrag 'Variablen' neue Gateway-Variablen an.


Abbildung 102: Konfiguration der Gateway-Variablen im Quell-System

Es sind in jedem Fall die Pflichtfelder 'Art' und 'Typ' zu konfigurieren. Über die 'Art' (Eingang oder Ausgang) legen Sie die Kommunikationsrichtung fest. Eine Gateway-Variable, die im Projekt des Quellsystems beschrieben / gesetzt wird, wird als Ausgang konfiguriert und muss im Projekt des Zielsystems mit gleichem Variablennamen als Eingang konfiguriert werden da sie dort gelesen wird - und umgekehrt. Legen Sie unter 'Typ' den IEC-Datentyp der Gateway-Variablen fest.

Informationen zu den weiteren Parametern entnehmen Sie bitte den Tooltipps.

2. Konfiguration der Variablen im Ziel-System Auf dem Kommunikationspartner (Ziel-System) müssen gleichnamige Gateway-Variablen im Projektierungsteil 'APROL-System' konfiguriert werden.

Es sind zwingend die identischen Variablennamen des Kommunikationspartners zu vergeben.

7.1.2 Definition des zu kontaktierenden CAE-Projekts Auf dem Ziel-System:

Abbildung 103: Konfiguration des Export-Schalters im Projektierungsteil 'APROL-System'

Die CC-Modul Option '-export' gibt die Verbindungs-Informationen eines weiteren Iosys für den Austausch von Prozessvariablen an.

Iosys-Kopplung 7-3

-export <Servername Kommunikationsziel>:<Iosys-Port>

Beispiel für einen redundanten Kommunikationspartner: -export meeting1:0, meeting2:0

Die Namen der zu auszutauschenden Prozessvariablen werden aus der Datei /home/<CC-Account>/RUNTIME/<lokaler Servername>:<Iosys-Port>.export.cfg gelesen.

Bei einem redundant ausgelegten Runtime- bzw. Gateway-System ist der Name der Datei <lokaler Servername>:<Iosys-Port>.export.cfg für beide Redundanz-Partner (entsprechend dem jeweiligen Rechnernamen) anzupassen. Diese Option kann mit der Option '-prefix' kombiniert werden, um bei entsprechender Verwendung der Optionen die exportierten Variablen im Ziel-Iosys eindeutig identifizieren zu können.

Die Option '-prefix' kann ausschließlich in Verbindung mit der Option '-export' verwendet werden. Die Zeichenkette, die als Präfix angegeben wird, wird den Variablen in der Konfigurationsliste vorangestellt.

7.1.3 Anlegen der Kommunikationsdatei Auf dem Zielsystem: Legen Sie im Verzeichnis /home/<CC-Account>/RUNTIME/ manuell die Konfigurationsdatei <lokaler Servername:Iosys-Port>.export.cfg an.

Tragen Sie in der neu angelegten Konfigurationsdatei untereinander die Namen der zuvor konfigurierten Gateway-Variablen ein. Beispiel: Iosys2Iosys_VAR1 Iosys2Iosys_VAR2 Iosys2Iosys_VAR3

APROL-SQL 5

8 APROL-SQL . Zur Erfassung und Auswertung von historischen Daten stand Ihnen bisher ausschließlich das ChronoLog-System zur Verfügung. Eine komfortable Darstellung ausgewählter Informationen war darüber hinaus mit den APROL-Reports möglich.

In diesem Handbuch möchten wir Ihnen die Möglichkeit vorstellen, wie Sie mit Hilfe von ODBC/JDBC und der standardisierten Abfragesprache SQL-92 (http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt) ihre Daten abrufen können. Zu diesem Zweck wurde der Dienst 'AprolSqlServer' entwickelt, welcher Ihre Abfragen entgegennimmt und diese auf die ChronoLog-Datenbank anwendet. Mit der offenen Datenbankschnittstelle ODBC/JDBC ermöglichen wir Ihnen nun die freie Wahl des Abfragewerkzeugs.

APROL-SQL bietet ausschließlich einen lesenden Zugriff auf die historischen Daten. Eine Manipulation ist nicht möglich!

Dieses Handbuch setzt Basiswissen über ODBC / JDBC voraus. Weiterhin sind Grundkenntnisse über Linux von Vorteil.

Informationen über die beispielhafte Verwendung im B&R 'Samples Project' finden Sie im Verzeichnis 'Widgets / ListView / SQLqueryPIC'.

SSL-Verschlüsselung Die Datenübertragung zwischen dem Abfrage-Client und dem APROL-SQL-Server wird standardmäßig mit SSL-Verschlüsselung durchgeführt.In der APROL-Systemumgebung ist keine Konfiguration für die SSL-Verschlüsselung erforderlich. Hinweis Zur Vermeidung von Namenskonflikten mit SQL-Schlüsselworten verwenden Sie bitte SQL-Namens-Delimeter (") bei Tabellen- und Spaltennamen. Beispiel:

• SELECT "ts" FROM "base"."Download"

8.1 Systemaufbau Dieses Kapitel soll Ihnen das Wissen über die Zuordnung von historischen Daten zu den jeweiligen APROL-Systemen und die verteilte Anwendung der AprolSqlServer vermitteln.

Die folgende beispielhafte Auflistung soll den Begriff 'historische Daten' konkretisieren und als Basis für den weiteren Verlauf dienen. Historische Daten sind:

• Projektierungsverlauf durch den Projektingenieur

• Schalthandlungen des Operators

http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

D1 System Handbuch 6

• Trendaufzeichnungen eines Prozesses

• Alarme und deren Quittierung Die 'Schalthandlung des Operators' erzeugt Daten über die durchgeführte Aktion, welche daraufhin in einer ChronoLog-Datenbank abgelegt werden. Ähnlich verhält es sich mit den weiteren Punkten. Der wesentliche Unterschied liegt in dem Ort der Speicherung.

Jedes Beispiel steht im direkten Bezug zu einem APROL-Systemtyp auf welchem die Daten erhoben und abgelegt werden. Analog zu der oberen Liste gilt dann:

• Engineering-System

• Operator-System (u. Protokoll-Server)

• Runtime-System

• Runtime-System (u. Protokoll-Server)

Historische Daten in APROL sind somit an einen Systemtyp gebunden. Sind diese Systeme auf unterschiedlicher Hardware installiert, so ergibt sich eine räumliche Trennung und somit eine Vielzahl von ChronoLog-Datenbanken. Die geklammerten Ausdrücke beschreiben das 'Data-Forwarding' auf ein zentrales APROL-System. Hierzu mehr im weiteren Verlauf.

Um nun die Abfrage 'Welche Schalthandlungen hat Operator A im Zeitraum von x bis y durchgeführt?' vollständig beantworten zu können, müssen alle Operator-Systeme in ihrer Gesamtheit betrachtet werden. Denn letztlich könnte Operator A mit verschiedenen Systemen interagieren. Anders verhält es sich mit der Anfrage 'Welche Projektierungsteile wurden von Projektingenieur B gelöscht?'. Diese betrifft ein konkretes Engineering-System und kann von diesem direkt beantwortet werden. Es kann also eine weitere Klassifizierung nach Art der historischen Daten getroffen werden:

• Lokale Daten

• Verteilte Daten Projektierungsdaten sind lokal, d.h. sie können nur von dem jeweiligen Engineering-System beantwortet werden. Daten aus dem Runtime- oder Operator-System sind verteilter Art. Deshalb müssen Techniken zur Zentralisierung eingesetzt werden, damit diese wie lokale Daten abgefragt werden können. Diese Techniken sind:

• Data-Forwarding

• Query-Forwarding Beim 'Data-Forwarding' werden anfallende historische Daten von einem Operator-System an den ausgezeichneten Protokoll-Server weitergeleitet und dort in der ChronoLog zentral gespeichert. Eine vollständige Abfrage kann nur von dem Protokoll-Server beantwortet werden. Beim 'Query-Forwarding' werden die anfallenden Daten in der jeweiligen lokalen ChronoLog abgelegt und nicht weitergeleitet. Wird nun vom Anwender eine Abfrage an ein bestimmtes Runtime-System abgesetzt, so ermittelt dieses System automatisch alle weiteren betroffenen Systeme und versendet daraufhin Teilabfragen. Diese werden eigenständig verarbeitet und es werden einzelne Teilantworten zurückgesendet. Das ursprünglich kontaktierte Runtime-System fügt nun diese Ergebnisse zusammen und sendet ein Gesamtresultat zurück zum Anwender. Eine Abfrage kann von jedem Runtime-System beantwortet werden. Das Verfahren 'Query-Forwarding' wird für Trend-Daten verwendet, deren Auswertung möglichst zeitnah zur Erfassung erfolgen soll. Alle weiteren Runtime bezogenen Daten werden mittels

APROL-SQL 7

'Data-Forwarding' bereitgestellt. Der Vollständigkeit halber sei darauf hingewiesen, dass neben dem 'Data-Forwarding' auch eine lokale Speicherung der historischen Daten auf dem jeweiligen System erfolgt (z.B. für die Archivierung). Abschließend kann nun gesagt werden, dass historische Daten entweder Runtime- oder CAE-bezogen sind. Weiterhin ist eine Abfrage auf historische Daten nur auf einem Runtime- oder Engineering-System möglich. In keinem Fall wird das Operator-System direkt kontaktiert. Aus diesem Grund werden auch nur auf den beiden Systemtypen jeweils eigenständige AprolSqlServer Dienste gestartet. Zur Vereinfachung gilt die folgende Faustregel:

Jedes Engineering-System wird für seine eigenen Anfragen kontaktiert.

Der Protokollserver wird für alle Anfragen im Runtime kontaktiert.

Diese Regel wird als Basis für den weiteren Verlauf der Dokumentation benutzt. Die Redundanzfähigkeit wird durch die ChronoLog-Datenbank gewährleistet.

8.2 Einrichtung einer Verbindung zum AprolSqlServer .

8.2.1 Authentifizierung und Autorisierung Für den Verbindungsaufbau zum AprolSqlServer benötigen sie einen Namen und ein Passwort. APROL-SQL verwendet die APROL Benutzer- und Operatorverwaltung zur Authentifizierung und Autorisierung. D.h. Benutzer und Operatoren können sich am AprolSqlServer anmelden, falls sie die hierfür benötigen Rechte haben.

• Benutzer benötigen für den Zugriff auf den SQL-Server das globale Recht „AprolSqlServer: Lesen“.

• Operatoren benötigen das Recht „AprolSqlServer: Lesen“. Es besteht die Möglichkeit, Benutzern bzw. Operatoren zu erstellen, die ausschließlich das Recht auf den SQL-Zugriff haben. Dies ist, z.B. für Personal gedacht, die sich mit Berichterstattung sich befassen sollen, aber keinen Falls mit die Bedienung der Anlage. Mittels der Stammdaten-Option 'SQL-System-User' bzw. 'SQL-System-Operator' wird dies eingestellt.

Abbildung 104: Einstellung für SQL-System User

Die SqlSystemUser werden ausschließlich zur Authentifizierung der Datenbeschaffung für SQL-Abfragen im APROL-SQL verwendet. Falls die Option 'SQL-System-User' auf einem bestehenden Konto aktiviert wird, werden alle andere Rechte außer 'AprolSqlServer' automatisch entzogen. Wir empfehlen daher, vorher einen Export der betroffenen Benutzer / Operator zu erstellen, da es nicht möglich ist, diesen Vorgang rückgängig zu machen.


Für den ersten Zugriff auf APROL-SQL stellt APROL jeweils einen vordefinierten SQL-Systembenutzer und einen SQL-Systemoperator bereit. Beide Accounts sind im Auslieferungszustand aktiviert.

Umgebung Benutzer / Operator Passwort

Engineering SqlSystemUser .SqlSystemUser Runtime SqlSystemOperator .SqlSystemOperator

Falls eine Authentifizierung über LDAP eingestellt ist, müssen diese User/Operatoren selbstverständlich auch im LDAP-Server angelegt sein.

Selbstverständlich können Benutzer / Operatoren in der Benutzer-Verwaltung / OperatorManager die oben genanten Recht zugewiesen bekommen.

Für genauere Informationen über die Benutzer- und Operator-Verwaltung lesen sie bitte die entsprechenden Abschnitte des Handbuchs 'B1 Engineering Umgebung', Kapitel Benutzer-Verwaltung und Operator-Verwaltung.

Bei APROL-WebReports mit Zugriff auf APROL-SQL-Daten, wie z.B. Auswertungen zu EnMon oder ConMon wird bei geforderter Authentifizierung der dann notwendigerweise anzugebene Benutzer / Operator mit seinem Passwort ausschließlich für den Zugriff auf den Report verwendet.

Bei Zugriff auf APROL-SQL-Daten mit Frendwerkzeugen, wie z.B. SQurreL muss somit ein als SqlSystemUser gekennzeichneter Benutzer / Operator angegeben werden. Dabei kann also der per Default bereit gestellte 'SqlSystemUser' bzw. 'SqlSystemOperator' oder ein eigens für diesen Zweck angelegter User/Operator verwendet werden.

8.2.2 Client-Verbindung mit ODBC Dieses Kapitel soll Ihnen das Wissen vermitteln, mit einem ODBC-fähigen Client-Programm eine Verbindung zum AprolSqlServer aufzubauen.

8.2.2.1 Installation des JDBC- und ODBC-Remotetreibers unter Linux Unter Linux werden die Konfigurationsanteile beim Build des CAE-Projekts automatisch erstellt und durch den Download verteilt. Die manuelle Traiber-Konfiguration ist nicht notwendig. ODBC-Treiber:

Zur Absicherung der Abfragen sollten somit die öffentlichen SqlSystemUser und SqlSystemOperator deaktiviert werden. Eine Änderung der Passworte ist nicht möglich.

ODBC-Treiber sind Systemarchitektur (z.B. 64-Bit Windows) spezifisch, sodass auf die Kompatibilität geachtet werden muss! Ein 32-Bit Client-Programm benötigt die 32-Bit Variante des Treibers und ein 64-Bit Programm die 64-Bit Variante.

APROL-SQL 9

Damit Linux-basierte und ODBC-fähige Client-Programme eine Verbindung zu einem AprolSqlServer aufbauen können, wird ein passender Treiber benötigt. Die Treiber sind vorinstalliert und befinden sich in den folgenden Pfaden: 32-Bit Version /opt/aprol/lib/SimbaEngine/client/libSimbaClient_unixODBC.so

64-Bit Version (Voraussetzung: 64-Bit APROL) /opt/aprol/lib64/SimbaEngine/client/libSimbaClient_unixODBC.so Dem Client-Programm fehlt nun die Pfadangabe zum Laden des korrekten Treibers. Diese Information wird in der Datei 'odbcinst.ini' hinterlegt. Die Konfigurationsdatei wird beim Generieren eines Projekts automatisch erzeugt, sodass keine manuelle Anpassung mehr notwendig ist. Nach einem Download steht diese auch den Zielsystemen zur Verfügung.

Die 'odbcinst.ini' ist APROL-Systemtypabhängig unter folgenden Pfaden zu finden:

Engineering-System: /home/<Engineering-System>/ENGIN/cnf/AprolSqlServer/odbcinst.ini

Runtime-System: /home/<Runtime-System>/RUNTIME/cnf/AprolSqlServer/odbcinst.ini

Manuelle Anpassungen werden ohne Rückfrage überschrieben!

Konfigurationsdatei odbc.ini: In der 'odbc.ini' Konfigurationsdatei werden alle verfügbaren Datenquellen definiert auf welches ein ODBC-fähiges Client-Programm zugreifen kann. Zusätzlich wird die zu verwendende Treiberversion spezifiziert. Die 'odbc.ini' wird beim Build des CAE-Projekts erzeugt. Hierbei wird das aktuelle Engineering-System und die Protokollserver aller zugehörigen Projekte in die Konfiguration geschrieben. Die Datei befindet sich anschließend im Pfad: /home/<Engineering-System>/ENGIN/cnf/AprolSqlServer/odbc.ini

Damit die Konfiguration auf allen Runtime-Systemen verfügbar ist, muss abschließend noch ein Download durchgeführt werden. Der Zielpfad auf jedem heruntergeladenen Runtime-System ist dann der Folgende: /home/<Runtime-System>/RUNTIME/cnf/AprolSqlServer/odbc.ini

Manuelle Anpassungen werden ohne Rückfrage überschrieben!

Verbindungsaufnahme mittels DSN: Für das Client-Programm ist bei einer Verbindungsaufnahme mit einem AprolSqlServer lediglich der Name der Datenquelle (Data Source Name) von Bedeutung. Alle weiteren Konfigurationsparameter können anhand dieser Information automatisch ermittelt werden. Dieser Name setzt sich wie folgt zusammen:

• Engineering-System (32- / 64-Bit Version) Engin_<Projektname>_32 Engin_<Projektname>

• Protokoll-Server (32- / 64-Bit Version)


Protocol_<Projektname>_32 Protocol_<Projektname>

Den Datenquellennamen können Sie auch direkt aus der 'odbc.ini' entnehmen. Er zeichnet sich als geklammerten Ausdruck aus (z.B. [Protocol_SamplesProject_32]).

8.2.2.2 Installation des JDBC- und ODBC-Remotetreibers unter Windows Damit JDBC- oder ODBC-fähige Client-Programme, unter Microsoft Windows eine Verbindung zu einem AprolSqlServer aufbauen können, wird ein jeweils passender Treiber benötigt. Mit Hilfe des mitgelieferten Windows-Installers können Sie diese installieren.

Pfad des Installers auf der APROL-DVD:

/windows_drivers_and_tools/AprolOdbcJdbcDriverSetup.exe

Abbildung 105: Eingabe von APROL-spezifischen Daten

Geben Sie den Hostnamen des Engineering-Systems oder des Protokoll-Servers ein.

Hostname or IP address ... <Hostname des Protokoll-Servers> oder

<Hostname des Engineering-Servers> oder <Globaler Cluster-Name/IP-Addresse>

Der vorgegebene Port ist unverändert zu lassen.

Name of your APROL project <Projektname>

Diese Information wird für die automatische Konfiguration des ODBC-Clients verwendet. Die notwendigen Windows Registry-Pfade werden daraufhin eingerichtet, sodass eine anschließende Verbindung mit dem Client-Programm möglich ist.

Ein Dialog mit den notwendigen APROL-spezifische Einstellungen der Clients wird am Ende der Installation angezeigt. Einstellungen durchlesen

Die manuelle Anpassung/Erweiterung wird im nachfolgenden Kapitel erläutert.

APROL-SQL 11

Nach der Installation befindet sich im Installationspfad eine Datei 'Install.txt' mit einem Verweis auf die vorliegende Dokumentation. Konfiguration einer Datenquelle für ODBC: Um eine ODBC-Datenquelle hinzuzufügen bzw. zu ändern, können Sie das Tool ODBC-Datenquellen-Administration'odbcad32.exe' verwenden.

Abbildung 106: ODBC Datenquellen Administrations-Tool

In einer 64-Bit Windows-Umgebung gibt es die folgenden Werkzeuge: C:\Windows\SysWOW64\odbcad32.exe (für 32-Bit Einstellungen)

C:\Windows\System32\odbcad32.exe (für 64-Bit Einstellungen)

Es handelt sich hierbei um zwei eigenständige Programme.

Sie müssen sowohl die 64-Bit als auch die 32-Bit Anwendung auf einem 64-Bit Windows-System ausführen, da jeweils die architekturabhängigen Registry-Pfade geschrieben werden. Nur so ist gewährleistet, dass Sie mit jedem ODBC-fähigen Clientprogramm eine Verbindung zum AprolSqlServer aufbauen können. In einer 32-Bit Windows-Umgebung gibt es das folgende Werkzeug: C:\Windows\System32\odbcad32.exe

Damit eine Verbindung unter Berücksichtigung der APROL spezifischen Eigenschaften passieren kann, sind zusätzliche Parameter einzutragen. Hierzu wählen Sie eine im 'System-


DSN' / 'Benutzer-DSN' Reiter befindliche Datenquelle aus und Öffnen den Konfigurations-Dialog. Als nächstes ist der Options-Dialog zu öffnen, in welchen Sie die folgenden Parameter eintragen müssen:

Abbildung 107: Dialog 'Client-Konfiguration'

Abbildung 108: Dialog 'Client-Konfiguration / Optionen'

Schlüssel: Wert:

PROJECT <CAE-Projekt der Datenquelle> SYSTEM Runtime-System: aprolsys

Engineering-System: <CC-Account der Datenquelle> UID User Identification (Benutzer-Identifikation)

PWD Zugehöriges Passwort des UID

APROL-SQL 13

Default Installationspfad ist C:\Program Files\APROL\AprolOdbcJdbcDriver Die SSL Zertifikatsdatei ist in folgendem Verzeichnis abgelegt: <Installationspfad>\SSLCertificates\ca.crt

Die Option 'Use SSL' muss in den 'Client-Konfiguration / Optionen' passend zum APROL SqlServer eingestellt sein!

8.2.3 Client-Verbindung mittels JDBC Dieses Kapitel soll Ihnen das Wissen vermitteln, mit einem JDBC-fähigen Programm eine Verbindung zum AprolSqlServer aufzubauen. Damit JDBC-fähige Client-Programme eine Verbindung zu einem AprolSqlServer aufbauen können, wird ein passender Treiber benötigt. Den notwendigen Treiber finden Sie in dem Pfad in welchem sich auch der ODBC-Treiber befindet (siehe Kapitel 'ODBC-Treiber' bzw. 'Installation des JDBC & ODBC-Remote Treibers'). Die Installation stellt JDBC3- und JDBC4-Treiber zur Verfügung.

Typ-3-Treiber Typ-3-Treiber eignen sich sehr gut für Internet-Protokolle im Zusammenhang mit Firewalls.

Typ-4-Treiber Typ-4-Treiber eignen sich gut für Intranet-Lösungen, die schnelle Netzprotokolle nutzen wollen. B&R empfiehlt die Verwendung von Typ-4-Treibern.

Neben der Angabe des Treibers wird eine JDBC-Verbindung über eine URL, die alle notwendigen Parameter enthält, hergestellt. Sie können die folgende Syntax in einem JDBC-Client-Programm verwenden und einfach die Tags '<>' mit den korrekten Werten versehen: Mit aktivierter SSL-Verschlüsselung (Default) ist die URL wie folgt aufgebaut:

• URL mit SSL-Verschlüsselung für Runtime-Daten jdbc:simba://<Hostname des Protokoll-Servers>:55503; SYSTEM=aprolsys;PROJECT=<Projektname>; UseSsl=1;TrustedStorePath=<Install path>\\SSLCertificates\\jdbckeystore; TrustedStorePassword=.aprol

• URL mit SSL-Verschlüsselung für Engineering-Daten jdbc:simba://<Hostname des Engineering-Servers>:55503; SYSTEM=<CC-Account des Engineering-Systems>;PROJECT=<Projektname>; UseSsl=1;TrustedStorePath=<Install path>\\SSLCertificates\\jdbckeystore; TrustedStorePassword=.aprol

Die Konfigurations-URL des JDBC-Treibers verlangt bei aktivierter SSL-Verschlüsselung die Angabe des vollständigen Domain Namens des SQL-Servers (Fully Qualified Domain Name (FQDN)).


Ohne aktivierte SSL-Verschlüsselung ist die URL wie folgt aufgebaut:

• URL für Runtime-Daten jdbc:simba://<Hostname des Protokoll-Servers>:55503; SYSTEM=aprolsys;PROJECT=<Projektname>

• URL für Engineering-Daten jdbc:simba://<Hostname des Engineering-Servers>:55503; SYSTEM=<CC-Account des Engineering-Systems>; PROJECT=<Projektname>

Der JAVA-Keystore mit den notwendigen Zertifikaten befindet sich in Abhängigkeit zum Betriebssystem in den folgenden Pfaden:

• Windows <Install path>\SSLCertificates\jdbckeystore

• Linux /opt/aprol/etc/jkeystore

Im KDE-Menü unter 'Werkzeuge' befindet sich das freie Abfragewerkzeug 'SQuirreL SQL Client' (http://squirrel-sql.sourceforge.net) mit welchem Sie eine erste Verbindung einrichten können. Es eignet sich hervorragend um eine Übersicht der angebotenen SQL-Tabellen einer verbundenen Datenquelle zu bekommen. Im Kapitel Verwendung von SQuirreL als Datenbank-Client finden Sie eine Kurzanleitung zum Verbindungsaufbau.

8.2.4 Verbindungen in Python und PHP Um den Zugriff auf den AprolSqlServer aus den gängigen Skriptsprachen Python und PHP zu ermöglichen, enthält die APROL-Installation bereits die benötigten Sprachmodule.

8.2.4.1 Python Unter Python kann das Modul 'pyodbc' zum SQL-Datenzugriff verwendet werden. Detaillierte Informationen zum Modul pyodbc erhalten sie auf dem pyodbc-Projektseite (https://code.google.com/p/pyodbc/). Beispiel: Abfrage von Daten aus der Tabelle Alarm der Datenquelle Protocol_SamplesProject.

Bitte beachten Sie, dass die URL keine überflüssigen Leerzeichen, z. B. vor oder nach einem Semikolon, enthalten darf.

http://squirrel-sql.sourceforge.net/

https://code.google.com/p/pyodbc/

APROL-SQL 15

#! /usr/bin/python # -*- coding: utf-8 -*- import pyodbc cnxn = pyodbc.connect('DSN=Protocol_SamplesProject;UID=SqlSystemOperator;PWD=.SqlSystemOperator') cursor = cnxn.cursor() cursor.execute("select * from base.Alarm where ts >= '2012-10-20'") row = cursor.fetchone() print '[0]:', row[0] # access by column index

8.2.4.2 PHP Für den SQL-Datenzugriff unter PHP kann das odbc-Modul von PHP verwendet werden. Um eine ODBC Verbindung aufzubauen muss der PHP-Umgebung der Pfad zur odbc.ini Datei in einer Umgebungsvariable bekannt gemacht werden (siehe Beispiel). Detaillierte Informationen zum Modul odbc unter PHP erhalten sie auf den PHP-Dokumentationsseiten (http://www.php.net/manual/de/book.uodbc.php). Beispiel: Abfrage von Daten aus der Tabelle Alarm der Datenquelle AprolSqlDemo über einen Webserver durch eine PHP-gestützte Webabfrage. <?php /*Setzen der Umgebungsvariable des AprolSqlServer; Pfad der odbc.ini*/ putenv('ODBCSYSINI=/opt/aprol/cnf/AprolSqlServer'); /*Aufbau der ODBC Verbindung.*/ $conn = odbc_connect('AprolSqlDemo', 'SqlSystemOperator', '. SqlSystemOperator '); $sql = "Select * from base.Alarm where ts >= '2012-10-20'"; $rs = odbc_exec($conn,$sql); while (odbc_fetch_row($rs)) { //Ansprechen des Ergebnisses über Index echo odbc_result($rs,6); //Ansprechen des Ergebnisses über Spaltennamen echo odbc_result($rs,'alias'); } odbc_close($conn); ?>

8.3 Den AprolSqlServer bedienen und konfigurieren Dieses Kapitel soll Ihnen das Wissen vermitteln, den AprolSqlServer zu bedienen, zu konfigurieren und die Logging-Informationen einsehen zu können.

8.3.1 Starten und Stoppen des Dienstes Um eine Konfigurationsänderung wirksam zu machen, kann es notwendig sein, den Dienst neu zu starten (z. B. nach Abschalten der SSL-Verschlüsselung).

http://www.php.net/manual/de/book.uodbc.php

http://www.php.net/manual/de/book.uodbc.php


Im Normalfall muss der Dienst nur gestoppt werden, da durch die Prozessüberwachung via 'Monit' nicht gestartete oder beendete Prozesse detektiert und anschließend neu gestartet werden. Zur manuellen Bedienung des Dienstes benötigen Sie die Rechte des Linux Superuser 'root'. Der Dienst befindet sich unter dem Pfad: /etc/init.d/aprolsqlserver

Die folgenden Optionen stehen Ihnen zur Verfügung: /etc/init.d/aprolsqlserver <Option>

Option Beschreibung

start Startet den Dienst stop Stoppt den Dienst restart Stoppt und Startet den Dienst status

Gibt den aktuellen Status wieder: • Status: running – Der AprolSqlServer ist einsatzbereit. • Status: unused – Der AprolSqlServer ist heruntergefahren.

ls weiteres Mittel zur Statusübersicht steht Ihnen der APROL System Diagnostics Manager zur Verfügung.

8.3.2 Port-Konfiguration Die Konfiguration des AprolSqlServer wird einmalig beim Starten eingelesen. Sollte eine Anpassung der Konfiguration erforderlich sein, so ist der Server auf dem bereits erwähnten Weg zu stoppen und anschließend neu zu starten. Die Konfigurationsdatei finden Sie unter dem Pfad: /opt/aprol/cnf/AprolSqlServer/aprolsqlserver.ini

APROL-SQL 17

Abbildung 109: Datei 'aprolsqlserver.ini

Der Standardport, unter welchem der Dienst erreichbar ist, lautet 55503. Sie finden diese Angabe in der Konfigurationsdatei unter der Rubrik '[Network]', 'ListenPort=55503'.

Hinweise bei Änderung der Default-Portnummer:

Falls Sie die Portnummer (Default: 55503) wegen etwaiger Netzwerk-Restriktionen ändern müssen, sind auch die Firewall Konfigurationsdateien entsprechend anzupassen. Detailinformationen hierzu finden Sie im Handbuch 'A2 Getting Started', Kapitel Optionale Anpassungen der Firewall.

Die Portnummer des APROL SQL-Servers muss ebenfalls angepasst werden. Editieren Sie hierzu die Datei /opt/aprol/cnf/AprolSqlServer/aprolsqlserver.ini und starten Sie anschließend den APROL SQL-Server neu. Dies muss als Linux-Benutzer 'root' mit dem Befehl /etc/init.d/aprolsqlserver restart erfolgen.

8.3.3 Konfiguration der Verbindungsverschlüsselung Die Datenübertragung zwischen dem Abfrage-Client und dem APROL-SQL-Server wird standardmäßig mit SSL-Verschlüsselung durchgeführt. Die SSL-Verschlüsselung wird in der folgenden Datei eingestellt: /opt/aprol/cnf/AprolSqlServer/aprolsqlserver.ini

Option Beschreibung

UseSsl 0 : Verschlüsselung deaktiviert 1 : Verschlüsselung aktiviert


Option Beschreibung

SslCertfile Zertifikat SslKeyFile Privater Schlüssel

8.3.4 Logging Alle Bedienvorgänge werden in der folgenden Log-Datei abgelegt. /var/log/AprolSqlServer.err

Zusätzlich werden abgesetzte SQL-Abfragen, Fehler und Warnungen in den APROL 'Systemmeldungen'-Report abgelegt, welche auch über die SQL-Tabelle 'Systemmessage' abrufbar sind. Hierzu mehr im Kapitel Vordefinierte SQL-Tabellen.

8.4 APROL SQL-Tabellen .

8.4.1 Vordefinierte SQL-Tabellen Dieses Kapitel enthält eine detaillierte Auflistung aller vordefinierten System-Tabellen.

Tabellenname Beschreibung

Alarm Die Tabelle enthält alle historischen Informationen von protokollierten Alarmereignissen wie z.B. das Auftreten, die Quittierung und das Gehen eines Alarms. Anhand der Verwendung der Datenfelder kann eine benutzerdefinierte Darstellung der Alarmereignisse erfolgen.

CaeUpdate Die Tabelle enthält alle historischen Informationen für die Protokollierung der Updatevorgänge der CAE-Datenbank.

Changelog Die Tabelle enthält die historischen Informationen der Protokollierungsdaten aller relevanten Benutzeraktionen in der APROL Engineering-Umgebung.

Compressor Die Tabelle enthält alle historischen Informationen für die Protokollierung verdichteter Daten. Hierzu gehört auch die Korrektur aufgezeichneter Werte (Vergabe von Ersatzwerten).

Download Die Tabelle enthält alle historischen Informationen für die Protokollierung und Analyse aller durchgeführten Download-Vorgänge.

Parameter Die Tabelle enthält alle historischen Informationen für die Protokollierung der durchgeführten Download- / Upload-Vorgänge von Parametersätzen im ParameterCenter.

SFC Die Tabelle enthält alle historischen Informationen zur Auswertung von deklarierten und verwendeten SFC-Kontrollvariablen für die Bereitstellung von Zusatzfunktionalitäten (z.B. Zeitüberwachung von Schritten) in SFC-Programmen und -Funktionsblöcken. Zudem umfasst

APROL-SQL 19

Tabellenname Beschreibung die Tabelle alle historischen Informationen für die Protokollierung von SFC-Ablaufdaten. Hierzu gehören u.a. Start, Init, Reset und Pause eines SFC, das Schalten einer Transition oder das Erreichen der maximalen Verweildauer.

Shiftlog Die Tabelle enthält alle historischen Informationen für die Protokollierung von Schichtlogbucheinträgen. Das APROL Schichtlogbuch ermöglicht dem Operator alle relevanten Ereignisse zur Prozessführung und danach ggf. eingeleitete Aktionen in elektronischer Form festzuhalten.

Sysconf Die Tabelle enthält die historischen Informationen für die Beschreibung aller relevanten Konfigurationsänderungen. Hierzu gehören z. B. Konfigurationsvorgänge in den Bereichen NTP, ChronoPlex oder VNC.

Syssetup Die Tabelle enthält die historischen Informationen für die Protokollierung aller vorgenommenen Installationsvorgänge.

Systemmessage Die Tabelle enthält die historischen Informationen für die Protokollierung aller relevanten APROL Systemmeldungen. Die APROL Systemmeldungen der GUI-Anwendungen, Hintergrundprogramme und Skripte ermöglichen eine komfortable und flexible Auswertung zu Diagnosezwecken.

SystemmessageANSL Die Tabelle enthält die historischen Informationen für die Protokollierung aller ANSL-Systemmeldungen. Anhand dieser Systemmeldungen können bei der Verwendung des ANSL-Treibers zur Kommunikation mit (redundanten) Controllern mögliche Fehlerursachen schnell und einfach ermittelt werden.

Trend Die Tabelle enthält die historischen Informationen für die Auswertung von Daten der aufgezeichneten Trendereignisse.

TrendComment Die Tabelle enthält alle historischen Informationen zu erfassten Kommentaren von aufgezeichneten Trendereignissen.

UseractionAlarm Die Tabelle enthält die historischen Informationen für die Protokollierung von AuditTrail-Einträgen zum Alarm Management. Hierzu gehören u.a. das Quittieren, Freigeben und Sperren von Alarmen.

UseractionClogmodify Die Tabelle enthält alle historischen Informationen für die Protokollierung von AuditTrail-Einträgen zur Modifikation von Protokolldaten.

UseractionController Die Tabelle enthält alle historischen Informationen für die Protokollierung von AuditTrail-Einträgen zum Controller Management. Hierzu gehören u.a. das Starten und Stoppen von Controller-Tasks, der Download einer Controller AR-OS Version und das Verschieben oder Löschen von Controller-Modulen.

UseractionExt Die Tabelle enthält alle historischen Informationen für die Protokollierung von AuditTrail-Einträgen zur externen Prozessführung. Hierzu gehören u.a. das Setzen von Werten durch externe Anwendungen sowie das Starten und Stoppen des Signalgenerators.

UseractionLogin Die Tabelle enthält alle historischen Informationen für die Protokollierung von AuditTrail-Einträgen zum Security Login (d.h. Login- und Logout-Vorgänge).


Tabellenname Beschreibung

UseractionParameter Die Tabelle enthält alle historischen Informationen für die Protokollierung von AuditTrail-Einträgen zur Parameter Historie (d.h. Parameter-Upload und Download).

UseractionPic Die Tabelle enthält alle historischen Informationen für die Protokollierung von AuditTrail-Einträgen zur Prozessführung. Hierzu gehören u.a. vorgenommene Schalthandlungen, das Öffnen und Schließen von Grafikmakros sowie der Alarmliste und das Modifizieren von Filtereinstellungen der Alarmliste.

UseractionSFC Die Tabelle enthält alle historischen Informationen für die Protokollierung von AuditTrail-Einträgen zu SFC Eingriffen. Hierzu gehören u.a. die Einstellung des Controlled-Mode, Setzen des SFC-Init / -Reset / -Pause sowie der Tip-Modus und das Forcen des SFC.

UseractionSys Die Tabelle enthält alle historischen Informationen für die Protokollierung von AuditTrail-Einträgen zur Systemsteuerung. Hierzu gehören u.a. das Starten und Stoppen des APROL-Systems und das Starten und Stoppen von Anwendungen.

Tabelle: Alarm Die Tabelle enthält alle historischen Informationen von protokollierten Alarmereignissen wie z.B. das Auftreten, die Quittierung und das Gehen eines Alarms. Anhand der Verwendung der Datenfelder kann eine benutzerdefinierte Darstellung der Alarmereignisse erfolgen.

Spaltenname (Chronolog-Attribut)

SQL-Typ Beschreibung

ack_text (acktext) VARCHAR Quittieriungstext

ack_ts (ackts) TIMESTAMP Zeitstempel der Quittierung

alias VARCHAR Alias-Name eines Alarms in der Quellsprache

begin_ts (begin) TIMESTAMP Zeitstempel des Kommens eines Alarms (bei 'Gehen'-Events)

comment VARCHAR Kommentar zum Alarm

display VARCHAR Display Bezeichnung

duration DOUBLE Dauer des Anstehens eines Alarms

end_ts (end) TIMESTAMP Zeitstempel des Gehen eines Alarms (bei 'Kommen'-Events)

flags VARCHAR Kennung des Alarm-Datensatzes [Typ][Eigenschaft][Kennung] Typ: A=alarm M=message Eigenschaft: B=Kommen eines Alarms/Meldung E=Gehen eines Alarms/Meldung Q=Bestätigungseintrag

APROL-SQL 21



L=Alarm gespert R=Alarm freigegeben Kennung: 1=Alarm benötigt keine Quittierung 2=Alarm benötigt Quittierung 3=Alarm ist quittiertextpflichtig

group VARCHAR Alarmgruppe

host VARCHAR APROL Computername

ivtext VARCHAR Dateiname für Interventionstext

multi INTEGER Mehrfach auftretender Alarm (Anzahl)

priority INTEGER Alarmpriorität

project VARCHAR Projektname

pv VARCHAR Name der Prozessvariable

system VARCHAR CC-Account

system_inst VARCHAR Runtime-System Instanz des zugehörigen Alarmbausteins

system_name VARCHAR Runtime-System Name des zugehörigen Alarmbausteins

text VARCHAR Alarmtext

tr_alias (tralias) VARCHAR Alias-Name eines Alarms in der Projektierungsprache

ts TIMESTAMP Zeitstempel des Alarm-Datensatzes

ts_switch_mark (nur SQL)

VARCHAR(1) Schalter für die Umschaltung von Sommerzeit in Winterzeit 0 = keine Umschaltung erfolgt B = Stunde nach der Umschaltung

username (user) VARCHAR Operator-Kontoname

Tabelle: CaeUpdate Die Tabelle enthält alle historischen Informationen für die Protokollierung der Updatevorgänge der CAE-Datenbank.




end_ts (end) TIMESTAMP Zeitstempel des Endes eines CAE-Updates

errors INTEGER Anzahl an Fehlern

firstname VARCHAR Vorname des Benutzers





loglevel (level) INTEGER Log-Level

message VARCHAR Meldungstext

messagetype VARCHAR Meldungstype: error | warning | message | stepBegin | stepEnd

newaprolrelease VARCHAR APROL Release nach CAE-Update

newdbversion VARCHAR Datenbankversion nach CAE-Update

oldaprolrelease VARCHAR APROL Release vor CAE-Update

olddbversion VARCHAR Datenbankversion vor CAE-Update

start_ts (start) TIMESTAMP Zeitstempel des Beginns eines CAE-Updates

stepname VARCHAR Schrittbezeichnung eines CAE-Updateschrittes

success BIT Erfolgskennung eines CAE-Updates

surname VARCHAR Nachname des Benutzers


ts TIMESTAMP Zeitstempel des CAE-Update-Datensatzes


VARCHAR(1) Standard time / daylight saving time 0 = no switch A = hour before switch B = hour after switch


warnings INTEGER Anzahl an Warnungen

Tabelle: Changelog Die Tabelle enthält die historischen Informationen der Protokollierungsdaten aller relevanten Benutzeraktionen in der APROL Engineering-Umgebung.



actionsource VARCHAR Aktionsgruppe

actiontype VARCHAR Durchgeführte Aktion

addasbuiltdatarerestore BIT Backup von As-Build Dokumentation durchführen

addcustomerdatarestore BIT Backup von Customer Daten durchführen

addgenerateddatarestore BIT Backup generierter Daten durchführen

application VARCHAR Anwendungssname (Download)

aprolrelease VARCHAR APROL-Releasebezeichnung

APROL-SQL 23



backupfile VARCHAR Name der Backup-Datei

command VARCHAR Abgegebenes Systemkommando

dbelapsetime BIT Datenbank-Optimierung: Generierungszeiten entfernen

dbinstance BIT Datenbank-Optimierung: Unreferenzierte Instanzen entfernen

dbk BIT Wiederherstellung der Controller Adressdatenbank durchführen

dbofflineref BIT Datenbank-Optimierung: Löschen ungültiger Offline-Referenzen

dbtrash BIT Datenbank-Optimierung: Papierkorb leeren

dbuserdata BIT Datenbank-Optimierung: Alte Benutzerdaten löschen

dbver BIT Datenbank-Optimierung: Alte Versionen löschen

destination VARCHAR APROL Ziel CC-Account (Download)


dstppname VARCHAR APROL Zielsystem. Name des Projektierungsteils (Download)

dsttype VARCHAR APROL Zielsystem-Typ (Download)

errors INTEGER Anzahl an Fehlern



jobno VARCHAR Auftragsnummer

key VARCHAR Eindeutiger Key eines Downloads

oldpath VARCHAR Alter Pfad zum Projektierungsteil

oldversion VARCHAR Alte Version des Projektierungsteils

path VARCHAR Pfad zum Projektierungsteil


pvn VARCHAR Instanzname (Download)

restorefile VARCHAR Name der Wiederherstellungs-Datei

restorepath VARCHAR Pfad zur Wiederherstellungs-Datei

source VARCHAR APROL Quell-CC-Account (Download)

srcppname VARCHAR APROL Quellsystem-Name (Download)




start TIMESTAMP Zeitstempel Start Download

success BIT Erfolgskennung (Download)



ts TIMESTAMP Zeitstempel des Datensatzes




usermode VARCHAR Benutzerkennung (Engineering-Benutzer | Runtime-Benutzer) - veraltet

version VARCHAR Versionsnummer des Projektierungsteils

warnings INTEGER Anzahl an Warnungen

Tabelle: Compressor Die Tabelle enthält alle historischen Informationen für die Protokollierung verdichteter Daten. Hierzu gehört auch die Korrektur aufgezeichneter Werte (Vergabe von Ersatzwerten).



average (avg) DOUBLE Durchschnittswert im Kompressionszeitraum

maximum (max) DOUBLE Maximum im Kompressionszeitraum

minimum (min) DOUBLE Minimum im Kompressionszeitraum

modified BIT Indikator: Wert geändert

compression (prefix)

VARCHAR Verdichtungsintervall






val DOUBLE Wert

validity DOUBLE Validierung

APROL-SQL 25

Tabelle: Download Die Tabelle enthält alle historischen Informationen für die Protokollierung und Analyse aller durchgeführten Download-Vorgänge.



jobno INTEGER Auftragsnummer

uuid (key) VARCHAR Eindeutige ID

level INTEGER Ausgabe-Level

message VARCHAR Meldungstext


pvn VARCHAR Downloadziel

source INTEGER Download-Quelle 1,2=DownloadManager 3=ControllerManager 4=ControllerLoader 5=System




type INTEGER Meldungstype: 1=Meldung 2=Erfolg 3=Systemkommando 4=Benutzer Interaktion 5=Warnung 6=Fehler

Tabelle: Parameter Die Tabelle enthält alle historischen Informationen für die Protokollierung der durchgeführten Download- / Upload-Vorgänge von Parametersätzen im ParameterCenter.



paramaction (action)

VARCHAR Parameter Management Aktion

at VARCHAR Anlagenteil-Instanz

connected VARCHAR Verbindungsstatus

description (desc) VARCHAR Beschreibung

dflt VARCHAR Standard Wert (Default)





enginmode BIT Benutzer war Engineering-Benutzer

firstname VARCHAR Vorname des Operators

fix BIT Wert kann bei 'TRUE' im Runtime nicht geändert werden


maximum (max) VARCHAR Maximum

minimum (min) VARCHAR Minimum

modified BIT Modifiziert

name VARCHAR Parametername

oldvalue VARCHAR Alter Wert

paramset VARCHAR Name des Parameter-Satzes


pvname VARCHAR Name der Prozessvariable

set BIT Parameter download: Parameterwert im Iosys gesetzt Parameter upload: Parameterwert aus dem Iosys im Parametersatz gesetzt

superuser BIT Benutzer war APROL-Superuser

surname VARCHAR Nachname des Operators

template VARCHAR Name des Parameter-Templates




tsrc VARCHAR Quelle der Änderung (z.B. Surface, system)

type VARCHAR IEC-Typ


valid VARCHAR Validität des Wertes

val (value) VARCHAR Aktueller Wert

Tabelle: SFC Die Tabelle enthält alle historischen Informationen zur Auswertung von deklarierten und verwendeten SFC-Kontrollvariablen für die Bereitstellung von Zusatzfunktionalitäten (z.B. Zeitüberwachung von Schritten) in SFC-Programmen und -Funktionsblöcken. Zudem umfasst

APROL-SQL 27

die Tabelle alle historischen Informationen für die Protokollierung von SFC-Ablaufdaten. Hierzu gehören u.a. Start, Init, Reset und Pause eines SFC, das Schalten einer Transition oder das Erreichen der maximalen Verweildauer.



begin VARCHAR Beginn Zeitstempel (Init)

class VARCHAR Daten Klasse: flow = Ablaufdaten control = Steuerdaten conext = Kontextdaten

cmode BIT Status SFC-Controlled-Mode

controller VARCHAR Controllername bzw IP-Adresse

cvset BIT Steuerung durch die Logik (FALSE) oder SFCViewer (TRUE)

duration FLOAT Zeitdauer zur letzten Aktivierung des init-Schrittes

event VARCHAR SFC-Event-Typ

force VARCHAR Force-Mode: aktiv: aktiv geforced inaktiv: inaktiv geforced off: nicht geforced


instance VARCHAR SFC-Objekt-Instanz

object VARCHAR SFC-Objekttyp

objectname VARCHAR SFC-Objektname

pause FLOAT Zeitdauer des Pausierens eines SFC


projectpath VARCHAR Projekt-Pfad des SFC

sfcname VARCHAR SFC-Name

smode BIT Ansteuerungsstatus eines SFC Schrittes

system_inst VARCHAR Runtime-System Instanz des zugehörigen Controllers

system_name VARCHAR Runtime-System Name des zugehörigen Controllers

systemvariables BIGINT UNSIGNED

Bitcodierte Angabe der gesetzten Kontrollvariable

task VARCHAR Taskname







value VARCHAR Sammelattribut (Die Bedeutung dieses Attributes sich ändert je nach dem welchen Wert das Attribute 'event' hat): Stellt passend zum event den Eventstatus an

Tabelle: Shiftlog Die Tabelle enthält alle historischen Informationen für die Protokollierung von Schichtlogbucheinträgen. Das APROL Schichtlogbuch ermöglicht dem Operator alle relevanten Ereignisse zur Prozessführung und danach ggf. eingeleitete Aktionen in elektronischer Form festzuhalten.



category VARCHAR Pfadangabe der Kategorie eines Schichtlogbuch-Eintrages

confirm VARCHAR Besttätigungs-Zeitstempel

confirmtext VARCHAR Bestätigungstext

confirmuser VARCHAR Operator-Kontoname des bestätigenden Operators

host VARCHAR APROL Computer-IP

message VARCHAR Meldungstext eines Schichtlogbuch-Eintrages

msgid VARCHAR Eindeutige ID des Datensatzes

mustconfirm BIT Flag ob Bestätigung eines Schichtlogbuch-Eintrages erforderlich ist

parentid VARCHAR Kennung des Elterndatensatzes


server VARCHAR APROL Computername

subject VARCHAR Thema eines Schichtlogbuch-Eintrages




type VARCHAR Typ des Knotens (z.B. parent)


APROL-SQL 29

Tabelle: Sysconf Die Tabelle enthält die historischen Informationen für die Beschreibung aller relevanten Konfigurationsänderungen. Hierzu gehören z. B. Konfigurationsvorgänge in den Bereichen NTP, ChronoPlex oder VNC.



aspect VARCHAR AprolConfig Aspect


messagetype VARCHAR Meldungstype: info_global = Meldung warning = Warnung error = Fehler

newval VARCHAR Neuer Wert

oldval VARCHAR Alter Wert

pid INTEGER Prozess-ID

rel VARCHAR APROL-Releasebezeichnung

script VARCHAR Name der schreibenden Anwendung mit Präfix 'script_'


text VARCHAR Meldungstext

timekey VARCHAR UNIX-Zeitstempel




username (user) VARCHAR Benutzername

Tabelle: Syssetup Die Tabelle enthält die historischen Informationen für die Protokollierung aller vorgenommenen Installationsvorgänge.



aspect VARCHAR AprolConfig Aspect


messagetype VARCHAR Meldungstype: info_global = Meldung warning = Warnung error = Fehler







rel VARCHAR APROL-Releasebezeichnung




timekey VARCHAR UNIX-Zeitstempel




username (user) VARCHAR Benutzername

Tabelle: Systemmessage Die Tabelle enthält die historischen Informationen für die Protokollierung aller relevanten APROL Systemmeldungen. Die APROL Systemmeldungen der GUI-Anwendungen, Hintergrundprogramme und Skripte ermöglichen eine komfortable und flexible Auswertung zu Diagnosezwecken.



application VARCHAR Name der schreibenden Anwendung

debugid VARCHAR Debug-ID

debuglevel INTEGER Nummer des Debug-Levels



job VARCHAR Auftragsnummer

last_ts (last) TIMESTAMP Zeitstempel des letzten Auftretens eines wiederholenden Systemmeldungs-Eintrags

messagetype VARCHAR Meldungstype: systemstate_start = Start eines APROL-System systemstate_stop = Stop eines APROL-System systemstate_info = APROL-System-Informationen systemstate_error = APROL System Fehler systemstate_redu = APROL System Redundanz

APROL-SQL 31



info_startup = Anwendung gestartet info_shutdown = Anwendung gestoppt info_internal = Interner Meldung info_global = Meldung info_hint = Hinweis info_success = Erfolgsmeldung warning = Warnung warning_high = Warnung hoher Priorität warning_low = Warnung niedriger Priorität error = Fehler debug = Debugging-Eintrag


repeated BIT Wiederholte Meldung (Anzahl des Auftretens)


success BIT Erfolgskennung



tid VARCHAR Thread-ID (Multithreading)




uniq VARCHAR ID eines Build-Vorgangs

Tabelle: SystemmessageANSL Die Tabelle enthält die historischen Informationen für die Protokollierung aller ANSL-Systemmeldungen. Anhand dieser Systemmeldungen können bei der Verwendung des ANSL-Treibers zur Kommunikation mit (redundanten) Controllern mögliche Fehlerursachen schnell und einfach ermittelt werden.




cpu_name VARCHAR Bezeichnung der CPU


error VARCHAR Fehlermeldung

eventtype VARCHAR Event-Typ





level INTEGER ANSL-Level

messagetype VARCHAR Meldungstype: ansl_error = ANSL Fehler ansl_info = ANSL Meldung

modul_name VARCHAR Modulname

object_id VARCHAR Objekt-ID

object_name VARCHAR Objektname

object_type VARCHAR Objekt-Typ

objecttype VARCHAR Objekt-Typ




tid VARCHAR Thread-ID (Multithreading)




Tabelle: Trend Die Tabelle enthält die historischen Informationen für die Auswertung von Daten der aufgezeichneten Trendereignisse.







value DOUBLE Wert der Prozessvariable

APROL-SQL 33

Tabelle: TrendComment Die Tabelle enthält alle historischen Informationen zu erfassten Kommentaren von aufgezeichneten Trendereignissen.







text VARCHAR Kommentartext





Tabelle: UseractionAlarm Die Tabelle enthält die historischen Informationen für die Protokollierung von AuditTrail-Einträgen zum Alarm Management. Hierzu gehören u.a. das Quittieren, Freigeben und Sperren von Alarmen.



acktext VARCHAR Quittieriungstext des Alarms

action VARCHAR Durchgeführte Schalthandlung des Operators aus der Gruppe der Alarmaktionen.

alias VARCHAR Alarm Alias


enginmode BIT Operator war Engineering-Benutzer


alarmgroup (group)

VARCHAR Alarmgruppe des betroffenen Aktion



pv VARCHAR Name der Prozess-Variablen

superuser BIT Operator war APROL-Superuser





system_inst VARCHAR Runtime-System Instanz des zugehörigen Alarmbausteins

system_name VARCHAR Runtime-System Name des zugehörigen Alarmbausteins

text VARCHAR Alarmtext





Tabelle: UseractionClogmodify Die Tabelle enthält alle historischen Informationen für die Protokollierung von AuditTrail-Einträgen zur Modifikation von Protokolldaten.



action VARCHAR Modifikation von Protokolldaten

category VARCHAR Kategorie





name VARCHAR Controller-Variablenname


rdate VARCHAR Zeitstempel der Änderung von Controller-Variablenwerten

reason VARCHAR Grund der Änderung eines Controller-Variablenwertes



system_inst VARCHAR Runtime-System Instanz des aufzeichnenden Bausteins.

system_name VARCHAR Runtime-System Name des aufzeichnenden Bausteins

text VARCHAR Änderungen an die Werte der Controller-Variablen


ts_switch_mark VARCHAR(1) Standard time / daylight saving time

APROL-SQL 35



(nur SQL) 0 = no switch A = hour before switch B = hour after switch


valid BIT Gültigkeitskennung

Tabelle: UseractionController Die Tabelle enthält alle historischen Informationen für die Protokollierung von AuditTrail-Einträgen zum Controller Management. Hierzu gehören u.a. das Starten und Stoppen von Controller-Tasks, der Download einer Controller AR-OS Version und das Verschieben oder Löschen von Controller-Modulen.



action VARCHAR Schalthandlung des Operators aus der Gruppe der Controlleraktionen.

class VARCHAR Taskklasse

connection VARCHAR Verbindungsparameter

controller VARCHAR Controllername bzw IP-Adresse

controlleraddress VARCHAR Controlleradresse

cycles VARCHAR Taskzyklen

destmemtype VARCHAR Zielspeicher (z.B. USERROM)


duration VARCHAR Dauer des Verbindungsaufbaus [ms]

end_time VARCHAR Zeitpunkt des Endes der Aktion


errorcode VARCHAR Fehlerkennung


forceval VARCHAR Geforcte- (force) Wert


iotype VARCHAR I/O-Typ

memtime VARCHAR Speicher-Typ

mode VARCHAR Copy-Mode für Controller (EI-Mode; Overload-Mode)

modules VARCHAR CPU-Modulname

name VARCHAR Controller-Variablenname




newforcedstate VARCHAR Aktueller Force Status

newtime VARCHAR Alter Zeitwert (bei Zeitänderungen auf dem Controller)


oldtime VARCHAR Neuer Zeitwert (bei Zeitänderungen auf dem Controller)


originalval VARCHAR Originalwert

path VARCHAR Variablenname

pid VARCHAR Prozess-ID


pv_name VARCHAR Name der Prozessvariable

res_addr VARCHAR Resultierende Verbindung

sel_addr VARCHAR Ausgewählte Verbindung

size VARCHAR Größe der kopierten Daten

sourcememtype VARCHAR Quellspeicher

start_time VARCHAR Zeitpunkt des Beginns der Aktion






task VARCHAR Taskname




type VARCHAR Art eines Controller-Restarts


version VARCHAR Versionsnummer

APROL-SQL 37

Tabelle: UseractionExt Die Tabelle enthält alle historischen Informationen für die Protokollierung von AuditTrail-Einträgen zur externen Prozessführung. Hierzu gehören u.a. das Setzen von Werten durch externe Anwendungen sowie das Starten und Stoppen des Signalgenerators.



action VARCHAR Ausgeführte externe Aktion extsetval = Setzen einer Wertes extsgstart = Start des Signalgenerators extsgstop = Stoppen des Signalgenerastors


changed BIT Flag ob Änderung durchgeführt


enginmode BIT Variable im Engineering Modus gesetzt



iosys VARCHAR Durchführender Iosys

lastval VARCHAR Letzter (alter) Wert

name VARCHAR Name der Prozess-Variablen

parameter VARCHAR Startparameter für externen Prozess


pv VARCHAR Name der Prozess-Variablen

remotehost VARCHAR Remote-Verbindung

sgtype VARCHAR Datentyp der vom Signalgenerator erzeugten Daten (IosDiagnosticManager)

sourced BIT Flag ob Variable versorgt



system_inst VARCHAR Runtime-System Instanz der geänderten Prozessvariable

system_name VARCHAR Runtime-System Name der geänderten Prozessvariable





val VARCHAR (Neuer) Wert




valid BIT Flag ob Variable valide

Tabelle: UseractionLogin Die Tabelle enthält alle historischen Informationen für die Protokollierung von AuditTrail-Einträgen zum Security Login (d.h. Login- und Logout-Vorgänge).



action VARCHAR Schalthandlung des Operators aus der Gruppe der Authentifizierungsaktionen.

device VARCHAR Loginmethode (Hardware)





idle BIT Logout wegen Inaktivität des Operators


shutdown BIT Logout wegen Herunterfahren des Rechners




system_inst VARCHAR Instanz des zugeordneten Runtime-System

system_name VARCHAR Name des zugewiesenen Runtime-System





APROL-SQL 39

Tabelle: UseractionParameter Die Tabelle enthält alle historischen Informationen für die Protokollierung von AuditTrail-Einträgen zur Parameter Historie (d.h. Parameter-Upload und Download).



action VARCHAR Schalthandlung des Operators aus der Gruppe der Parameteraktionaktionen.

changed BIT Änderungsflag (Parameter geändert)

parametercount (count)

VARCHAR Anzahl der Parameters





modcnt VARCHAR Anzahl geänderter Parameter

paramset VARCHAR Name des Parameter-Satzes




system_inst VARCHAR Instanz des Runtime-Systems welcher die Prozessvariable geändert hat

system_name VARCHAR Namen des Runtime-Systems welcher die Prozessvariable geändert hat

template VARCHAR Name des Parameter-Templates




tsrc VARCHAR Quelle der Anfrage commandline = Kommandozeilenaufruf surface = Oberflächenaufruf



Tabelle: UseractionPic Die Tabelle enthält alle historischen Informationen für die Protokollierung von AuditTrail-Einträgen zur Prozessführung. Hierzu gehören u.a. vorgenommene Schalthandlungen, das Öffnen und Schließen von Grafikmakros sowie der Alarmliste und das Modifizieren von Filtereinstellungen der Alarmliste.



action VARCHAR Schalthandlung des Operators aus der Gruppe der Prozessbildaktionen.

active BIT Alarmfilterstatus (aktiv | inaktiv)

authfail VARCHAR Grund einer Fehl-Authentifizierung im Vier-Augen-Prinzip

authmode INTEGER Modus der Authentifizierung im Vier-Augen-Prinzip

block VARCHAR Bausteinname

closemacros BIT Grafikmakros wurden geschlossen da ein Prozessgrafik geschlossen wurde.

commituser VARCHAR Login des zweiten Operators im Vier-Augen-Prinzip




groupfilter VARCHAR Gruppen eines gesetzten Gruppenfilters


lastval VARCHAR Letzter Wert

name VARCHAR Variablenname

notackfilter BIT Ein bei einer Alarmfilterung gesetzter 'Logikfilter' Wird TRUE, wenn der Operator nur 'nicht quittierte' Alarme gefiltert hat.

picture VARCHAR Prozessgrafikname

picturedesc VARCHAR Prozessgrafik Beschreibungstext

pin VARCHAR Name der Blockpin

priofilter VARCHAR Prioritätsfilter setzen


pvfilter VARCHAR PC Filter regex (regular expression)



system_inst VARCHAR Runtime-System Instanz des zugehörigen Grafikbausteins bzw. Prozessgrafik

system_name VARCHAR Runtime-System Name des zugehörigen Grafikbausteins

APROL-SQL 41



bzw. Prozessgrafik

text VARCHAR Abgegebenes Systemaufruf





val VARCHAR Aktueller Wert

verifycomment VARCHAR Bestätigungskommentar

verifytext VARCHAR Bestätigungstext

Tabelle: UseractionSFC Die Tabelle enthält alle historischen Informationen für die Protokollierung von AuditTrail-Einträgen zu SFC Eingriffen. Hierzu gehören u.a. die Einstellung des Controlled-Mode, Setzen des SFC-Init / -Reset / -Pause sowie der Tip-Modus und das Forcen des SFC.



action VARCHAR Schalthandlung des Operators aus der Gruppe der SFC-Aktionen.






instance VARCHAR SFC-Instanz

objectname VARCHAR SFC-Objektname

objecttype VARCHAR SFC-Objekttyp













val (value) INTEGER Aktueller Wert

Tabelle: UseractionSys Die Tabelle enthält alle historischen Informationen für die Protokollierung von AuditTrail-Einträgen zur Systemsteuerung. Hierzu gehören u.a. das Starten und Stoppen des APROL-Systems und das Starten und Stoppen von Anwendungen.



APROL-Superuser VARCHAR Operator war APROL-Superuser

action VARCHAR Schalthandlungen aus der Gruppe der System-Aktionen.


command VARCHAR Abgegebenes Systemkommando

connectedhost VARCHAR Verbundener Server (Download)

connectedsystem VARCHAR Verbundenes System (Download)

destination VARCHAR Downloadziel


dstppname VARCHAR Downloadziel (Name des Projektierungsteils)

dsttype VARCHAR Art des Systems (Download)


errors VARCHAR Anzahl an aufgetretene Fehlern



jobno VARCHAR Auftragsnummer

level VARCHAR Init-level mit sysinitaprol


source VARCHAR Download-Quelle

srcppname VARCHAR Downloadquelle (Name des Projektierungsteils)

start TIMESTAMP Zeitstempel Start Download

APROL-SQL 43



subtarget VARCHAR Ausgewählte Sub-Targets eines Downloadziels

success BIT Erfolgskennung



system_inst VARCHAR Instanz des angesteuerten Runtime-System

system_name VARCHAR Name des angesteuerten Runtime-System

text VARCHAR Statusinformation zum Hostwechsel (altes/neues Projekt), (alter/neuer Rechner), (alter/neuer CC-Account)





usermode VARCHAR Benutzer-Mode-Kennung (Engineering-Benutzer Kennung) - veraltet

warnings VARCHAR Anzahl an aufgetretene Warnungen

8-1

8.4.2 JSON-Tabellenschema Dateien Dieses Kapitel soll Ihnen das Wissen vermitteln, den Unterschied zwischen dynamischen und statischen SQL-Tabellen zu verstehen. Wie bereits in der Einleitung erwähnt, werden historische Daten in der ChronoLog-Datenbank abgespeichert. Die hier abgelegten Daten sind streng chronologisch angeordnet und besitzen keine SQL-konforme Struktur. Es fehlt die Definition einer SQL-Tabelle mit dem Bezug auf die jeweiligen Attribute der ChronoLog-Daten. Hierfür wurde eine im JSON Format (http://de.wikipedia.org/wiki/JavaScript_Object_Notation) definierte Tabellenschema-Datei eingeführt. Eine JSON-Datei beschreibt genau eine SQL-Tabelle und wird vom AprolSqlServer direkt ausgelesen. Der Dateiname entspricht dabei dem SQL-Tabellennamen. Eine detaillierte Beschreibung über den Aufbau dieser Datei finden Sie im Kapitel 'Manuelle Erstellung von Tabellenschema-Dateien'. Die Tabellenschemata befinden sich im folgenden Pfad: /opt/aprol/cnf/AprolSqlServer/<Tabellenname>.json

APROL unterscheidet zwischen dynamischen und statischen Tabellenschemata.

Statische Tabellenschemata sind fest definierte SQL-Tabellen, welche bereits bei der Installation vollständig verfügbar sind. Eine genaue Beschreibung aller Tabellen finden Sie im Kapitel 'Verfügbare SQL-Tabellen'. Dynamische Tabellenschemata sind projektierungsabhängige SQL-Tabellen. Erst bei einer Generierung durch den GenLib/Devil-Prozess werden diese Tabellen erzeugt und durch den DownloadManager verteilt. Diese umfassen im Konkreten PDA und SFC Daten. Um die jeweiligen Bereiche klar voneinander abzutrennen, wurden die folgenden SQL-Schemata eingeführt:

• base : statische Tabellen

• sfc : dynamische SFC-Tabellen

• pda : dynamische PDA-Tabellen Diese sind bei einer SQL-Abfrage und der Selektion einer Tabelle mit anzugeben. Bei einer fehlenden Angabe wird standardmäßig 'base' angenommen. Beispiel: SELECT ts FROM sfc.SFC_Test

http://de.wikipedia.org/wiki/JavaScript_Object_Notation

8-2

8.4.3 Manuelle Erstellung von Tabellenschema-Dateien

8.4.3.1 Aufbau der Konfigurationsdatei im JSON-Format Test_Schema.json // Tabellenname { 'DataSourceHeader': { 'Name': 'TestBlock', 'Description': 'Test description' }, 'DataSourceDefinition': { 'IdSchema': 'country:forename/surname/state/city/street', 'country': 'GERMANY', 'forename': [ 'david', 'karsten', 'petros', 'rufus' ], 'state': 'nrw/me', 'street': [ '*.12', '*.42' ] }, 'TableDefinition': [ { 'ColumnKey': 'ts', 'ColumnAlias': 'Timestamp', 'IecType': 'DATE_AND_TIME', 'Description': '1a', 'Comment': '1b', 'Unit': '1c' }, { 'ColumnKey': 'country', 'IecType': 'STRING', 'SqlType': 'VARCHAR(255)', 'Description': '2a', 'Comment': '2b', 'Unit': '2c' } ] }

8.4.3.2 Abschnitt 'DataSourceHeader': Die hier aufgeführten Felder dienen ausschließlich der Dokumentation. Das Feld 'Name' gibt dabei den Namen der Datenquelle an und 'Description' eine weiterführende Beschreibung.

8.4.3.3 Abschnitt 'DataSourceDefinition': Hier wird die Datenquelle der Tabelle über den ChronoLog-Identifier definiert. Das vorgegebene Feld 'IdSchema' spezifiziert den Aufbau des Identifiers und benennt die jeweiligen Sektionen des Schlüssels. Die Benennung ist willkürlich, muss jedoch eindeutig sein (keine Überschneidungen im Identifier und ChronoLog-Feld). Die Datenmenge kann nun über konkrete

8-3

Wertzuweisungen der einzelnen Sektionen beschrieben werden. Es wird hierzu der Sektionsname als Attribut angelegt und mit einem oder mehreren Werten belegt. Das Präfix eines Schlüssels kann jedoch maximal aus einem Wert bestehen. Jede nicht definierte Sektion wird als Wildcard ausgewertet. Das obige Beispiel beschreibt die Tabelle 'Test_Schema' welche Einträge erlaubt die den 'GERMANY'-Präfix tragen und die Vornamen 'david', 'karsten', 'petros' oder 'rufus' beinhalten. Der Nachname ist irrelevant (Wildcard). Als 'state'-Feld wird ausschließlich 'nrw/me' zugelassen und die Straße muss mit der Hausnummer '12' oder '42' enden. Die Stadtangabe ist wiederum irrelevant. Hieraus resultieren die folgenden ChronoLog-Identifier:

• GERMANY:david/*/nrw/me/*/*.12

• GERMANY:rufus/*/nrw/me/*/*.12

• GERMANY:karsten/*/nrw/me/*/*.12

• GERMANY:petros/*/nrw/me/*/*.12

• GERMANY:david/*/nrw/me/*/*.42

• GERMANY:rufus/*/nrw/me/*/*.42

• GERMANY:karsten/*/nrw/me/*/*.42

• GERMANY:petros/*/nrw/me/*/*.42 Ein mit diesen Identifiern disjunktiv verknüpfter ChronoLog-Aufruf ergibt die vollständige Datenmenge.

8.4.3.4 Projekt-Substitution Die automatische Substitution des in der odbc.ini spezifizierten Projekts erreicht man dadurch, dass man den Wert einer Sektion mit '$project' beschreibt. ...

'forename' : '$project',

...

Für die Tabelle 'Test_Schema' wird nun der in der odbc.ini spezifizierte Projektname als festen Wert vorgegeben.

8.4.3.5 Abschnitt 'TableDefinition': Hier werden die verfügbaren Spalten der Tabelle definiert. Jeder '{ }'-Block entspricht einer Spalte. Die Anordnung von oben nach unten entspricht der Spaltenanordnung von links nach rechts. Beschreibung der einzelnen Felder: ColumnKey: Dieser Wert nimmt Bezug auf den ChronoLog-Eintrag. Hier muss entweder ein Feld selektiert werden oder eine zuvor benannte Sektion im Identifier. Der Wert wird zusätzlich als SQL-Tabellenspaltennamen verwendet. Pflichtfeld ColumnAlias: Ein hier eingetragener Wert überlagert den ColumnKey-Wert für den SQL-Tabellenspaltennamen.

8-4

IecType: Definition des Datensatztypen aller in der Spalte vorhandenen Einträge im IEC-Format. SqlType: Definition des Datensatztypen aller in der Spalte vorhandenen Einträge im SQL-Format. Description: Beschreibung der Spalte als Metainformation. Comment: Kommentar der Spalte als Metainformation. Unit: Einheit der Spalte als Meta-Information. Ergänzende Hinweise: Durch das Spezifizieren des IecType und SqlType Feldes wird eine Umwandlungs-Operation vom Quell- zum SQL-Datensatztypen vorgegeben. Wird keine/nur einer der beiden Felder benutzt, so gilt die folgende Regel: nur IecType: Angabe des Quelltypen. Cast in SQL-Zieltyp wird implizit vorgenommen - sofern möglich. nur SqlType: Angabe des Quelltypen entspricht bereits dem Zieltyp. keine Angabe: Quelltyp wird auf VARCHAR(255) umgewandelt Es stehen ausschließlich die hier definierten Spalten für das SQL-Statement zur Verfügung.

8.4.3.6 Beispiel eines SQL-Select Statements: SELECT Timestamp, country FROM Test_Schema WHERE Timestamp > '2012-01-01';

8.4.3.7 Validierung einer Tabellenkonfiguration Zur Validierung einer JSON-Tabellenkonfiguration steht Ihnen das 'SqlTableSchemaValidator' Werkzeug zur Verfügung. Dieses überprüft eine angegebene Datei auf die inhaltliche Korrektheit und gibt evtl. Fehlerursachen zurück. Beispiel: SqlTableSchemaValidator /opt/aprol/cnf/AprolSqlServer/Alarm.json

8.5 Anhang APROL-SQL |url=appendixaprolsqlserver.htm.

8.5.1 Treiberparameter Schlüssel: Wert:

PROJECT <CAE-Projekt der Datenquelle> SYSTEM Runtime-System: aprolsys

Engineering-System: <CC-Account der Datenquelle> UID User Identification (Benutzer-Identifikation)

PWD Zugehöriges Passwort des UID

ARKPATH Der SQL-Server bietet die Unterstützung für die von ChronoLog bekannte Funktion arkpath, die den Zugriff auf gesicherte ChronoLog-Container erlaubt.

8-5

Schlüssel: Wert:

TREND_SOURCE Der Parameter dient der Auswahl der Trend-Datenquelle, d. h. der Auswahl des / der APROL-Systeme, welche kontaktiert werden. Der Parameter kann die folgenden Werte annehmen: protocol: Trenddaten werden vom Protokoll-Server gelesen. local: Tenddaten werden von dem System gelesen, auf dem sich der AprolSqlServer befindet. default oder Option nicht verwendet: Trenddaten werden auf den Runtime-Systemen ermittelt, auf denen die Trends erfasst werden.

8.5.2 Unterstützte SQL-Datentypen Die folgenden SQL92-Datentypen werden vom AprolSqlServer unterstützt. Die geklammerten Spezifikationen sind optional. Beim Weglassen dieser Informationen werden die Defaultwerte (nachfolgend in eckigen Klammern) angewendet.

BIT

INT

INT UNSIGNED

TINYINT

TINYINT UNSIGNED

SMALLINT

SMALLINT UNSIGNED

BIGINT

BIGINT UNSIGNED

REAL

DOUBLE

FLOAT(size) [default: 53]

NUMERIC(size, scale) [default: 38, 0]

DECIMAL(size, scale) [default: 38, 0]

DATE

TIME

TIMESTAMP(precision) [default: 6]

CHAR(size) [default: 1]

VARCHAR(size) [default: 255]

8-6

8.5.3 IEC zu SQL Datentyp-Mapping Die folgende Tabelle enthält die Zuordnung von IEC-Datentypen zu SQL-Datentypen, wie sie in der Tabellenkonfiguration angewendet wird. Nicht aufgeführten IEC-Datentypen ist kein SQL-Datentyp zugeordnet.

IEC-Datentyp SQL-Datentyp ANY_BIT INTEGER UNSIGNED BOOL BIT BIT BIT BYTE SMALLINT UNSIGNED WORD INTEGER UNSIGNED DWORD INTEGER UNSIGNED LWORD INTEGER UNSIGNED SINT SMALLINT INT INTEGER DINT INTEGER LINT INTEGER USINT SMALLINT UNSIGNED UDINT INTEGER UNSIGNED ULINT INTEGER UNSIGNED REAL DOUBLE LREAL DOUBLE TIME INTEGER DATE DATE DT TIMESTAMP TOD TIME ANY_NUM DOUBLE STRING VARCHAR(32767) SSTRING VARCHAR(64) LSTRING VARCHAR(32767)

8.5.4 Verwendung von AprolSqlQueryTool als Datenbank-Client Für einen ersten Einstieg bieten wir Ihnen unter Linux das mitgelieferte SQL-Abfragewerkzeug 'AprolSqlQueryTool' an. Es ist auf Engineering- und Operator-Systemen verfügbar und kann aus dem APROL-Startmenu unter dem Menüpunkt 'Diagnose' heraus gestartet werden.

8-7

8.5.4.1 Beschreibung der Benutzeroberfläche

Abbildung 110: Benutzeroberfläche des AprolSqlQueryTool

8.5.4.2 Eingabefelder Datenquelle: Wählt eine Datenquelle aus. Die Liste wird aus der Konfigurationsdatei odbc.ini ermittelt. Eine Auswahl bewirkt die Aktualisierung der Tabellenübersicht (s.u.). Statement: Eingabefeld für das abzusetzende SQL-Statement. Es wird eine Historie über die 20 erfolgreichen Statements geführt. Button [Ausführen]: Bei Betätigung wird die Ausführung gestartet. Status-Icon: Signalisierung über Fehler- oder Erfolgsfall.

8-8

8.5.4.3 Anzeigeflächen Tabellenübersicht: Alle in der Datenquelle spezifizierten Tabellen. Bei einem Mausklick wird das aktuelle SQL-Statement um den Tabellennamen substituiert. Ist das Feld noch frei, so wird ein SQL-Statement generiert. Ergebnistabelle: Anzeige des Resultats des abgesetzten SQL-Statements. Log-Fenster: Anzeige der vom AprolSqlQueryTool durchgeführten Tätigkeiten. Statuszeile: Signalisierung des Endzustands. Fehler- oder Erfolgsfall wird mit Informationen hier hinterlegt.

8.5.4.4 Hauptmenü Menüpunkt 'Konfigurationsdatei öffnen...': Öffnet die „odbc.ini“ Datei mit kwrite. Menüpunkt 'Query-Jobs abarbeiten...': Öffnet einen modalen Dialog zur Abarbeitung einer Query-Job Liste (s.u.). Die Job-Datei muss die Dateierweiterung '.sql_queries' besitzen und als JSON-Format vorliegen. Die Zieldatei wird mit ".log" als Dateierweiterung geschrieben. Bei Bestätigung wird die Liste top-down Durchlaufen und eine Protokollierung in der Zieldatei geschrieben. Wahlweise ist das Exportieren der Ergebnisse in jeweils eine eigene Datei möglich. Der Job-Bezeichner wird hierbei als Name gewählt. Hierfür muss die Checkbox gesetzt sein. Menüpunkt 'Ergebnis Exportieren...': Speichert die aktuelle Ergebnistabelle in Form einer ".csv" Datei. Als Trennzeichen wird hierbei das Semikolon gewählt. Menüpunkt 'Standard wiederherstellen': Setzt das Layout und die Statement-Historie zurück. Menüpunkt 'Beenden': Beendet die GUI-Anwendung und speichert die Einstellungen. Menüpunkt 'APROL Info Lizenzen': Der APROL-Lizenzen-Dialog wird aufgeschaltet.

8-9

8.5.4.5 Query-Job Liste Eine Query-Job Liste beinhaltet SQL-Statements, welche vom AprolSqlQueryTool abgearbeitet werden kann. Das Dateiformat ist JSON. Ein Job-Eintrag muss als Attributnamen einen eindeutigen Bezeichner enthalten, welcher im Dateisystem gültig ist (wird ggf. als Exportdateiname genutzt). Das eigentliche Statement muss als dazugehöriger Attributwert angegeben werden.

Wichtig: Im Statement genutzte Anführungsstriche müssen mit "\" maskiert werden!

Beispiel: {

"select1": "Select * from base.PDA_PdaReaktor2 where \"ts\" >= '2012-10-03' and \"from\" = 'FT27102'",

"select2": "Select * from base.CaeUpdate where ts >= '2012-10-02'",

"select3": "Select * from base.CaeUpdate where ts >= '2012-10-03'"

}

8.5.4.6 Protokollierung Die Abarbeitung eines SQL-Statements über das Eingabefeld wird in einer Log-Datei (JSON-Format) unter dem Pfad: /<Engineering-System>/ENGIN/cnf/AprolSqlQueryTool/queries.log /<Runtime-System>/RUNTIME/cnf/AprolSqlQueryTool/queries.log

protokolliert. Jeder Block enthält eine fortlaufende Nummerierung. Weiterhin werden der aktuelle Zeitstempel, das Statement, die Laufzeit und die Anzahl der Ergebniszeilen festgehalten. Im Negativfall wird die Fehlerursache in die Datei queries.log geschrieben.

8.5.5 Verwendung von SQuirreL als Datenbank-Client Nachfolgend wird das Einrichten einer Verbindung mittels SQuirreL beschrieben.

8-10

8.5.5.1 Einrichtung des Datenbanktreibers

Abbildung 111: Einrichtung des Datenbanktreibers

Schritt Beschreibung

1 Reiter 'Drivers' und Menü 'New Driver' wählen 2 Name des Treibers vergeben: 'AprolSqlClientDriver' 3 URL eintragen (spitze Klammern ersetzen):

'jdbc:simba://<host>:55503;SYSTEM=<aprolsys | CC-Account>;PROJECT=<project>'

4 Im Reiter 'Extra Class Path' > 'Add' wählen. Auswahl der Datei '/opt/aprol/lib64/SimbaEngine/client/SimbJDBCCLient.jar' (auf 32-bit Systemen: '/opt/aprol/lib/SimbaEngine/client/SimbJDBCCLient.jar')

5 Button [ListDrivers] drücken Im Feld 'ClassName' erscheint die Anzeige: 'com.simba.client.core.JDBCDriver'

6 Treibereinrichtung mit [OK] abschließen.

8-11

8.5.5.2 Einrichtung eines Alias (DB-Verbindungs-Alias)

Abbildung 112: Einrichtung eines Alias (DB-Verbindungs-Alias)


1 Reiter 'Aliases' und Menü 'New Alias' wählen 2 Namen des Alias vergeben: z.B. 'Verbindung zu pdadevelop01' 3 Treiber auswählen: 'AprolSqlClientDriver' 4 URL anpassen: 'jdbc:simba://pda.your-automation.com:

55503;SYSTEM=aprolsys;PROJECT=SamplesProject'(Beispiel) 5 Checkbox 'Connect at Startup' abwählen 6 Alias-Einrichtung mit [OK] abschließen

8.5.5.3 SSL-Verbindung über SQiurreL Für die verschlüsselte Verbindung über SQiurreL sind die in der folgenden Abbildung eingetragenen Parameter anzugeben. Hierbei sind statt der in Klammern gesetzten Platzhalter die tatsächlichen Werte einzutragen:

8-12

Abbildung 113: SQL-Zufriff über SQiurreL


4 URL anpassen: 'jdbc:simba://pda.your-automation.com: 55503; SYSTEM=aprolsys;PROJECT=SamplesProject'; UseSsl=1;TrustedStorePath=<Install path>\\SSLCertificates\\jdbckeystore; TrustedStorePassword=.aprol’ (Beispiel)

8.5.5.4 Datenbankverbindung aufbauen

Abbildung 114: Datenbankverbindung aufbauen


1 Reiter 'Aliases' und Eintrag 'Verbindung zu pdadevelop01' auswählen

8-13


2 Die Aktion 'Connect...' ausführen 3 Verbindung mit dem Button [Connect] aufbauen (es ist keine Benutzer- oder

Passwortangabe notwendig).

8.5.6 Anmerkungen zu SQL-Abfragen .

8.5.6.1 TOP-Klausel Mit Hilfe der TOP-Klausel kann die Zeilenanzahl des Ergebnisses begrenzt werden. Das folgende Beispiel liefert die ersten 10 Zeilen zurück: SELECT TOP 10 * FROM base.CaeUpdate;

8.5.6.2 Datums- und Zeitangaben Datums- und Zeitangaben müssen in folgenden Formaten definiert werden.

• Datumsangabe

◦ Format: '<JJJJ>-<MM>-<TT>'

◦ Beispiel:'2013-12-31'

• Zeitangabe

◦ Format: 'HH:MM:SS' oder 'HH:MM:SS.FFFFFF'

◦ Beispiel:'13:49:47' oder '13:49:47.081094'

• Zeitstempelangabe

◦ Format: '<Datumsangabe> <Zeitangabe>'

◦ Beispiel:' 2013-12-31 13:49:47.081094'

8.5.6.3 Performancebetrachtung Historische Informationen bestehen aus einem Nutzinhalt und einer Zeitangabe. Jede Tabelle besitzt die Spalte 'ts' welche diese Zeitangabe abbildet. Für die optimale Performance empfehlen wir, stets die Berücksichtigung der 'ts' Spalte im SQL-Statement. Beispiel: SELECT * FROM base.Trend WHERE ts > ' 2013-12-31'

9-14

9 ReportSpooler .

9.1 Allgemeines zur ereignisgesteuerten Report-Erstellung Die Funktionalität des ReportSpoolers ermöglicht eine automatische Erstellung von Reports (z.B. AuditTrail, Schichtlogbuch, ChangeControl sowie eigene, kundenspezifische Reports) zu zuvor definierten Ereignissen oder Zeitpunkten. Die erzeugten Berichte werden im PDF-Format zur anschließenden Erstellung hochqualitativer Ausdrucke bereitgestellt. Vergleichbar dem Mechanismus zur Erstellung der As-Built-Dokumentation der CAE-Bibliotheken, wird für die Erstellung einer druckbaren PDF-Datei das von B&R lizenzierte und auf der APROL-DVD mitgelieferte Programm Prince der Firma YesLogic verwendet.

Die Lizenz für dieses Programm ist im CaeManager unter "Hilfe/Lizenz-Information" einzusehen.

Prince konvertiert XHTML-Dokumente in das PDF-Format und formatiert dabei nach den in CSS-Stylesheets vorgegebenen Regeln. Voraussetzung hierfür ist, dass die Quell-Dokumente in lokalen Dateien vorliegen. Sie haben hierbei die Möglichkeit, Bilder (PNG- oder GIF-Format) in das Quell-Dokument einzubinden. Hierbei kann es sich auch um Trend-Diagramme handeln, die via ChronoChart erstellt wurden. Das Programm Prince unterstützt CSS-Regeln zum Seitenlayout (z. B. Kopfzeilen, Fußzeilen, Steuerung des Seitenumbruchs) sowie zu Tabellenumbrüchen (Tabellenheader, Spaltenheader, -footer). Somit kann aus einem Quell-Dokument unter Hinzufügung spezieller CSS-Regeln eine Darstellung des Reports im Web-Browser als auch als hochauflösender Ausdruck ermöglicht werden.

Die XHTML-konforme Notation wird hierbei zwingend vorausgesetzt. Beachten Sie hierzu die Hinweise im Handbuch "B4 Projekt- & Bibliotheks-Dokumentation".

9.1.1 Prinzipieller Ablauf zur Erstellung von PDF-Dateien Die folgende Abbildung gibt einen schematischen Überblick über die Erstellung von PDF-Dateien via Prince in APROL:

9-15

Abbildung 115: Übersichtsbild zur PDF-Erstellung im APROL-System

Die Reports werden zunächst mit Hilfe von ChronoLog-Templates im XHTML-Format erstellt. Die Dokumente werden über das HTTP-Protokoll transferiert und temporär in lokalen Dateien auf dem Protokoll-Server abgelegt, da Prince nur lokale Dateien als Quelldokumente erlaubt. Anschließend wird die Konvertierung in das PDF Format via Prince durchgeführt.

9-16

9.2 Konfiguration der Report-Erstellung mit dem Baustein AprCcTrigReport

In der CAE-Bibliothek 'APROL' steht Ihnen in der Gruppe Reports der Baustein AprCcTrigReport zur Konfiguration der ereignisgesteuerten Report-Erstellung zur Verfügung. Mit dem Baustein AprCcTrigReport wird bei einem Trigger-Ereignis ein Report erstellt. Der Report kann in einer Datei auf dem Protokoll-Server und/oder auf einem Drucker ausgegeben werden. Der Baustein konfiguriert das CC-Modul ReportSpooler. Bei Verwendung des Bausteins muss der ReportSpooler im Rahmen der CC-Module des Control Computers konfiguriert werden.

Nach dem Eintreffen eines Trigger-Ereignisses kann ein erneutes Triggern derselben Baustein-Instanz nur nach Abarbeitung des vorherigen Auftrags erfolgen.

Aufträge unterschiedlicher Baustein-Instanzen werden in eine Warteschlange gestellt und sequentiell abgearbeitet. Bausteinansicht:

Abbildung 116: Der Baustein AprCcTrigReport

Der Baustein AprCcTrigReport kann ausschließlich in der vorliegenden Form aus der "APROL" Bibliothek verwendet werden.

Ein Kopieren und Modifizieren des Bausteins zur Verwendung in Kunden-Bibliotheken ist nicht möglich!

Baustein-Eingänge:

9-17

Name Typ Beschreibung / Defaultwert Attribut (CRDS)*

Trigger BOOL Die Reporterstellung wird durch eine positive Flanke an diesem Eingang ausgelöst.

CRDS

Url STRING Die URL wird ohne Protokoll (http[s]:) und Server angegeben. Der ReportSpooler kontaktiert immer den im Projekt konfigurierten Protokoll-Server. Wenn die URL mit "/" beginnt, so wird sie als absoute URL auf dem Protokoll-Server interpretiert. Hiermit können beispielsweise cgi-Programme unter /cgi-bin/ adressiert werden. Falls die URL nicht mit "/" beginnt, so wird sie als der Teil einer URL interpretiert, der auf den Ländercode (z.B. 049) einer URL folgt, die ein Projekt-Template adressiert. Der ReportSpooler stellt automatisch den Namen des Protokoll-Servers und den Pfad zu den Projekt-Templates einschließlich Ländercode (Eingang "AreaCode") der hier angegebenen URL voran. Bitte beachten Sie auch die in den Hinweisen dargestellten Beispiele. Konstante CGI Parameter können in beiden Fällen angehängt werden. Defaultwert: standard/syslog/syslog.clt

C-DS

Conversion STRING Mögliche Werte: "'PDF": Konvertierung nach PDF, "PDF pdf2ps": Konvertierung nach PDF, zusätzlich nach Postscript (ggf. zum Druck erforderlich), "none": keine Konvertierung (z.B. csv Format) Defaultwert: PDF

C-DS

PdfOptions STRING Zur Zeit ohne Funktion Defaultwert: ?

---S

9-18


File STRING Dateiname, unter dem der Report gespeichert werden soll. Die Reports werden auf dem Protokoll-Server im projektspezifischen REPORTS-Pfad gespeichert: /home/aprolsys/APROL_DATA/PROJECTS/ <Projektname>/REPORTS. Zusätzliche angegebene Pfadkomponenten werden angelegt! Falls kein Name angegeben oder keine gültige Prozessvariable angeschlossen ist, so wird der Report nicht gespeichert. Die vom ReportSpooler gesetzten Ausgänge JobId und JobCount können zur dynamischen Vergabe eines Dateinamens verwendet werden! Verwenden Sie als Teil des Dateinamens die Schlüsselworte $JobCount und/oder $JobId. Sie werden durch die entsprechenden numerischen Werte ersetzt.

C-DS

Printer STRING Druckername oder -klasse (ProtokollServer). Der Drucker bzw. die Druckerklasse muss auf dem Protokoll-Server in der Linux Druckerkonfiguration angelegt sein. Falls hier nichts eingegeben ist oder keine gültige Prozessvariable angeschlossen ist, so wird der Report nicht gedruckt.

C-DS

AreaCode STRING Sprachcode für Auswahl des ChronoLog-Templates (wird auch als CGI-Parameter 'lang' der URL angehängt!). Defaultwert: 001

C-DS

JobOperator STRING Name des Operators, der die Report-Erzeugung startet. Wird als CGI-Parameter der URL angehängt! Defaultwert: system

C-DS

from STRING Startzeitpunkt des Abfragezeitraumes eines ChronoLog-Templates in der Form "TT.MM.JJJJ hh:mm[:ss]" oder "JJJJ-MM-TT hh:mm[:ss]". Datums- oder Zeitkomponente kann weggelassen werden. Details entnehmen Sie bitte der APROL Dokumentation "D2 System API". Wird als CGI-Parameter der URL angehängt! Defaultwert: 00:00

C-D-

9-19


till STRING Endezeitpunkt des Abfragezeitraumes in der Form "TT.MM.JJJJ hh:mm[:ss]" oder "JJJJ-MM-TT hh:mm[:ss]". Datums- oder Zeitkomponente kann weggelassen werden. Details entnehmen Sie bitte der APROL Handbuch "D2 System API". Wird als CGI-Parameter der URL angehängt! Defaultwert: 24:00

C-D-

Unused_1 STRING Zur Zeit ohne Funktion Defaultwert: ?

- - - -


- - - -


- - - -

Der Dateiname kann durch Verwendung der Schlüsselworte oder durch Anschluss einer Prozessvariablen dynamisch vergeben werden. In diesem Fall werden bei Triggerung immer neue Dateien im Dateisystem gespeichert. Bitte stellen Sie durch applikative Massnahmen sicher, dass immer genügend Speicherplatz auf der zugehörigen Partition vorhanden ist . Einzelheiten entnehmen Sie bitte der APROL Dokumentation "Backup & Recovery", Kapitel Festplatten-Management.

Baustein-Ausgänge:


Status INT Bedeutung des Statuscodes: 0 = "done_ok" : kein Fehler bei Abarbeitung des letzten Jobs, 1 = "done_error" : Fehler bei Abarbeitung des letzten Jobs, 2 = "idle" : Leerlauf , 3 = "canceled": Abbruch aufgrund eines Wechsels der Prozessführung, 4 = "timeout" : Keine Rückmeldung vom Protokoll-Server erhalten, 5 = "active" : Report-Request in Berabeitung (keine Triggerung erlaubt), 6 = "pending" : Report-Request in Warteschlange (keine Triggerung erlaubt).

C-DS

9-20


Error INT Bedeutung des Fehlercodes: 0 = "ok" >0 = "Error": Siehe Ausgang "ErrorText" für eine kurze Beschreibung.

C-DS

StatusText STRING Kurzer Statustext C-DS ErrorText STRING Kurzer Fehlertext C-DS QueueTotal INT Gesamtzahl der in der globalen Warteschlange

anstehenden Jobs C-DS

QueuePos INT Alle Aufträge werden Baustein-übergreifend nacheinander abgearbeitet. Dieser Ausgang gibt die momentane Position dieses Auftrages in der globalen Warteschlange an.

C-DS

JobId ULINT Bei dem Ausgang JobId handelt es sich um einen Identifier des aktuell anstehenden bzw. des letzten Auftrags. Der Zähler berücksichtigt hierbei alle Trigger-Ereignisse aller Baustein-Instanzen. Der Ausgang JobId wird als remanente Variable vom Iosys gehalten. Das bedeutet, dass nach einem Neustart des ReportSpoolers oder nach erfolgtem Download alle Werte erhalten bleiben!

C-DS

JobCount ULINT Am Ausgang JobCount wird ein Zähler zur Verfügung gestellt, der bei jedem Trigger-Ereignis dieser Baustein-Instanz inkrementiert wird. Der Ausgang JobCount wird als remanente Variable vom Iosys gehalten. Das bedeutet, dass nach einem Neustart des ReportSpoolers oder nach erfolgtem Download alle Werte erhalten bleiben!

C-DS

Erläuterung zur Spalte "Attribut":

Attribut Bedeutung

C Anschlussfähig R Anschlusspflichtig D Dynamisch konfigurierbar S System-Pin

Beispiele für URLs zur Erstellung von APROL Standard Reports:

Report-Typ URL

AuditTrailReport standard/action/overview.clt?id=USERACTION:

9-21

Report-Typ URL

AlarmReport standard/alarm/show_alarm_list.clt?css=standard;... ...group=filter;alias=filter;pv=filter;prio=filter

TargetControlReport standard/changecontrol/targetlist.clt Systemmeldungen standard/syslog/syslog.clt TrendReport standard/trend/trd_data.clt?project=<Projekt>&runtimesystem...

...=<CC-Account>&id=TRD:<PV-Name>&nmax...

...=<Max.AnzahlEreignisse> ProcessDataReport /cgi-bin/IosInOut.pl?lang=<area-

code>&server=<server>&runtimesystem=<CC-Account>... ...&port=<port-no>&pv=<pv-name>... ...&xsl=/opt/aprol/doc/xsl-sheets/<area-code>/online/Result/iosinouthtml.xsl Beachten Sie, dass hier die URL mit "/" beginnt!

CustomerReport customer/<Name des kundenspezifischen Templates> Kundenspezifische ChronoLog-Templates werden im Verzeichnis /home/<CC-Account>/ENGIN/PROJECTS/ <Projektname>.pgp/WEB/<Language-Code>/REPORTS/ customer" abgelegt und sind nach dem Generierungs-Vorgang und dem anschließenden Download auf dem Protokoll-Server verfügbar! Weiterführende Informationen zum ChronoLog-Mechanismus entnehmen Sie der APROL Dokumentation "D2 System API".

9.2.1 Konfiguration und Funktionsweise des ReportSpoolers Im Rahmen der Konfiguration der CC-Module ist der ReportSpooler zu aktivieren und dessen Optionen -iosys, -restart, -self zu überprüfen bzw. zu parametrieren. Nach Eintreffen einer positiven Flanke am Eingang Trigger werden vom ReportSpooler die Werte an den Eingängen Url, Printer und File abgegriffen. Daraufhin wird ein Report-Request (HTTP-Post-Request) an das CGI-Programm AprolCreateReport abgesetzt. Der Request wird in eine globale Warteschlange eingereiht, welche sequentiell abgearbeitet wird. Der ReportSpooler wertet die Status- bzw. Statustext-Rückgabe des CGI-Programms aus und stellt diese an den Baustein-Ausgängen Error und ErrorText zur Verfügung. An den Ausgängen Status und StatusText wird der gegenwärtige Status der Abarbeitung Requests angezeigt.

9.2.2 AprolCreateReport Dem CGI-Programm AprolCreateReport wird per HTTP-Post Request von einem Client (ReportSpooler) die URL des Reports, ein Druckername, ein Dateiname und Parameter zur Steuerung der Konvertierung übergeben. Unter der URL wird der (über den ChronoLog-Mechanismus erzeugte) Report mit allen zur Anzeige erforderlichen Dateien (xhtml, css, png) geholt und in einem lokalen (temporären) Verzeichnis abgelegt.

9-22

Für den Datentransfer wurde das Linux-Werkzeug wget dahingehend modifiziert, dass auch das Handling sehr langer URLs (ChronoChart) möglich ist. Anschließend wird (falls eine PDF-Konvertierung erwünscht) via Prince aus den lokalen Dateien ein PDF-Dokument erzeugt. Sofern ein Druckername übergeben wurde, wird das Dokument zu diesem Drucker geschickt. Falls ein Dateiname (einschließlich Pfad) übergeben wurde, wird das Dokument dort abgelegt. Falls parametriert, wird der erstellte Report zum HTTP-Client zurückgesendet. In jedem Fall wird eine Statusmeldung zum Client zurückgeschickt, die Informationen über einen erfolgreichen bzw. fehlerhaften Vorgang enthält.

9-23

Abbildung 117: Übersichtsbild zur ereignisgesteuerten Report-Erstellung im APROL-System

9.3 Abläufe und Wirkungswege bei der Ereignis-gesteuerten Report-Erstellung

Die folgende Übersicht verdeutlicht den zeitlichen Ablauf der Ergeignisse und das Zusammenwirken der an der Erstellung des Reports beteiligten Komponenten des Prozessleitsystems.

9-24

In der Übersicht sind die beteiligten Server und die Operator-Station getrennt dargestellt. Je nach Topologie des Prozessleitsystems können diese Komponenten auf dem selben (Kompakt-System) oder unterschiedlichen Rechnern liegen. Die Nummerierung in der nachfolgenden Tabelle entspricht der Nummerierung in der schematischen Übersicht.


1a / 1b Interaktion des Operators im DisplayCenter (1a) oder die Control Computer Task (1b) setzt Prozessvariablen im Iosys, welche den Report parametrieren und über die Trigger-Variable den Ablauf starten.

2 Der ReportSpooler übernimmt die Parameter des Reports und hängt den Auftrag an das Ende der Warteschlage an.

3 Daraufhin werden vom ReportSpooler die Prozessvariablen der Baustein-Ausgänge gesetzt, wie z. B. die Warteschlangenposition an dem Baustein-Pin "QueuePos".

4a, 4b Die Baustein-Ausgänge werden vom DisplayCenter visualisiert (4a) bzw. von der Control Computer Task ausgewertet(4b).

5 Beim Start der Auftrages wird ein HTTP-Post-Request an das CGI-Programm AprolCreateReport abgesetzt.

6 Report-Erzeugung via ChronoLog durch Absetzen eines HTTP-Get-Requests der parametrierten URL.

7 Nach Umwandlung in das PDF-Format erfolgt die Ablage des Reports als Datei auf dem Protokoll-Server und / oder Ausgabe des Reports auf dem Drucker.

8 HTTP-Response in dem Status und ggf. Fehler der Report-Erstellung und der Transformation in das PDF-Format zurück gemeldet werden.

9 Setzen der Prozessvariablen, die den Status- und Fehlercode und die zugehörigen Texteam Baustein-Ausgang enthalten.

10a, 10b Die Baustein-Ausgänge werden vom DisplayCenter visualisiert (10a) bzw. von der Control Computer Task ausgewertet (10b).

9-25

Abbildung 118: Übersicht zu den Abläufen und Wirkungswegen

9.4 Erstellung kundenspezifischer Reports Für die Erstellung kundespezifischer Berichte sind eigene ChronoLog-Templates zu erstellen, die im Verzeichnis /home/<CC-Account>/ENGIN/PROJECTS/<Projektname>.pgp/WEB/<Language>/REPORTS/customer abgelegt werden.

Die Erstellung kundenspezifischer Reports setzt Kenntnisse des APROL ChronoLog-Systems sowie grundlegende XHTML- und CSS-Kenntnisse voraus.

1. Einzelheiten zum ChronoLog-System entnehmen Sie der APROL Dokumentation "D2 System API" 2. Grundlegende Informationen zu XHTML und CSS entnehmen Sie der externen Dokumentation "SelfHTML" der APROL Handbuchgruppe X-AddOns.

Die in diesem Verzeichnis vorhandenen Dateien können über die URL http(s)://<Rechnername>/PROJECTS/<Projektname>/<Language>/customer aufgerufen werden. Alternativ kann der Aufruf über das KDE-Menü 'Berichte / Customer-Reports' oder über die Report-Übersichtsseite erfolgen. Der Webserver erstellt automatisch eine Liste der abgelegten Verzeichnisse und Dateien (siehe Screenshot) über die navigiert werden kann bzw. welche direkt aufgerufen werden können.

9-26

Abbildung 119: Vom Webserver automatisch erstellte Auflistung

Sollte eine individuelle Gestaltung einer Startseite gewünscht bzw. eine eigene Menüstruktur erforderlich sein, kann dies applikativ anhand einer Datei index.html oder index.htm oder index.php, die in dem angegebenen Verzeichnis als Startseite ablgelegt werden muss, erfolgen.

In diesem Fall wird das o. g. Listing nicht mehr automatisch vom Webserver erstellt, sondern muss ggf. anhand eines (PHP)-Skripts nachgebildet werden.

Die folgende Abbildung stellt den Zusammenhang zwischen dem XHTML formatierten Inhalt, den CSS-Regeln des zugehörigen Stylesheets und dem daraus resultierenden Layout des Reports dar:

9-27

Abbildung 120: Zusammenhang zwischen XHTML formatierten Inhalt, CSS-Regeln und resultierendem Layout

Das vorliegende Beispiel zeigt die Erstellung von Kopf- und Fußzeilen, welche auf jeder Seite dargestellt werden sowie die Implementierung einer fortlaufenden Seiten-Nummerierung.

9-28

Abbildung 121: Darstellung des generierten Reports im AdobeReader

Zur Fehlernalyse der von Ihnen erstellten Report-Templates wurde ein Web-Formular entworfen, welches unter den Profi-Abfragen (KDE-Menü "APROL/Berichte/Detail-Berichte/ChronoLog-ProfiReport") zu finden ist. Rufen Sie für die Fehleranlayse den Eintrag "Erzeugung, PDF-Transformation und Drucken von Reports" auf.

Hier kann der HTTP-Request des ReportSpoolers manuell nachgestellt werden. Durch Setzen der Option "Mit Debug-Meldungen" werden im Browser die Debug-Ausgaben des CGI-Programms AprolCreateReport sowie eventuelle Fehlermeldungen (z.B. XHTML-Syntax-Fehler) angezeigt.

Im Rahmen der APROL Protokollierung werden die URLs aller HTTP-Requests des ReportSpoolers aufgezeichnet. Aus den APROL-Systemmeldungen kann die URL zum Zweck der Fehleranalyse in das vorgenannte Formular kopiert werden.

Fehleranalyse – Schritt 1: Aufruf der APROL-Systemmeldungen / Kopieren der URL

Fehleranalyse – Schritt 2: Einfügen der URL in das Web-Formular

9-29

Fehleranalyse – Schritt 3: Darstellung der Debug-Ausgaben des CGI-Programms sowie eventuelle Fehlermeldungen (z.B. XHTML-Syntax-Fehler) im Browser

9.4.1 Redundanz

Der ReportSpooler unterstützt die APROL Prozess-Redundanz. Darüber hinaus gelten folgende Einschränkungen: Geht die Prozessführung während der Abarbeitung eines Requests auf den Redundanz-Partner über, sind die Statusmeldung und eventuelle Fehlermeldungen dieses Request an den Baustein-Ausgängen nicht verfügbar. Wenn der Protokoll-Server, welcher den HTTP-Request abarbeitet, weiterhin läuft, wird die Report-Erstellung dennoch ordnungsgemäß beendet. Alle in der Warteschlange befindlichen Requests gehen bei der Umschaltung der Prozessführung verloren.

Ebenso werden bei Beendigung des ReportSpoolers (z. B. bei Stoppen des APROL-Systems) alle Requests aus der Warteschlange entfernt

10-1

10 Digitale Signatur von PDF-Dokumenten .

10.1 Grundlagen der digitalen Signatur .

10.1.1 Motivation und Intention

Die digitale Signatur von PDF-Dokumenten in APROL bietet Ihnen folgende Vorteile:

Sicherstellung, dass der Ursprung des Reports das Prozessleitsystem APROL ist

fälschungssichere Ablage und Weitergabe von Reports

Bestätigen oder Kommentieren des Inhaltes der automatisch generierten Reports durch den Operator (Signieren von Reports)

nachprüfbare Identität des Operators, welcher den Report signiert hat

Der Inhalt der Daten (z.B. des PDF-Dokuments) ist jedoch durch die alleinige Anbringung einer Signatur nicht verschlüsselt, sondern ausschließlich auf nachträgliche Manipulation überprüfbar.

10.1.2 Was ist Signierung? Elektronische Signatur: Die elektronische Signatur ist ein Rechtsbegriff der im Signaturgesetz (Gesetz über Rahmenbedingungen für elektronische Signaturen, kurz SigG) definiert ist.

Im §2 SigG werden die verschiedenen Formen der elektronischen Signatur definiert.

Unter einer elektronischen Signatur versteht man mit elektronischen Informationen verknüpfte Daten. Mit diesen Daten kann Folgendes erreicht werden:

Identifikation des Unterzeichners bzw. Signatur-Erstellers

Überprüfbarkeit der Integrität der signierten elektronischen Dokumente

Digitale Signatur: Die digitale Signatur ist die technische Umsetzung der elektronischen Signatur. Im Prinzip wird mittels des im Zertifikat enthaltenen privaten Schlüssels ein verschlüsselter Hash-Wert erstellt.

10-2

Durch erneute Erstellung eines Hash-Wertes und Vergleich mit dem zuerst erstellten Wert, kann erkannt werden, ob nach der Signatur Veränderungen an den Daten vorgenommen wurden. Es kann jedoch nicht erkannt werden, welche Änderungen vorgenommen wurden.

10.1.3 Wozu dienen digitale Signaturen in APROL?

Für alle im HTML-Format vorliegenden, und im Web-Browser darstellbaren, APROL Reports kann optional eine PDF-Datei erstellt werden, auf dessen Basis ein Ausdruck ermöglicht wird.

Alle vom APROL-System erzeugten und im PDF-Format vorliegenden Reports werden dabei standardmäßig mit einer digitalen Signatur versehen und somit vor nachträglicher Manipulation geschützt.

Die Signatur erfolgt durch das APROL-System-Zertifikat auf dem Server, auf dem der Report erzeugt wurde. Diese Signaturen werden nachfolgend als Zertifizierungssignaturen bezeichnet. Anhand dieser Signatur wird für den vorliegenden Report als Ursprung das Prozessleitsystem APROL sichergestellt.

Zusätzlich kann das PDF-Dokument mit einem personifizierten Benutzer- oder Operator-Zertifikat signiert werden. Mit dieser Signatur bestätigt der Unterzeichner den Inhalt des Dokuments, wobei der Zweck der Signatur angegeben werden muss. Diese Signaturen werden nachfolgend als Genehmigungssignaturen bezeichnet.

Im APROL Webportal (Reports / Dokument signieren) wird eine eine Funktion bereitgestellt, um auch selbsterstellte PDF-Dokumente mit einer elektronischen Signatur zu versehen. Somit können neben der Signierung von APROL-Reports auch mit externen Werkzeugen erstellte Dokumente mit einer digitalen Signatur versehen werden. D. h. es können z. B. mit dem JasperSoft Studio erstellte Reports nachträglich signiert werden. Das JasperSoft Studio ermöglicht die Erstellung eigener Reports durch die Anbindung der APROL-Daten über eine JDBC Datenquelle mit Bezug der Daten über den AprolSqlServer. Die Funktionalität ermöglicht ebenso das 'Gegenzeichnen' eines bereits zuvor signierten Reports.

Durch die Signatur des PDF-Dokuments ist sichergestellt, dass anhand der Integritätsprüfung im Adobe Reader nachträglich am Inhalt vorgenommene Änderungen klar erkennbar sind. Zusätzlich wird die Identität des Unterzeichners verifiziert. Hierdurch wird eine fälschungssichere Ablage und Weitergabe von Reports (z. B. historischer Prozessdaten) gewährleistet.

10.1.4 Was ist asymetrische Verschlüsselung? Grundlage der digitalen Signatur ist die asymmetrische Verschlüsselung. Sie ist ein kryptographisches Verfahren, bei dem jede der kommunizierenden Parteien ein Schlüsselpaar besitzt, das aus einem geheimen Teil (privater Schlüssel) und einem nicht geheimen Teil (öffentlicher Schlüssel) besteht. Asymmetrische Kryptosysteme werden daher auch als Public-Key-Verfahren bezeichnet.

10-3

Im Gegensatz hierzu verwenden bei einem symetrischen Kryptosystem die kommunizierenden Parteien einen gemeinsamen (geheimen) Schlüssel.

Bei der Erstellung von PDF-Signaturen in APROL wird die asymetrische Verschlüsselung wie folgt eingesetzt:

Privater Schlüssel (Private Key) zum Erstellen einer digitalen Signatur Hierzu wird aus dem PDF-Dokument via Hash-Funktion (z. B. MD5-Checksumme) ein sogenannter digitaler Fingerabdruck berechnet. Anhand des privaten Schlüssels und des Fingerabdrucks kann eine eineindeutige Signatur für das PDF-Dokument erstellt werden. Somit wird beim Signieren wird nur der Fingerabdruck verschlüsselt und nicht das Dokument. Die Signatur wird zusammen mit dem Zertifikat, das den öffentlichen Schlüssel enthält, dem PDF-Dokument hinzugefügt.

Öffentlicher Schlüssel (Public Key) zum Überprüfen der digitalen Signatur Der öffentliche Schlüssel aus dem signierten PDF-Dokument wird zur Entschlüsselung der Signatur (Ergebnis: digitaler Fingerabdruck) verwendet. Parallel hierzu wird der digitale Fingerabdruck aus dem Ursprungsdokument erneut berechnet. Sind die Fingerabdrücke aus der Signatur und dem Ursprungsdokument gleich, wurden keine nachträglichen Änderungen seit der Signierung vorgenommen.

Detail-Informationen entnehmen Sie bitte der nachfolgenden schematischen Übersicht!

Abbildung 122: Schematische Darstellung zur Signierung in APROL

10.1.5 Was ist ein Zertifikat? Ein Zertifikat (hier: X.509-Format) besteht grundsätzlich aus folgenden Komponenten: 1) Identität des Inhabers (E-Mail-Adresse, Name, …)

10-4

2) Öffentlicher Schlüssel (Public Key) des Inhabers

3) CA-Signatur, d.h. von der Zertifizierungsstelle erstellte Signatur über Identität des Inhabers und dem Öffentlicher Schlüssel des Inhabers

4) sowie optional CA-Zertifikat Zertifikat der Zertifizierungsstelle einschließlich deren Identität und Öffentlichen Schlüssel zur Überprüfung der CA-Signatur

10.1.6 In welchem Format werden Zertifikate gespeichert? Zertifikate können in diversen Dateiformaten gespeichert werden.

Die APROL-Zertifikate werden gemäß dem Standard PKCS#12 in Dateien mit der Endung '*.p12' gespeichert. Das standardisierte Format wird verwendet, um private Schlüssel mit dem zugehörigen Zertifikat passwortgeschützt zu speichern.

PKCS steht für Public Key Cryptography Standards und bezeichnet eine Reihe von kryptographischen Spezifikationen.

10.1.7 Was ist eine Zertifizierungsstelle? Eine Zertifizierungsstelle (englisch: Certificate Authority bzw. Certification Authority, kurz CA) ist eine Organisation, die von ihr signierte digitale Zertifikate herausgibt. Eine Zertifizierungsstelle kann ein spezielles Unternehmen oder eine Institution bzw. Abteilung innerhalb eines Unternehmens sein. Es können ebenfalls öffentliche Organisationen oder Regierungsstellen als Zertifizierungsstelle dienen, z. B. die Bundesnetzagentur in Deutschland.

10.1.8 Wozu dient ein Zeitstempelserver? Digitale Dokumente können mit einem zertifizierten Zeitstempel versehen werden. So kann zuverlässig nachvollzogen werden, wann ein Dokument erstellt bzw. unterzeichnet wurde. Es lässt sich somit eindeutig ermitteln, zu welchem Zeitpunkt somit originale, unveränderte Daten vorgelegen haben. Nachträgliche Vor- oder Rückdatierungen von Inhalten können so ausgeschlossen werden. Die Verwendung von Zeitstempeln setzt voraus, dass die herausgebenden Unternehmen oder Institutionen selbst vertrauenswürdig sind. Unternehmen bzw. Institutionen, die als Zeitstempel-Anbieter (ZSA) fungieren, werden als Timestamping Authority (TSA) bezeichnet.

In APROLwird die Verwendung eines Zeitstempel-Servers unterstützt.

10-5

10.2 Wie erstelle ich digitale Signaturen in APROL?

10.2.1 Wozu werden Zertifikate in APROL verwendet?

Zertifikate werden in APROL zu folgenden Zwecken verwendet:

als Stamm-Zertifikat bei der Erstellung von personifizierten Benutzer- und Operator-Zertifikaten

zur digitalen Zertifizierung (Zertifizierungsignatur) von PDF-Dokumenten durch das APROL-System

zur persönlichen digitalen Signierung (z.B. Genehmigungssignatur) von PDF-Dokumenten durch Operatoren und Benutzer

zum Aufbau gesicherter HTTP-Verbindungen (https) bei der Kommunikation mit dem Web-Server (nicht Bestandteil dieser Beschreibung)

LDAP-Zertifikat SSL-Verbindung zum LDAP-Server (nicht Bestandteil dieser Beschreibung)

10.2.2 Welche Zertifikate gibt es in APROL?

Für die digitale Signatur in APROL werden folgende Zertifikate unterschieden:

Zertifikatstyp Beschreibung

Stamm-Zertifikat Vom APROL-Stamm-Zertifikat (auch Wurzel oder Root-Zertifkat genannt) werden alle für APROL erstellten Zertifikate abgeleitet. Das APROL-Stammzertifikat wird ausschließlich von B&R erstellt. Der private Schlüssel (Datei: 'ca.key') und das Zertifikat (Datei: 'ca.crt') werden im Rahmen der APROL-Installation in getrennten Dateien im Verzeichnis /opt/aprol/etc abgelegt.

System-Zertifikat Mit dem System-Zertifikat wird standardmäßig jede PDF-Datei signiert (Zertifizierungsignatur). Das APROL-System-Zertifikat wird ausschließlich von B&R erstellt. Das System-Zertifikat (Datei: 'APROL_SYSTEM.p12') im Rahmen der APROL-Installation im Verzeichnis /opt/aprol/etc abgelegt.

Benutzer-Zertifikat Diese Zertifikate dienen zum Anbringen einer personifizierten Signatur durch einen Benutzer. Sie werden in der Benutzerverwaltung erstellt und enthalten die Identität des Engineering-Benutzers (insbesondere sein Login). Die Zertifikate werden im 'P12-Format' in der CAE-Datenbank gespeichert.

10-6

Zertifikatstyp Beschreibung

Operator-Zertifikat Diese Zertifikate dienen zum Anbringen einer personifizierten Signatur durch einen Operator. Sie werden im OperatorManager erstellt. Sie enthalten die Identität des Operators (insbesondere sein Login). Die Zertifikate werden im 'P12-Format' in der CAE-Datenbank gespeichert.

Das Stammzertifikat ist als Voreinstellung auf den APROL-Servern als vertrauernswürdige Zertifizierungsstelle in den installierten Profilen von Firefox, Konqueror und Adobe Reader eingetragen.

10.2.2.1 Wie werden Zertifikate für die digitale Signatur in APROL verwendet?

Die folgende Übersicht zeigt schematisch die Verwendung von Zertifikaten für die Signatur von PDF-Dokumenten in APROL:

Abbildung 123: Verwendung der Zertifikate in APROL

Verwendung des APROL System-Zertifikats: Mit diesem Zertifikat wird standardmäßig jede PDF-Datei eines im HTML-Format vorliegenden und im Web-Browser darstellbaren APROL Reports signiert.

Diese Signatur (Zertifizierungssignatur) wird standardmäßig beim Betätigen der Buttons [Drucken] oder [Dokument signieren] dem erstellten PDF-Dokument hinzugefügt.

Das APROL System Zertifikat ist vom APROL Stamm-Zertifikat abgeleitet und kann nicht durch ein externes Zertifikat ersetzt werden!

D. h. es bleibt auch dann vom APROL Stamm-Zertifikat abgeleitet, wenn für die Operator / Benutzer Zertifikate ein externes Stamm-Zertifikat verwendet wurde.

10-7

Verwendung des APROL Stamm-Zertifikats: Das APROL Stamm-Zertifikat wird für die Erstellung von Benutzer-Zertifikaten in der Benutzerverwaltung sowie von Operator-Zertifikaten im OperatorManager verwendet. Verwendung der Benutzer-Zertifikate: Benutzer-Zertifikate werden in der CAE-Datenbank abgelegt und stehen auf dem Engineering-Server zur Verfügung. Zur Erstellung der Genehmigungssignatur (via Button [Signieren]) durch einen Benutzer wird das Benutzer-Zertifikat aus der CAE-Datenbank ausgelesen. Detail-Informationen zur Erstellung eines Benutzer-Zertifikats und zur Signierung entnehmen Sie dem Kapitel Erstellen eines Benutzer-Zertifikats sowie Wie werden PDF-Dokumente in APROL signiert?

Anstelle der vom APROL Stamm-Zertifikat abgeleiteten Benutzer-Zertifikate können auch Zertifikate verwendet werden, die von einer externen Zertifizierungsstelle stammen (externe Zertifikate).

Verwendung der Operator-Zertifikate: Operator-Zertifikate werden in der CAE-Datenbank abgelegt. Beim Build-Vorgang werden sie in die 'access'-Datenbank übernommen. Diese wird via Download auf den Protokoll-Server und alle Operator-Stationen übertragen. Zur Erstellung der Genehmigungssignatur (via Button [Signieren]) durch einen Operator wird das Operator-Zertifikat aus der 'access'-Datenbank ausgelesen. Detail-Informationen zur Erstellung eines Benutzer-Zertifikats und zur Signierung entnehmen Sie dem Kapitel Erstellen eines Operator-Zertifikats sowie Wie werden PDF-Dokumente in APROL signiert?

Anstelle der vom APROL Stamm-Zertifikat abgeleiteten Operator-Zertifikate können auch Zertifikate verwendet werden, die von einer externen Zertifizierungsstelle stammen (externe Zertifikate).

10.2.2.2 Können Zertifikate verwendet werden, die von einer externen Zertifizierungsstelle kommen?

Für die digitale Signatur in APROL können auch von externen Zertifizierungsstellen stammende, kostenlose (bzw. erworbene) Zertifikate verwendet werden. Voraussetzung hierfür ist, dass diese Zertifikate im '*.p12'-Format vorliegen und im Dateisystem des APROL-Servers (z. B. im Verzeichnis /home/<CC-Account>/ENGIN/EXCHANGE/) abgelegt wurden.

Abhängig von der externen Zertifizierungsstelle werden diese automatisch in die Zertifikatsliste des Web-Browsers eingetragen und müssen anschließend von dort exportiert und auf den APROL-Server übertragen werden.

Der Import eines externen Zertifikats kann ausschließlich in der Engineering-Umgebung (Benutzerverwaltung oder OperatorManager) erfolgen Ist das externe Zertifikat ggf. bereits in der CAE-Datenbank vorhanden (d. h. bereits importiert), erfolgt eine Sicherheitsabfrage, die ein ungewolltes Überschreiben des vorhandenen Zertifikats unterbindet.

10-8

10.2.3 Wie werden Zertifikate für Benutzer und Operatoren erstellt? Das nachfolgende Kapitel beschreibt zunächst die Erstellung eines Benutzer-Zertifikats in der Benutzer-Verwaltung. Da die Vorgehensweise für die Erstellung von Operator-Zertifikaten grundsätzlich identisch ist, werden daher nur mögliche Unterschiede aufgezeigt.

10.2.3.1 Erstellen eines Benutzer-Zertifikats Ein Benutzer-Zertifikat wird in der 'Benutzerverwaltung / Reiter Stammdaten' erstellt. Anhand der Checkbox 'Signierung ist möglich' kann für den ausgewählten Benutzer gesteuert werden, ob ein Benutzer ein Dokument (anhand eines ggf. bereits vorhandenen Zertifikats) signieren darf. Gleichzeitig werden damit die Buttons zur Erstellung und Verwaltung des Zertifikats sensitiv geschaltet. Fehlende bzw. unvollständige Eingaben in den Pflichtfeldern für die Zertifikatserstellung werden anhand zugehöriger Validatoren überprüft.

Abbildung 124: Pflichtfelder für die Erstellung eines Benutzer-Zertifikats

Sind alle notwendigen Eingaben erfolgt, kann anhand des nun sensitiven Buttons [Zertifikat erzeugen] der gleichnamige Dialog aufgerufen werden.

10-9

Tragen Sie eine Gültigkeitsdauer für das Zertifikat ein und vergeben Sie ein Zertifikatspasswort. Das hier eingebene Zertifikatspasswort dient ausschließlich der digitalen Signatur von PDF-Dokumenten. Das Passwort sollte aus Sicherheitsgründen nicht das Passwort des APROL-Benutzers sein. Bestätigen Sie die Eingaben mit [Zertifikat erzeugen]. Daraufhin wird das erstellte Zertifikat angezeigt.

Abbildung 125: Eingabe von Gültigkeitsdauer und Passwort

Abbildung 126: Anzeige des erstellten Benutzer-Zertifikats

Nachdem ein Benutzer-Zertifikat erstellt wurde, können folgende Funktionalitäten ausgeführt werden:

10-10

Zertifikat anzeigen:

Zertifikat löschen: Ein vorhandenes Benutzerzertifikat wird nach Bestätigung einer zusätzlichen Sicherheitsabfrage gelöscht.

Zertifikat importieren: Der Import von Zertifikaten ermöglicht die Übernahme von Zertifikaten, die mit einem geheimen Passwort versehen sind. Somit ist nicht erforderlich, dass eine zentrale Zertifikatserstellung von einem Engineering- Benutzer, unter Vergabe eines Zertifikatpasswortes, vorgenommen werden muss. Wurde für den aktuell eingeloggten Benutzer bereits ein Zertifikat erstellt, erfolgt eine Sicherheitsabfrage, die ein ungewolltes Überschreiben des vorhandenen Zertifikats unterbindet.

Zertifikat exportieren: Ein vorhandenes Benutzer-Zertifikat kann im '*.p12'-Format in das Datei-System des Engineering-Servers exportiert werden.

10.2.3.2 Erstellen eines Operator-Zertifikats Ein Operator-Zertifikat wird im 'OperatorManager / Reiter Stammdaten' erstellt. Zusätzlich zu den Benutzer-Zertifikaten kann in den 'Projekteigenschaften' unter dem Reiter 'Runtime (1/2) die Default-Gültigkeitsdauer von Operator-Zertifikaten voreingestellt werden. Die dort vorgenommene Einstellung beeinflusst jedoch nicht die Gültigkeit bereits vorhandener Operator-Zertifikate. Der Ablauf innerhalb der Engineering-Umgebung entspricht dem zuvor beschriebenen Ablauf zur Erstellung von Benutzer-Zertifikaten. Informationen zur Erstellung von Operator-Zertifikaten im Runtime-System und deren

Rückführung in die Engineering-Umgebung, entnehmen Sie bitte dem Kapitel Wie kann auf einer laufenden Anlage für einen Operator ein Zertifikat erstellt werden und zur Signatur verfügbar gemacht werden?

10-11

10.2.4 Wie werden PDF-Dokumente in APROL signiert?

Abbildung 127: Schaematische Darstellung der Signatur-Erstellung in APROL

10.2.5 Welche Eingaben sind bei der Erstellung einer Signatur erforderlich?

Durch das Anbringen einer persönlichen Signatur bestätigt der Unterzeichnende die Kenntnisnahme des Inhaltes. Zusätzlich kann er im Feld 'Grund' eine spezielle Begründung für die Unterschrift (z. B. 'Genehmigung') eintragen.

Aus allen APROL-Reports kann über den Toolbar-Button 'Dokument signieren' das Formular 'Dokumente und Berichte signieren' aufgerufen werden. Wählen Sie über den zugehörigen Radio-Button aus, ob es sich um ein Benutzer- oder ein Operator-Zertifikat handelt. Tragen Sie in dem Formular den Benutzer- /Operatornamen, das Zertifikats-Passwort, eine Begründung und den Ort ein.

Nach der Eingabe des Benutzer- / Operatornamens und des zugehörigen Zertifikatspasswortes werden bei Betätigung des Buttons [Anwenden] die zugehörigen Stammdaten automatisch eingeblendet.

10-12

Abbildung 128: Notwendige Eingaben für die Erstellung einer digitalen Signatur

Sind alle notwendigen Eingaben erfolgt, kann die Erstellung der digitalen Unterschrift über den Button [Signieren] ausgeführt werden.

Abbildung 129: Erstellen einer digitalen Unterschrift

Auf dem kontaktierten Server wird nun das PDF-Dokument erstellt, mit der APROL System Zertifizierungssignatur und der persönlichen Signatur des ausgewählten Benutzers / Operators versehen.

Anhand der Checkbox 'Sichtbares Signaturfeld auf der ersten Seite....' kann die Position für die Anzeige der Signatur eingestellt werden. Die Einstellung der Seitenausrichtung (Hochformat / Querformat) muss entsprechend der Ausrichtung des Quelldokuments, d. h. des zu signierenden PDFs, eingestellt werden.

Bei den APROL-Reports ist die Ausrichtung standardmäßig 'Querformat'.

10-13

Anschließend wird das PDF-Dokument zum Browser übertragen, der den Adobe Reader zur Anzeige startet.

Abbildung 130: Anzeige des signierten PDF-Dokuments im Adobe Reader

An dieser Stelle muss der Unterzeichner das Dokument inhaltlich nochmals prüfen. Das Dokument muss anschließend im Dateisystem abgespeichert werden, andernfalls wird keine Kopie des Dokuments archiviert. Anhand eines weiteren Beispiels wird die Gültigkeit der Zertifikatssignatur sowie der Unterschrift dargestellt.

Abbildung 131: Gültigkeit der Zertifikatssignatur sowie der Unterschrift

Als Ablageort für die signierten PDF-Dateien wird standardmäßig das Verzeichnis '/home/<CC-Account>/RUNTIME | ENGIN>/REPORTS/' vorgeschlagen.

10-14

10.2.6 Was ist der Unterschied zwischen Zertifizieren und Signieren beim Adobe Reader?

'Bei den meisten digitalen Signaturen handelt es sich um Genehmigungsunterschriften. Signaturen, die ein Adobe® PDF-Dokument zertifizieren, nennt man Zertifizierungssignaturen. Nur der erste Unterzeichner eines PDF-Dokuments (meist der Verfasser) kann eine Zertifizierungssignatur einfügen. Eine Zertifizierungssignatur bestätigt den Inhalt des Dokuments. Zudem ermöglicht sie dem Unterzeichner, die für das Dokument im Rahmen der Zertifizierung zulässigen Änderungen festzulegen. Änderungen am Dokument werden im Fenster 'Signaturen' angezeigt.' Quelle: http://help.adobe.com Umsetzung in APROL: Die Zertifizierungssignatur wird vom APROL-System (via 'System-Zertifikat) ausgeführt. (Bestätigung des Inhalts, Verfasser ist das APROL-System). Durch die Zertifizierungssignatur wird somit der Originalzustand zugesichert. Die personifizierte Genehmigungsignatur erfolgt vom Benutzer / Operator durch Verwendung das Benutzer- / Operator-Zertifikats. Durch die Genehmigungssignatur wird somit der Originalzustand nach der Genehmigung zugesichert. Gleichzeitig ist die Identität des Unterzeichners verifizierbar.

10.2.7 Wie kann nachträglich ein Operator-Zertifikat erstellt werden? Falls das Erstellen eines Operator-Passwortes in der Engineering-Umgebung aus Sicherheits- bzw. Geheimhaltungsgründen nicht gewünscht ist, kann ein Operator-Zertifikat zur Laufzeit erstellt werden. Damit ist es möglich, ein Zertifikat zu erstellen, desse Passwort ausschließlich dem jeweiligen Operator bekannt ist. Ebenso kann so bei einem ausgespähten Zertifikats-Passwort das Zertifikat unter Verwendung eines anderen Passwortes erneuert werden.

Die Passwortänderung eines Zertifikats ist nur über die Neuerstellung des Zertifikates möglich!

Um für einen Operator auf einer laufenden Anlage ein personifiziertes Zertifikat zun erstellen und zur Signatur verfügbar zu machen, ist wie wie folgt vorzugehen:

Schritt: Beschreibung

1 Anlegen eines neuen Operator-Zertifikats in der Runtime-Umgebung. Falls der OperatorManager in der Runtime-Umgebung gestartet wurde, wird das neue Zertifikat im Dateisystem im '*.p12'-Format abgelegt.

10-15


2 Das Zertifikat muss (ggf. via externem Datenträger) in das Dateisystem des Engineering-Servers übertragen werden (z. B. in das Verzeichnis /home/<CC-Account>/ENGIN/EXCHANGE/).

3 Auf dem Engineering-Server muss das neue Zertifikat anhand des OperatorManagers importiert und in die CAE-Datenbank übertragen werden.

4 Beim Build-Vorgang wird es automatisch in die Datenbank für Web-Zugriffe ('access'-Datenbank) überführt.

5 Durch den Download wird das Zertifikat auf alle Operator-Stationen sowie den Protokoll-Server verteilt.

10.2.8 Wann wird eine Signatur vom AdobeReader als gültig angezeigt?

Auf einem APROL Server werden die Signaturen standardmäßig als 'gültig' markiert, das das APROL Stammzertifikat über die APROL-Installation in die Liste der vertrauenswürdigen Zertifikate eingetragen ist. Eine Übersicht der gültigen Zertifikate erreichen Sie im Adober Reader unter dem Menüpunkt 'Document / Manage Trusted Identities'. Nach Auswahl des Eintrags 'Display / Certificates' werden alle im Adobe Reader vorhandenen Zertifikate (einschließlich Gültigkeitsdauer) aufgelistet.

Das APROL Stammzertifikat (APROL Root CA) ist in der Liste eingetragen.

Detail-Informationen zum APROL Stammzertifikat erreichen Sie über den Button [Show Certificate].

Abbildung 132: Anzeige der gültigen Zertifikate im Adobe Reader

Für einen Nicht-APROL-Server kann das APROL Stammzertifikat wie folgt importiert werden: Schritt: Beschreibung

1 Übertragen Sie das APROL Stammzertifikat vom APROL-Server (aus dem Verzeichnis /opt/aprol/etc/ca.crt) auf einen externen Datenträger. Kopieren Sie das Stammzertifikat auf den Nicht-APROL-Server.

10-16


2 Alle nachfolgend beschriebenen Schritte sind im Adobe Reader auf dem Nicht-APROL-Server durchzuführen. Bearbeiten sie die vertrauenswürdigen Identitäten Menü (Adobe 10): 'Bearbeiten / Schutz / Vertrauenswürdige Indentitäten verwalten'.

3

Abbildung 133

Wählen Sie unter 'Anzeige' den Eintrag 'Zertifikate' aus. Betätigen Sie den Button [Kontakte hinzufügen]. Wählen Sie das APROL Stammzertifikat aus.

4

Abbildung 134

Betätigen Sie den Button [Vertrauenswürdigkeit] .

10-17


5

Abbildung 135

Aktivieren Sie folgende Checkboxen: ' Dieses Zertifikat als vertrauenswürdigen Stamm' sowie 'Zertifizierte Dokumente'. Bestätigen Sie die Eingabe mit [OK].

6

Abbildung 136

Importieren Sie den Kontakt (Button [Importieren].

10-18


7

Abbildung 137

Der Importvorgang ist damit abgeschlossen. 8

Abbildung 138

In der Liste der vertrauenswürdigen Zertifikate ist nun das APROL Stamm-Zertififikat eingetragen.

10.2.9 Können Zertifikate als 'ungültig' deklariert werden? Für die selbst erstellten Benutzer- und Operator-Zertifikate ist ein Zurückziehen durch Erstellung und Verteilung einer Zertifikatssperrliste (englisch: Certificate Revocation List, kurz: CRL) nicht möglich.

10.2.10 Was mache ich, wenn das Passwort für ein Benutzer- / Operator-Zertifikat einem Dritten bekannt geworden ist?

Wurde das Passwort eines Benutzer- oder Operator-Zertifikats durch Dritte ausgespäht, so muss zwingend ein neues Benutzer- bzw. Operator-Zertifikat erstellt werden und über den beschriebenen Mechanismus zur Verfügung gestellt werden.

10-19

10.2.11 Wie sicher ist die APROL-Signatur?

Bei der APROL-Signatur handelt es sich um eine sog. 'Fortgeschrittene elektronische Signatur' (=elektronische Signatur, die es ermöglicht, die Authentizität und Unverfälschtheit der durch sie signierten Daten zu prüfen). Kennzeichen einer 'Fortgeschrittenen elektronischen Signatur':

schützt das signierte Dokument vor Veränderung

verwendet Signaturschlüssel

ist an den Schlüsselinhaber gebunden

Es handelt sich nicht um eine 'qualifizierte elektronische Signatur' Das Vorhandensein der privaten Schlüssel auf allen Operator-Stationen und dem Protokoll-Server schränkt die Sicherheit der Signaturen ein. Daher muss der Zugang zu den APROL-Servern restriktiv gehandhabt werden.

10.2.12 Wie signiere ich mit einem privaten (auf einem externen Datenträger vorhandenen) Zertifikat?

Es besteht grundsätzlich die Möglichkeit, ein nicht in APROL (d. h. in der CAE-Datenbank) vorhandenes, externes Zertifikat zu verwenden, das sich z.B. auf einem externen Datenträger befindet. Dieses muss im 'P12-Format' vorliegen. Wählen Sie zu diesem Zweck im Formular 'Dokumente und Berichte signieren' in der Drop-Down-Liste 'Zertifikat' den Eintrag 'Verwendung einer lokalen Zertifikatsdatei' aus und betätigen Sie anschließend den Button [Zertifikat auswählen].

Das lokale Zertifikat wird ausschließlich zur Signierung des aktuellen Dokuments verwendet und nicht dauerhaft gespeichert!

10-20

Abbildung 139: Verwendung eines 'lokalen Zertifikats'

10.2.13 Wie konfiguriere ich einen Zeitstempel-Server Um bei der Erstellung der Genehmigungssignatur einen zertifizierten Zeitstempel in die Signatur mit aufzunehmen, ist die 'Verwendung eines externen Zeitstempel-Servers' in den Projekteigenschaften (Reiter 'Runtime 1/2') auszuwählen.

Abbildung 140: Einstellung des Zeitstempel-Servers in den Projekteigenschaften

Beispiel für einn (kostenlosen) Zeitstempel-Server: URL:http://zeitstempel.dfn.de/

Funktionsweise: Zum Zeitpunkt der Signaturerstellung wird vom APROL-Server eine Anfrage, welche den Hashwert des Dokumentes enthält, zur konfigurierten URL geschickt. Der Zeitstempel-Server

10-21

ermittelt die aktuelle Zeit, signiert die Zeitangabe und den Hashwert des Dokuments und schickt diese Signatur zusammen mit seinem Zertifikat zurück. Die Signatur und auch das Zertifikat werden mit in das PDF-Dokument geschrieben. Für die Signatur des Zeitstempels verwendet der Zeitstempel-Server dabei sein eigenes Zertifikat. Dieses muss im Adobe Reader nach dem Öffnen des PDF-Dokumentes einmal als vertrauenswürdiges Zertifikat gekennzeichnet werden. In der Folge werden Zeitstempel dieses Zeitstempel-Servers in allen weiteren Dokumenten als vertrauenswürdig gekennzeichnet.

Bei Verwendung eines Zeitstempel-Servers muss sichergestellt sein, dass der konfigurierte Zeitstempel-Server via HTTP vom APROL-Server, auf dem die Signatur erstellt wird, erreichbar ist. Andernfalls wird die persönliche Gehnehmigungsignatur nicht erstellt! Das Dokument enthält dann lediglich die APROL System-Signatur mit dem Zeitstempel des APROL-Servers auf dem die Signatur erstellt wurde.

Im Dialog werden die Parameter des verwendeten Zeitstempel-Servers eingetragen:

Eingabefeld: Kurzbeschreibung: Defaultwert:

TSA-URL URL unter der der Zeitstempel-Server angeboten wird.

'http://zeitstempel.dfn.de' Bei diesem Anbieter ist keine Authentifizierung oder die Angabe einer TSA-Policy erforderlich.

TSA-Benutzer Benutzername zur Authentifizierung am Zeitstempel-Server. Dieses Feld ist nur auszufüllen, falls eine Authentifizierung vom Anbieter des Zeitstempel-Servers verlangt wird.

kein Eintrag

TSA-Passwort Passwort zur Authentifizierung am Zeitstempel-Server. Dieses Feld ist nur auszufüllen, falls eine Authentifizierung vom Anbieter des Zeitstempel-Servers verlangt wird.

kein Eintrag

TSA-Passwort-Wiederholung

Passwort-Wiederholung zur Authentifizierung am Zeitstempel-Server. Dieses Feld ist nur auszufüllen, falls eine Authentifizierung vom Anbieter des Zeitstempel-Servers verlangt wird.

kein Eintrag

TSA-Policy (OID) Optionale Angabe einer Policy Object-ID, die mit dem Request zum Zeitstempel-Server gesendet wird. Diese Feld ist nur auszufüllen, falls dies vom Anbieter des Zeitstempel-Servers verlangt wird. Der erforderliche Wert wird vom Anbieter vorgegeben.

kein Eintrag

10-22

11-1

11 TranslationManager Der TranslationManager bietet Ihnen optimale Unterstützung bei der effizienten und komfortablen Übersetzungsleistung. Mit diesem in APROL integrierten Werkzeug erstellen Sie benutzergeführt Übersetzungen für die Visualisierung, für das Alarm-System sowie für die APROL-Systemsoftware.

Detaillierte Informationen zur Lokalisierung von XLS- und CLT-Dateien (für Reports) finden Sie im Kapitel Übersetzung der xsl- und clt-Dateien. Detaillierte Informationen zur Lokalisierung von KDE-Menüs finden Sie in Kapitel Übersetzung des KDE-Menüs für APROL. Detaillierte Informationen zur Eingabe von chinesischen Zeichen finden Sie im Kapitel Werkzeuge für die Eingabe chinesischer Zeichen. Detaillierte Informationen zur Sprachumschaltung und zum GNU gettext-Mechanismus finden Sie im Kapitel Detail-Informationen zur Sprachumschaltung. Detaillierte Informationen zur Sprachumschaltung via gettext im Python API finden Sie im Handbuch 'D2 System API', Kapitel Sprachumschaltung mit gettext im Python API.

Verwenden Sie den TranslationManager zur Übersetzungsleistung, profitieren Sie von automatischen Plausibilitätsprüfungen und einer hohen Konsistenz der Übersetzungen in der jeweiligen Zielsprache. Dies ermöglicht Ihnen die professionelle Erstellung internationaler Texte. Der TranslationManager erspart Ihnen sowohl das manuelle Navigieren zu den jeweils erforderlichen PO-Dateien als auch das aufwendige Generieren und Installieren der MO-Dateien. Per Knopfdruck werden diese Aktionen automatisch ausgeführt, wobei der jeweilige Kontext (z. B. Alarmtexte oder Visualisierungstexte) berücksichtigt wird. Die einfache Handhabung sowie die vielen unterstützenden Details machen den TranslationManager zu einem unersetzlichen Werkzeug für die Übersetzungsleistung in APROL.

Folgende Highlights werden Sie in der Praxis besonders schätzen:

übersichtliche Listendarstellung der PO-Einträge

schnelle, einheitliche Übersetzung identischer Quell-Strings in unterschiedlichen PO-Dateien (erhöhte Konsistenz)

Anzeige von Übersetzungsvorschlägen

Sammelübersetzungen

Fehlererkennung und -kennzeichnung

funktionale Unterstützung durch Suchen, Ersetzen, Sortieren uvm.

Auswertung geleisteter / noch zu leistender Übersetzungsarbeit

direktes Generieren und Installieren der Übersetzungen

11-2

einfacher Import / Export im CSV-Format zur Bearbeitung in OpenOffice oder Excel

schnelle Aufteilung der Übersetzungsarbeit auf mehrere Übersetzungs-Teams via Import / Export

Die folgende exemplarische Darstellung zeigt, wie schnell und einfach die Übersetzung von Alarmtexten durchgeführt wird: 1. Wählen Sie im geöffneten Projekt im CaeManager "Extras/Alarmtexte übersetzen". 2. Führen Sie die gewünschten Übersetzungen durch, wobei Sie angezeigte Übersetzungsvorschläge direkt übernehmen können.

Abbildung 141: Übersetzungsleistung

3. Generieren und installieren Sie die MO-Dateien über die Toolbar oder über "Bearbeiten/Generieren und installieren der Übersetzungen".

Abbildung 142: Generieren und Installieren der MO-Dateien

Nach einem Build der Control Computer-Task und dem Download auf die Zielsysteme stehen dort die übersetzten Alarmtexte zur Verfügung.

11.1 Aufrufen des TranslationManagers

11-3

Zum Starten des TranslationManagers benötigen Sie das Benutzerrecht "TranslationManager: Start". Um den kontextbezogenen Aufruf des TranslationManagers für Alarm- und Visualisierungstexte zu ermöglichen, muss in den Projekteigenschaften / Reiter 'Lokalisierung' die Option 'Übersetzung der Alarm- und Visualisierungstexte vorbereiten' gesetzt sein. In der zugehörigen Combobox können Sie die gewünschte Zielsprache auswählen, für die entsprechende PO-Dateien erzeugt werden sollen.

Abbildung 143: Vorbereiten projektspezifischer Übersetzungen der Alarm- und Visualisierungstexte

Je nach Anwendungsfall können Sie den TranslationManager separat oder auch direkt aus dem CaeManager heraus starten, beispielsweise um Visualisierungstexte für ein bestimmtes Projekt zu übersetzen. In folgenden Kontexten kann der TranslationManager verwendet werden:

alarm: Lokalisierung von Alarmtexten (Dieser Kontext ist ausschließlich in der Engineering-Umgebung verfügbar).

visualisation: Lokalisierung von Visualisierungstexten (Dieser Kontext ist ausschließlich in der Engineering-Umgebung verfügbar).

11-4

aproltr: APROL Übersetzungsumgebung zur Lokalisierung der APROL-Systemsoftware (bereitgestellt durch Installation des APROL-Translation-devel-Pakets der Language-DVD)

Der Kontext wird beim Start des TranslationManagers automatisch ermittelt. Außerdem haben Sie die Möglichkeit, - für den Start der Anwendung einem bestimmten Kontext zu wählen (siehe Kommandozeilenebene) sowie - den Kontext im TranslationManager zu wechseln ("Neue Sitzung" bzw. "Sitzung laden" im Menü "Sitzung"). Die Statuszeile informiert Sie unter anderem über den aktuellen Kontext und die eingestellte Zielsprache.

Abbildung 144: Kontext-Anzeige mit Tooltipp in der Statuszeile

Durch die Festlegung des Kontextes werden die notwendigen Prozesse zum Generieren und Installieren der entsprechenden MO-Dateien definiert. Auf folgende Weise können Sie den TranslationManager starten: 1. Menü 'Extras' im CaeManager Sie können den TranslationManager kontextbezogen direkt aus dem CaeManager starten, wobei die entsprechenden PO-Dateien automatisch geladen werden. In einer geöffneten CAE-Bibliothek rufen Sie den TranslationManager zum Übersetzen von Visualisierungstexten dieser Bibliothek über "Extras/Visualisierungstexte übersetzen" auf. In einem geöffneten Projekt können Sie über das Menü "Extras" sowohl Visualisierungstexte als auch Alarmtexte dieses Projekts zum Übersetzen laden.

Weitere Hinweise zum Übersetzen von Visualisierungs- und Alarmtexten finden Sie im Kapitel Übersetzungsleistung mit dem TranslationManager.

2. KDE-Menü Des Weiteren können Sie das Übersetzungswerkzeug manuell über "Sprache/TranslationManager" im KDE-Menü starten. Dabei werden keine PO-Dateien automatisch geöffnet. Stattdessen können Sie diese kontextbezogen über "Sitzung/Neue Sitzung" bzw. "Sitzung/Sitzung laden" öffnen, oder Sie laden PO-Dateien selektiv über "Datei öffnen".

Detailinformationen zu Übersetzungs-Sitzungen entnehmen Sie bitte dem Kapitel Übersetzungs-Sitzungen.

11-5

3. Kommandozeilenebene Auch aus der Kommandozeile können Sie den TranslationManager starten. Auf diese Weise steht Ihnen dieses Überstzungswerkzeug auch in der Runtime-Umgebung zur Verfügung. Verwenden Sie zum Aufrufen der Anwendung bitte den Befehl TranslationManager oder den Befehl AprolStartTranslationManager. Über zusätzliche Aufrufoptionen können Sie das Startverhalten bedarfsgerecht anpassen und das automatische Laden bestimmter PO-Dateien/Kompendien steuern. Für den Befehl TranslationManager stehen Ihnen unter anderem folgende Aufrufoptionen zur Verfügung:

Option Beschreibung

-compendium <Dateiname> Verweis auf das Kompendium, das beim Start der Anwendung geladen werden soll. Beispiel: TranslationManager -compendium /home/<CC-Account>/ENGIN/PROJECTS/<Projektname>.pgp/po/ de/<Dateiname>_po_Compendium

-context <alarm|visualisation|aproltr>

Über diese Option werden alle für diesen Kontext benötigten Dateien automatisch geladen, Dies bedeutet für den - Kontext alarm: ALARM.po der in den Projekteigenschaften eingestellten Sprache - Kontext visualisation: VISU.po der in den Projekteigenschaften eingestellten Sprache - Kontext aproltr: alle zur Sprachumgebung passenden PO-Dateien, z. B. alle unter /home/aprotr/TRANSLATE/fr/ Bei Verwendung der Kontexte alarm und visualisation muss immer ein Projekt angegeben werden. Über das Projekt und den Kontext werden Zielsprache und Pfad der .po-Datei automatisch ermittelt. Um im Kontext aproltr PO-Dateien explizit zu laden, kann die Option -file verwendet werden. Beispiel: TranslationManager -context alarm -project Demoprojekt

-file <PO-Datei> Über diese Option wird eine PO-Datei nach dem Start der Anwendung geladen. Sollen mehrere Dateien geladen werden, verwenden Sie einen Wildcard-Filter oder die Option -filelist. Unter Verwendung von Wildcards muss der Pfad/Dateiname in Hochkommata gesetzt werden. Beispiel: TranslationManager -file "/home/engin2/ENGIN/PROJECTS/Demoprojekt.pgp/po/fr/ AL*.po"

11-6

Option Beschreibung

-filelist "<PO-Datei1; PO-Datei2; ...>"

Über diese Option werden mehrere PO-Dateien nach dem Start der Anwendung geladen. Die Liste der Dateien muss in Hochkommata gesetzt werden; die Dateinamen müssen durch ein Semikolon getrennt werden. Die Option -filelist wird bei Verwendung der Option -context ignoriert.

-import <CSV-Datei> Über diese Option wird eine CSV-Datei nach dem Start der Anwendung importiert. Beispiel: TranslationManager -import /home/engin2/tmp/alarm1.csv

-openall Diese Option lädt alle PO-Dateien im aktuellen Verzeichnis und bis zu zwei Verzeichnis-Ebenen tiefer. Dies ermöglicht einen schnellen Zugriff auf alle relevanten PO-Dateien. Die Suchtiefe kann mit der Option -scandepth verändert werden.

-opensession Diese Option öffnet eine gespeicherte Sitzung mit den zugehörigen PO-Dateien. Die Sitzungs-Dateien werden im Verzeichnis ENGIN/cnf/TranslationManager/user gesucht.

-project <Projektname> Über diese Option wird nach dem Starten der Anwendung ein APROL Projekt ausgewählt. Bei der Verwendung der Option -context kann die Kombination mit -project den Abfragedialog zur Projektauswahl unterdrücken.

-scandepth Diese Option definiert die Suchtiefe für die Option -openall.

11.2 Grundlegende Funktionalitäten .

11.2.1 Übersetzungs-Sitzungen Eine Übersetzungs-Sitzung ist eine benutzerspezifische Zusammenstellung von Dateien, die für die Übersetzungsleistung im TranslationManager benötigt werden. Sie beinhaltet - eine Liste von PO-Dateien - einen bestimmten Kontext (alarm, visualisation, aproltr) - optional ein Kompendium. Eine Sitzung kann gespeichert und später wieder geladen werden (Menü "Sitzung"). Dadurch wird die gezielte Bearbeitung bestimmter PO-Dateien beschleunigt und vereinfacht. Im Kontext "Übersetzung der Alarmtexte" wird z. B. die PO-Datei abhängig vom gewählten Projekt und der in den Projekteigenschaften gewählten Zielsprache geladen. Über "Sitzung/Sitzungs-Optionen" konfigurieren Sie die Sitzung.

11-7

Abbildung 145: Sitzungs-Optionen

Geben Sie unter dem Reiter Einstellungen eine Beschreibung für diese Sitzung ein. In der Statuszeile des TranslationManagers wird diese Beschreibung im Tooltipp zur Kontextanzeige dargestellt (siehe Kapitel Aufrufen des TranslationManagers). Außerdem können Sie hier den Verzeichnispfad zu den benötigten PO-Dateien sowie die Namen der zu verwendenden Dateien speichern. Im Kontext der Alarmtexte wird außerdem das gewählte Projekt angezeigt. Die automatische Anzeige von Übersetzungsvorschlägen beschleunigt die Übersetzungsarbeit, während gleichzeitig die Konsistenz der Übersetzungen erhöht wird. Ein externes Kompendium kann optional eingebunden werden. Wählen Sie hierzu unter dem Reiter Kompendium eine Kompondium-Datei für diese Sitzung aus. Dieses Kompendium liefert Ihnen dann zusätzliche Übersetzungsvorschläge.

Weitere Informationen hierzu entnehmen Sie bitte dem Kapitel Kompendien.

11.2.2 Kompendien Eine weitere Effizienzsteigerung sowie eine erhöhte Konsistenz der Übersetzungen erzielen Sie durch die Verwendung von Kompendien. Diese können mit Menü 'Sitzung' / Sitzungs-Optionene / Reiter 'Kompendien' geladen werden.

11.2.3 CSV-Import/Export Die geladenen PO-Dateien können zur Bearbeitung mit externen Werkzeugen (z. B. Excel) in eine CSV-Datei (CSV=comma separated values) exportiert werden. Die exportierten Daten

11-8

können Sie beispielsweise schnell aufteilen und verschiedenen Übersetzungs-Teams zur Verfügung stellen. Nach der Bearbeitung können die Daten wieder importiert werden. Die Funktionen "Export" und "Import" stehen Ihnen über das Menü "Datei" zur Verfügung. Wechseln Sie in dem sich öffnenden Dialog in das gewünschte Verzeichnis und geben einen Namen zum Speichern der CSV-Datei ein bzw. wählen Sie eine CSV-Datei für den Import aus. Defaultmäßig wird das Verzeichnis /home/<CC-Account>/ für den Import/Export geöffnet.

Beim Exportieren und anschließendem Importieren gehen alle in den PO-Dateien enthaltenen zusätzlichen Informationen wie Header, Format-Hinweise (z. B. #, python) etc. verloren! Lediglich der Status "unklar" wird exportiert und beim Import wieder gesetzt. Beim Import wird außerdem ein Standard-Header verwendet.

Die CSV-Datei ist nach folgendem Schema aufgebaut: "<Text-Domäne>","<Status>","<Mehrdeutigkeit>","<Originaltext>", "<Übersetzung>" Für den Übersetzungsstatus (Status) sind folgende Werte möglich: 1: übersetzt 2: unklar (fuzzy) 3: nicht übersetzt Der Zeichensatz für die CSV-Datei ist Unicode (UTF-8). Als Feldtrenner werden Kommata verwendet. Ist beim Importieren die PO-Datei geladen, von der aus exportiert wurde, so wird versucht, die Änderungen, die an den Übersetzungen vorgenommen wurden, in die geladenen PO-Dateien zurückzuführen bzw. zu importieren. Wird ein Originaltext aus der CSV-Datei unter den geladenen Text-Domänen gefunden, so wird dessen Übersetzung durch die Übersetzung aus der CSV-Datei ersetzt. Sofern sich die Übersetzung durch die Ersetzung mit der Variante aus der CSV-Datei geändert hat, wird der Eintrag durch folgendes Symbol als modifiziert gekennzeichnet:

Abbildung 125

11.3 Übersetzungsleistung mit dem TranslationManager Mit dem TranslationManager erbringen Sie schnell und komfortabel Übersetzungsleistungen für Visualisierungstexte, für Alarmtexte sowie für die APROL-Systemsoftware. Die Erzeugung der dazu erforderlichen PO-Dateien basiert auf dem Linux Gettext-Mechanismus. Vorbereitend aktivieren Sie für das jeweilige Projekt bitte die Option "Übersetzung der Alarm- und Visualisierungstexte vorbereiten" in den Projekteigenschaften, Reiter Runtime-Optionen. Dort stellen Sie ebenfalls die gewünschte Zielsprache für die Übersetzungen ein (siehe Kapitel Aufrufen des TranslationManagers). Aus einem Projekt heraus rufen Sie den TranslationManager kontextbezogenen über das Menü "Extras" auf (z. B. "Alarmstexte übersetzen"). Dabei werden automatisch die benötigten Dateien für die eingestellte Zielsprache ermittelt und geladen. Aus einer geöffneten CAE-Bibliothek können Sie den TranslationManager für die Übersetzung von Visualisierungstexten dieser Bibliothek starten. Wählen Sie hierzu "Visualisierungstexte

11-9

übersetzen" im Menü "Extras" und selektieren Sie in dem darauf folgenden Dialog die gewünschte Zielsprache für die Übersetzung.

Abbildung 146: Auswahl der Zielsprache im Kontext einer CAE-Bibliothek

Der TranslationManager zeigt Ihnen in der Spalte "Nr./Text-Domäne" den jeweiligen Dateinamen für die Quell-/Zielstrings an, wobei ein Tooltipp zusätzliche Informationen zum Verzeichnispfad liefert. Defaultmäßig wird für Visualisierungstexte einer Bibliothek folgender Pfad/Dateiname angelegt: /home/<CC-Account>/ENGIN/LIBRARIES/<Name der CAE-Bibliothek>/po/<localeCode>/<Bibliotheksname>_VISU.po Das manuelle Laden von Dateien ist folgendermaßen möglich:

Menüpunkt Beschreibung

"Datei/Öffnen" Laden von PO-Dateien "Datei/Import" Laden von CSV-Dateien "Sitzung/Sitzung laden" Laden einer gespeicherten Zusammenstellung von Dateien

(PO-Dateien und ggf. Kompendien) "Sitzung/Kompendium laden" Laden eines Kompendiums

Um eine geöffnete Text-Domäne aus dem TranslationManager zu entfernen, selektieren Sie bitte einen Eintrag dieser Domäne und wählen "Datei entfernen". Dadurch wird diese Text-Domäne (z. B. ALARM.po) mit allen Einträgen entfernt. Über "Ansicht/Baum-Struktur" bzw. über die Toolbar können Sie zwischen der Baumdarstellung und einer flachen Darstellung wechseln. Um die Übersichtlichkeit zu erhöhen, werden in der Baum-Darstellung mehrere Text-Domänen mit gleichem Originaltext in einem aufklappbaren Ast zusammengefasst. Durch Editieren des Wurzelelements (n Domänen) wird die Sammelübersetzung aller untergeordneten Text-Domänen ermöglicht.

Abbildung 147: Text-Domänen in Baumansicht

In der flachen Darstellung ist beispielsweise die kontextbezogene Sortierung auch bei mehreren identischen Originaltexten möglich (z. B. Sortierung nach ALARM.po, VISU.po). Im Tooltipp sowie in der Spalte "Mehrdeutigkeit" wird das mehrfache Vorkommen des gleichen Originaltextes gekennzeichnet.

11-10

11.3.1 Statusinformationen Die intuitive Bedienung des TranslationManagers wird durch klare Symbole zusätzlich unterstützt. Sowohl in der Spalte "Status" als auch in der Statuszeile der Anwendung erhalten Sie einen sofortigen Überblick über den aktuellen Stand der Übersetzungsleistung. Dies betrifft sowohl den Status der einzelnen Übersetzungen als auch den Status aller geladenen Text-Domänen in Summe.

11.3.2 Bearbeiten der PO-Dateien Durch einen Doppelklick auf die gewünschte Zeile wird dieser Eintrag im Dialog "Übersetzen" geöffnet.

Um einen anderen Originaltext in dem geöffneten Dialog "Übersetzen" zu bearbeiten, ist kein Schließen dieses Dialoges notwendig. Sowohl über die Schaltflächen innerhalb dieses Dialoges als auch über sämtliche Navigationsmöglichkeiten im Hauptfenster können Sie den gewünschten Text in den bereits geöffneten Dialog laden.

Abbildung 148: Arbeiten im Dialog "Übersetzen"

Der aktuelle Status der Übersetzung wird Ihnen durch die zuvor beschriebenen Symbole angezeigt. Möchten Sie den Originaltext als Basis für die Übersetzung verwenden, drücken Sie bitte [Originaltext kopieren]. Den kopierten Text können Sie dann direkt übernehmen oder in dem Feld "Übersetzter Text" editieren. Die Konsistenz der Übersetzungen lässt sich durch die Verwendung von Übersetzungsvorschlägen erheblich steigern. Als Übersetzungsvorschläge werden Ihnen alle Originaltexte der geöffneten Dateien (PO-Dateien und Kompendien) angezeigt, die mit dem ausgewählten Text genau oder annähernd übereinstimmen. Die Anzahl der angezeigten Übersetzungsvorschläge können Sie über das Feld Unschärfe der Vorschläge (im Hauptfenster des TranslationManagers) eingrenzen. Hierzu müssen Sie den Dialog "Übersetzen" nicht schließen. Die Änderung der Unschärfe wirkt sich unmittelbar auf die Anzeige der Vorschläge aus.

11-11

Abbildung 149: Eingrenzung der Übersetzungsvorschläge über die Unschärfe

Durch Selektieren eines Übersetzungsvorschlags wird der vorgeschlagene Text direkt als Übersetzung angezeigt, die Sie unverändert übernehmen oder weiter editieren können. Mit [Anwenden] übernehmen Sie die angezeigte Übersetzung. Über [OK] wird der Dialog zusätzlich geschlossen. Modifizierte Einträge werden durch folgendes Icon gekennzeichnet:

Abbildung 150

Erst durch das Speichern der Dateien ("Alles speichern", Speichern unter" oder "Alles speichern unter" im Menü "Datei") werden die Änderungen dauerhaft übernommen.

11.3.2.1 Navigation Nach der Übersetzung eines Originaltextes können Sie schnell und gezielt zu weiteren Einträgen navigieren. Verwealarmnden Sie hierzu bitte das Menü "Gehe zu". bzw. die entsprechenden Buttons im Hauptfenster oder direkt im Dialog "Übersetzen".

Abbildung 151: Schnelle Navigation zum gewünschten Eintrag

11-12

11.3.2.2 Sortieren Eine weitere Hilfe zum gezielten Übersetzen von Originaltexten bietet Ihnen die Sortierfunktion. Durch Anklicken der Spaltenüberschriften werden alle Einträge nach dieser Spalte sortiert (z. B. nach Status oder Originaltext).

11.3.2.3 Suchen/Ersetzen Sowohl das Suchen über Originaltexte und/oder Übersetzungen als auch das Ersetzen innerhalb von Übersetzungen wird Ihnen im TranslationManager angeboten. Wählen Sie hierzu bitte "Suchen" bzw. "Suchen und ersetzen" im Menü "Bearbeiten".

Abbildung 152: Text suchen

Möchten Sie eine unscharfe Suche durchführen, stellen Sie dies bitte über die Such-Optionen im Dialog "Suchen" ein. Die Unschärfe für Übersetzungsvorschläge wird bei der Suche nicht berücksichtig. Dadurch wird sowohl für die Suche als auch für die Vorschläge eine bedarfsgerechte Anpassung ermöglicht, ohne die jeweils andere Einstellung zu überschreiben. Die aktivierte unscharfe Suche wird durch einen gelben Hintergrund im Eingabefeld signalisiert.

Über die Optionen in diesem Dialog können Sie die Suche komfortabel verfeinern. Im Dialog "Suchen und ersetzen" können Sie die Suche nach Übersetzungen ebenfalls bedarfsgerecht anpassen und Ersetzungen selektiv oder global auf alle Fundstellen anwenden. Die Originaltexte sind ebenfalls in der CAE-Datenbank gespeichert (Bibliothek oder Projekt). Da über die PO-Dateien nicht die Quellen der Originaltexte sondern die Übersetzungen bearbeitet werden, ist das Suchen und Ersetzen ausschließlich in den Übersetzungen möglich.

11.3.2.4 Syntaxprüfungen Um die Genauigkeit der Übersetzungen zu erhöhen, unterstützt Sie der TranslationManager mit einer automatischen Syntaxprüfung. Auf diese Weise werden Sie nicht nur auf - zusätzliche Leerzeichen am Anfang oder

11-13

- abweichende Satzzeichen am Ende einer Übersetzung hingewiesen, sondern beispielsweise auch auf eine geänderte Reihenfolge von C-Argumenten. In dem Dialog "Übersetzen" werden Syntaxfehler durch folgendes Symbol signalisiert:

Abbildung 153

Detailinformationen erhalten Sie über den Tooltipp. Im Hauptfenster des TranslationManagers können Sie diese Detailinformationen zum selektierten Eintrag ebenfalls anzeigen lassen. Über "Ansicht/Warnungen anzeigen" können Sie die Syntax-Warnungen ein- und ausblenden.

11.3.3 Visualisierungstexte Visualisierungstexte können Sie im Engineering-System in eine andere Zielsprache übersetzen und für die Anzeige im Runtime-System zur Verfügung stellen. Übersetzte Visualisierungstexte werden im DisplayCenter zur Laufzeit in der Übersetzungssprache angezeigt. Dabei werden folgende Einträge von der Sprachumschaltung berücksichtigt:

in Bibliotheken:

Defaultwerte am Eingangspin eines Bildbausteins

Texte in Bildbausteinen

Konstanten im Konfigurations-Dialog der Widgets

Statische Tooltipps in Bildbausteinen

Strings innerhalb des Python-Codes eines Bildbausteins

Dynamisierungsart "Textliste"

in Projekten:

Texte in der Prozessgrafik

Bildbausteine in CFCs und Hypermakros

Konstanten im Konfigurationsdialog von Widgets in der Prozessgrafik

Detaillierte Informationen zur Sprachumschaltung via gettext im Python API finden Sie im Handbuch 'D2 System API', Kapitel Sprachumschaltung mit gettext im Python API.

Aus den vorgenommenen Übersetzungsleistungen in den hinzugelinkten CAE-Bibliotheken wird beim "Build all (Projekt)" das Kompendium /home/<CC-Account>/ENGIN/PROJECTS/<Projektname>.pgp/po/<localeCode>/libraries_compendium.po erstellt, welches Ihnen Übersetzungsvorschläge für das CAE-Projekt anbietet.

11-14

Übersetzungsleistungen, die für einzelne CAE-Bibliotheken erstellt wurden, fließen automatisch in das CAE-Projekt ein, wenn Bildbausteine aus den bereits übersetzen CAE-Bibliotheken verwendet werden. Daher sollten Übersetzungen immer zuerst im Kontext der CAE-Bibliotheken durchgeführt werden. Änderungen und Erweiterungen der Übersetzungen können Sie im Kontext des Projekts durchführen. Diese Änderungen werden nicht in die Übersetzungen der CAE-Bibliotheken zurückgeführt.

Folgendermaßen führen Sie die Lokalisierung der Visualisierung durch: 1. Starten des TranslationManagers aus dem Kontext einer Bibliothek via "Extras/Visualisierungstexte übersetzen" und Auswahl der Zielsprache.

Bei der erstmaligen Aktivierung der Option bzw. nach der Änderung der gewünschten Zielsprache muss in der CAE-Bibliothek ein "Build (Bibliothek)" erfolgen, um die entsprechende PO-Datei zu erzeugen.

2. Erstellen der Übersetzungen (siehe Kapitel Bearbeiten der PO-Dateien) und Speichern der PO-Datei 3. Wechsel in das Projekt und Auswahl der Zielsprache über die Projekteigenschaften (siehe Kapitel Aufrufen des TranslationManagers) 4. Führen Sie ein "Build all (Hardware)" für den Control Computer durch, um im Verzeichnis /home/<CC-Account>/ENGIN/PROJECTS/<Projektname>.pgp/po/<localeCode>/ - die PO-Dateien für die konfigurierte Zielsprache zu erzeugen - das Kompendium "libraries_compendium.po" aus den PO-Dateien der verwendeten Bibliotheken zu erzeugen 5. Starten des TranslationManagers via "Extras/Visualisierungstexte übersetzen" und Erstellen der Übersetzungen 6. "Bearbeiten/Generieren und installieren der Übersetzungen" 7. Download auf die Zielsysteme

Weitere Informationen hierzu entnehmen Sie bitte dem Handbuch "B3 CAE Bibliotheks Engineering", Kapitel Lokalisierung in der Visualisierung.

11-15

Abbildung 154: Schematischer Ablauf der Lokalisierung in der Visualisierung

11.3.4 Alarmtexte Projektierte konstante Texte an den Alarmbausteinen (AprCcAlarm, AprCcAlarmBasic) können beim Projekt-Engineering in eine alternative Sprache übersetzt werden. Zur Laufzeit werden diese übersetzten Texte im Runtime-System angezeigt und aufgezeichnet. Folgende Alarm-Daten unterliegen der Sprachumschaltung:

I/O-Konstanten am Eingang TEXT der Alarmbaustein-Instanzen (Anzuzeigender Alarmtext)

I/O-Konstanten am Eingang ALIAS der Alarmbaustein-Instanzen (Bezeichnung für das Meldesystem)

Sowohl die in CFCs als auch die in Hypermakros platzierten Alarmbausteine werden dabei berücksichtigt.

Abbildung 155: Konfiguration der I/O-Konstanten in der platzierten Instanz eines Alarmbausteins

11-16

Bei der Sprachumschaltung können natürlich nur konstante Texte und deren Übersetzungen berücksichtigt werden. Dynamisch generierte Alarmtexte unterliegen nicht der Sprachen-Lokalisierung.

Die Lokalisierung der Alarm-Daten wird in folgenden Schritten durchgeführt: 1. Einmalige Konfiguration der Zielsprache in den Projekteigenschaften (siehe Kapitel Aufrufen des TranslationManagers)

Bei der erstmaligen Aktivierung der Option bzw. nach der Änderung der gewünschten Zielsprache muss im CAE-Projekt ein "Build (Hardware)" für den Control Computer erfolgen, um die entsprechende PO-Datei zu erzeugen.

2. Starten des TranslationManagers via "Extras/Alarmtexte übersetzen" und Erstellen der Übersetzungen (siehe Kapitel Bearbeiten der PO-Dateien) 3. "Bearbeiten/Generieren und installieren der Übersetzungen" 4. Download auf die Zielsysteme

Abbildung 156: Workflow Lokalisierung der Alarmtexte

Im Runtime-System werden die Alarmtexte in der projektierten Sprache und (sofern vorhanden) in der übersetzten Sprache vom AlarmServer aufgezeichnet. Die übersetzte Sprache muss dabei der in den Projekteigenschaften/Runtime-Optionen konfigurierten Zielsprache entsprechen. Der AlarmServer stellt unter diesen Voraussetzungen die projektierten und die übersetzten Texte sowohl dem DisplayCenter als auch dem AlarmReport zur Verfügung. Die Anzeige dieser Texte ist von der Sprache der gestarteten Runtime-Appliaktion abhängig. Zur Laufzeit wird ermittelt, welche Sprache für das DisplayCenter bzw. den AlarmReport eingestellt ist. Die Anzeige der Daten erfolgt nach folgender Auswertung:

11-17

eingestellte Sprache = Zielsprache der Übersetzungen

eingestellte Sprache ≠ Zielsprache der Übersetzungen

- Anzeige in der übersetzten Sprache (bei fehlender Übersetzung Fallback auf die projektierte Sprache) - Anzeige des projektierten Textes im Tooltipp

- Anzeige in der projektierten Sprache - Anzeige des übersetzten Textes (sofern verfügbar) im Tooltipp

Abbildung 157: Anzeige der übersetzten Alarmtexte im DisplayCenter (Originaltext im Tooltipp)

In den Alarm-Eigenschaften wird sowohl der Text der projektierten Sprache angezeigt als auch (sofern verfügbar) der übersetzte Text. Zur Anzeige der Alarm-Eigenschaften wählen Sie bitte "Eigenschaften" im Kontextmenü des Alarmereignisses. Im AlarmReport können Sie über CGI-Parameter in der URL die Anzeige der Originaltexte und Übersetzungen manuell steuern. Hierzu stehen Ihnen folgende Parameter zur Verfügung: Parameter Beschreibung

usetr=y - Anzeige in der übersetzten Sprache (bei fehlender Übersetzung Fallback auf die projektierte Sprache) - Anzeige des projektierten Textes im Tooltipp

usetr=n - Anzeige in der projektierten Sprache - Anzeige des übersetzten Textes (sofern verfügbar) im Tooltipp

checktr=y - Anzeige in der projektierten und in der übersetzten Sprache - bei fehlender Übersetzung Anzeige "fehlt!"

11-18

Abbildung 158: Verwendung des Parameters checktr=y

11.3.5 Übersetzen der APROL-Systemsoftware

Um den multilingualen Einsatz von APROL weiter zu optimieren, können Sie Übersetzungen für Texte in den grafischen Oberflächen des Prozessleitsystems durchführen und in die Software integrieren.

Für die Lokalisierung der APROL-Systemsoftware, die meist von Übersetzungsbüros erstellt wird, steht Ihnen die separate Übersetzungsumgebung "aproltr" zur Verfügung. Über die Language-DVD richten Sie die Umgebung ein, wobei ein neuer Linux-Benutzer namens "aproltr" angelegt wird. Für diesen Benutzer wird das Verzeichnis /home/aproltr/TRANSLATE/ mit weiteren sprachenspezifischen Unterverzeichnissen (de/, en/, fr/, ..) erzeugt. Die Language-DVD stell Ihnen ebenfalls die Sprachpakete für APROL zur Verfügung.

Folgende Sprachpakete werden Ihnen auf der Language-DVD zur Installation bereitgestellt:

Chinesisch

Französisch

Italienisch

Niederländisch

Polnisch

Rumänisch

Russisch

Slowakisch

Spanisch

Tschechisch

11-19

Ungarisch

Norwegisch

Finnisch

Türkisch

Litauisch

Portugiesisch

Dänisch

Lettisch

Schwedisch

APROL-Translation-devel-Paket zur Erbringung der Übersetzungsleistung für APROL

Beachten Sie hierzu bitte die Kapitel Inhalt der Language-DVD und Erstellung einer Übersetzungsumgebung.

12-1

12 Sprachen-Lokalisierung .

Detaillierte Informationen zur Lokalisierung von Sprachen in APROL und der KDE-Umgebung sowie zur Sprachumschaltung finden Sie im Kapitel TranslationManager.

12.1 Installations-Voraussetzung

Die Quell-Sprache von APROL für eine Übersetzungsleistung ist englisch.

Die Übersetzung wird vom betreuenden Technischen Büro (TB) erbracht, verwaltet und dem Endkunden zur Verfügung gestellt. Folgende Pakete müssen installiert sein: AutoYast DVD für Linux: Speziell folgende Selektionen: APROL AutoYast Chinesisches Grundsystem APROL AutoYast Russisches Grundsystem APROL Installations-DVD: APROL Installation Es müssen folgende Pakete zusätzlich installiert werden:

APROL Language für AutoYast (mindestens Version 3.0-0) DVD mit Zusatzpaketen zur Unterstützung der Fremdsprache

12.2 Inhalt der APROL Language-DVD

Die Anzahl der unterstützten Sprachen wird sukzessive erweitert (z. B. im APROL R 3.6-08 standen bei installierter APROL Language-DVD 20 Sprachen zur Auswahl).

Informationen zur Erweiterung der Lokalisierung entnehmen Sie bitte der Dokumentation 'A1 Release Notes'.

Die gewünschte Selektion kann mit YaST ausgewählt und installiert werden.

Durch die Installation der APROL Language-DVD und zusätzlich der Selektion "APROL AutoYast Chinesisches Grundsystem" bei Chinesisch oder der Selektion "APROL AutoYast Russisches Grundsystem" bei Russisch:

12-2

- kann KDE auf die Fremdsprache umgeschaltet werden und es stehen X11-Fonts (xterm-Ausgaben) in der Fremdsprache zur Verfügung. - kann APROL in die Fremdsprache umgeschaltet werden. - kann die Übersetzung in den Sprachdateien (po-Dateien) erfolgen, und dieselben können installiert werden, sodass das Ergebnis der Übersetzung auch überprüft werden kann. - können nach Übersetzung der speziell für den XSL- und CLT-Bereich (Diagnose, Audit Trail, Reports) zuständigen po-Dateien die sprachspezifischen xsl- und clt-Dateien generiert und installiert werden. Anmerkung: Diese zweistufige Vorgehensweise ist deshalb nötig, weil es hier keine dynamische Sprachumschaltung zur Laufzeit gibt, sondern sprachspezifische xsl- und clt-Dateien. - Steht speziell für chinesische Spracheingaben (Simplified Chinese) ein Eingabe-Tool zur Verfügung

Mit der Installation der Selektion "APROL AutoYast Chinesisches Grundsystem" wird das chinesisches Eingabewerkzeug "fcitx" bereitgestellt. In einer chinesischen Sprachumgebung wird standardmäßig jedoch ein anderes Werkzeug, nämlich "xcin", aktiviert und beim Start von KDE hochgepoppt. Um für ein gegebenes System (Engineering, Runtime, Operator, Übersetzungs-Entwickler "aproltr") jedoch das Werkzeug "fcitx" zu aktivieren, folgen Sie bitte den im Kapitel Arbeiten mit dem Werkzeug fcitx aufgeführten Anweisungen.

12.3 Erstellung einer Übersetzungsumgebung Folgende Schritte sind zur Erstellung einer Übersetzungsumgebung notwendig: Schritt Beschreibung

1 Installation "APROL-Translation-devel" 2 Wechseln ins Verzeichnis "/home/aproltr/TRANSLATE/" 3 Ausführen von "make newLanguage LANGUAGE=<localename>"

Zu Schritt 1: Durch die Installation der Selektion "APROL-Translation-devel" mit (YaST) wird ein neuer Linux-Benutzer namens "aproltr" angelegt. Im Home-Verzeichnis dieses Benutzers wird ein Unterverzeichnis "TRANSLATE" erzeugt, in dem alle pot-Sprachdateien enthalten sind. Diese beinhalten alle Quellbezeichner. Die pot- Dateien haben folgenden Inhalt (Beispiel: CaeManager.pot) ... #: CaeManager.cc:219 msgid "&Working area"

12-3

msgstr "" ... Die msgid-Einträge stellen alle zu übersetzenden Zeichenketten bzw. Quell-Strings dar. Zu Schritt 2: -·Wechseln ins Verzeichnis "/home/aproltr/TRANSLATE/"

Zu Schritt 3: (Beispiel für Niederländisch) - Ausführen von "make newLanguage LANGUAGE=nl" Die Umgebung für eine Übersetzung wird unter /home/aproltr/TRANSLATE/nl angelegt. Dort werden die leeren po-Dateien (abgeleitet von den pot-Sprachdateien) abgelegt.

12.4 Schritte der Übersetzungsleistung Die Übersetzungsleistung umfasst folgende Bereiche:

po-Dateien

xsl /clt-Dateien

Projektspezifische Engineering-Daten

12.4.1 Übersetzen der po-Dateien Große Teile der sprachspezifischen Beschreibungen in der caedb werden über den po-Mechanismus der Sprachumschaltung unterworfen. Die entsprechenden po-Dateien sind im Folgenden aufgelistet: Hardware-Katalog: CAEDB_AprolHwc.po Treiber-Beschreibungen: CAEDB_AprolPnkMod.po Gateway-Regeln: CAEDB_AprolRules.po APROL-System-Informationen: CAEDB_AprolSystem.po Benutzer-Rechte: CAEDB_UserRights.po SysInfo: CAEDB_sysinfo.po Engineering-Tipps: CAEDB_Tipps.po

Zur Übersetzung der po-Dateien sind folgende Schritte notwendig:


1 po-Dateien editieren 2 Ausführen von "make"

12-4


3 Ausführen von "make install"

Zu Schritt 1: Alle po-Sprachdateien werden im Unicode-Format (UTF-8) gehalten. Dies ist ein Kodierungs-System, das die meisten der weltweit vorkommenden Sprachen unterstützt. Es sichert problemlos die Internationalisierung, erlaubt erstmalig mehrere Sprachkombinationen, da alle Sprachen in einer einzigen Kodierung abgelegt sind. Nachdem die po-Dateien erzeugt wurden, kann nun mit der Übersetzungsleistung mit einem geeigneten Editor (z.B. kwrite oder kbabel, + chinesisches Eingabe-Tool) eingepflegt werden. Die Übersetzungen sind unter msgstr einzutragen (vergleichen Sie hierzu das Kapitel Erstellung einer Übersetzungsumgebung, Schritt 1). Anmerkung: Unter TRANSLATE ist der derzeitig aktuelle (und bei B&R zurückgeführte) Stand der chinesischen und der russischen po-Dateien schon enthalten (Unterverzeichnisse "zh_CN" für "Simplified Chinese" und "ru" für Russisch). Zu Schritt 2: Nach getätigter Übersetzung ist unter /home/aproltr/TRANSLATE ein make durchzuführen. Dadurch werden alle po-Dateien ins Binärformat konvertiert (Ablage als gmo-Datei im po-Bereich sowie zusätzlich lokale "Installation" als mo-Datei unter po/LC_MESSAGES). Zusätzlich wird im po-Bereich eine check-Datei abgelegt (Bsp.: zh_CN.check), wo alle noch nicht übersetzten Strings sowie die als fuzzy gekennzeichneten Einträge aufgeführt sind: Fuzzy-Einträge ("unscharfe" bzw. ungenaue Übersetzungen) entstehen immer dann, wenn im Source-Bereich (hier: pot-Datei) eine Änderung gemacht wurde, so dass beim "make" (Mergen der neuen pot-Datei mit der sprachspezifischen po-Datei) die schon getätigte Übersetzung als nicht mehr aktuell bzw. als überarbeitungsbedürftig gekennzeichnet wird. Als "fuzzy" gekennzeichnete Einträge werden nicht in die gmo- bzw. mo-Dateien übernommen, werden also ignoriert. Deshalb muss ein evtl. vorhandener fuzzy-Eintrag nach erfolgter Übersetzung gelöscht werden! Beispiel: CaeManager: Übersetzungs-String "Display/Hide user specific working versions" muss bearbeitet werden! changecontrol_clt : Übersetzungs-String "Audit Trail" fehlt ! Zu Schritt 3: Durch ein "make install" werden diese Binär-Dateien installiert (als mo-Dateien, unter /opt/aprol/share/locale/zh_CN/LC_MESSAGES).

Daraufhin kann die Übersetzung geprüft werden.

Zur Kontrolle der Übersetzungsleistung ist ein Neustart der entsprechenden Anwendungen zwingend erforderlich.

Anmerkung zu den Alt-Letter-Code Einträgen:

12-5

Die Alt-Letter-Codes bzw. Shortcuts sind durch ein Ampersand "&" gekennzeichnet. Dieser steht unmittelbar vor dem Shortcut-Zeichen, wie im folgenden Beispiel gezeigt: msgid "&Close" msgstr "XXX (&C)" , wobei "XXX" die Übersetzung darstellt. Es sollte das Alt-Letter-Zeichen des Quellstrings (hier "C") auch im Zielstring eingegeben werden, und zwar in Klammern. Dadurch ist es auch dem nicht der Fremdsprache mächtigen Benutzer/Operator möglich, APROL in der Fremdsprache zu bedienen (Vorliegendes Beispiel: Schließen der Anwendung (Menü "Close") durch Betätigen der Tastenkombination [Alt] + [C]).

12.4.2 Übersetzung der xsl- und clt-Dateien (APROL-Menüs: Diagnose sowie Reports) Da die xsl- und clt-Dateien keine zur Laufzeit wirksame Sprachumschaltung haben, sondern in sprachspezifischer Form vorliegen, wobei die Übersetzungen auch hier in po-Dateien (*_xsl.po. *_clt.po) vorliegen, müssen die sprachspezifischen xsl- und clt-Dateien nach Übersetzung dieser po-Dateien durch ein "make" noch generiert werden, wie im folgenden erläutert wird. Unter dem Verzeichnis "TRANSLATE" gibt die Unterverzeichnisse "XSL" und "CLT", die die xsl- und clt- Quelldateien enthalten. Das Generieren der sprachabhängigen xsl- und clt-Dateien geschieht durch Patchen der Quell-xsl- und -clt-Dateien (Eintrag PccTr(xxx) wird gepatcht) mit der zugehörigen Übersetzung, welche aus den zugehörigen mo-Sprachdateien entnommen wird. Beispiel: Nach Eingabe/Änderung einer Übersetzung in /home/aproltr/TRANSLATE/zh_CN/systeminfo_xsl.po ist anschließend ein erstes "make" in diesem Verzeichnis durchführen.

Dadurch wird die Binärdatei systeminfo_xsl.gmo im aktuellen Verzeichnis erzeugt und unter /home/aproltr/TRANSLATE/zh_CN/LC_MESSAGES/systeminfo_xsl.mo

installiert (nötig, da die Sprachübersetzungen beim Erzeugen der zugehörigen sprachspezifischen XSL-Datei dieser "lokal" installierten Sprachdatei entnommen wird).

Wird nun unter /home/aproltr/TRANSLATE/ ein zweites "make" durchgeführt, wird unter /home/aproltr/TRANSLATE/XSL die sprachspezifische Datei erzeugt (./086/systeminfo/systeminfo.xsl).

Vor dem zweiten "make" ist zwingend ein "make clean" auszuführen!

Diese entsteht aus der Quelldatei ./systeminfo/systeminfo.xsl durch Patchen aller Pcctr-Einträge durch die zugehörige Übersetzung, entnommen aus oben genannter mo-Sprachdatei. Auszug (eine Zeile mit sprachspezifischem Eintrag) aus systeminfo.xsl (Quelldatei und sprachspezifische Zieldatei): ./systeminfo/systeminfo.xsl:<title><xsl:text>PccTr("System informations")</xsl:text></title>

./086/systeminfo/systeminfo.xsl:<title><xsl:text>chinesische Übersetzung</xsl:text></title> Ein anschließendes "make install" unter /home/aproltr/TRANSLATE wird neben den mo-Sprachdateien (/home/aproltr/TRANSLATE/zh_CN/*.gmo wird als *.mo unter /opt/aprol/share/locale/zh_CN installiert)auch der XSL- und CLT-Bereich installiert:

xsl-Dateien unter /home/aproltr/TRANSLATE/XSL/086 werden unter /opt/aprol/doc/xsl-sheets/086 installiert.

12-6

clt-Datein unter /home/aproltr/TRANSLATE/CLT werden in /opt/aprol/doc/clt/086 installiert.

Abbildung 159: Übersicht zum Übersetzungs-Mechanismus der XSL-Dateien

12.4.3 Übersetzung des KDE-Menüs für APROL

In Linux 9.3 wird der APROL KDE-Menü-Baum durch folgende Dateien aufgebaut: /etc/xdg/menus/aprolmain.menu Einbinden (Merge) von aprol.menu Heimat-Verzeichnis des Engineering-/Runtime-/Operator-Systems: <home-dir>/.config/menus/aprol.menu:

Definition des APROL-Menü-Baums in XML-Struktur

12-7

Hier sind eingebunden: /opt/aprol/share/desktop-directories/*.directory (Definition der Untermenüs im APROL KDE-Baum) sowie /opt/aprol/share/applications/*.desktop (Definition der Menüs im APROL KDE-Baum)

Zur Übersetzung des APROL-KDE-Menüs in die gewünschte Zielsprache sind die desktop-Dateien und die directory-Dateien zu editieren und zu erweitern. Bsp.:AprolStartOperatorManager.desktop: # KDE Config File # Attention: This is an UTF-8 file # and must be edited in an UTF-8 environment [Desktop Entry] Encoding=UTF-8 GenericName=Starts OperatorManager GenericName[zh_CN]=Starts OperatorManager GenericName[de]=Startet OperatorManager GenericName[en_US]=Starts OperatorManager Name=OperatorManager Name[zh_CN]=XXXXXXX Name[de]=OperatorManager Name[en_US]=OperatorManager Exec=AprolStartOperatorManager Icon=/opt/aprol/doc/html/Icons/operatormanager.png Path= Type=Application Terminal=0 TerminalOptions= X-KDE-SubstituteUID=false X-KDE-Username= Categories=X-APROL-ENGIN;X-APROL-RUNTIME Um z.B. die chinesische Sprachunterstützung (zh_CN) zu gewährleisten, sind folgende Einträge zu machen: GenericName[zh_CN]=Starts OperatorManager Name[zh_CN]=XXXXXXX Dabei ist unter Name[zh_CN] die chinesische Bezeichnung einzutragen (sie erscheint als Menüeintrag in der Oberfläche), unter GenericName[zh_CN] sollte nicht die eigentliche "Beschreibung" eingetragen werden, da sonst APROL nur noch von der Landessprache mächtigen Benutzern/Operatoren bedient werden kann. Vielmehr sollte der englische Name (hier OperatorManager) eingetragen werden.

12-8

Unter Linux 8.x erschien die Beschreibung (GenericName) als Tooltip, bei Linux 9.x ist es anders: Sie kann nur sichtbar gemacht werden, wenn die Kickerleiste so konfiguriert wird, daß die Beschreibung auch angezeigt wird, sie erscheint dann in Klammern. Anmerkung: Die Kickerleiste kann so konfiguriert werden, dass entweder nur der Menü-Name (=Name-Eintrag) angezeigt wird, oder aber der Name und die Beschreibung (=GenericName-Eintrag) in Klammern, oder aber die Beschreibung und der Name in Klammern (Kickerleiste, rechte Maustaste, Kontrollleiste einrichten, Menüs, K-Menü, Format der Menü-Einträge: Nur Name, Name (Beschreibung), Beschreibung (Name)). Desgleichen sind die directory-Dateien zu editieren und der sprachspezifische Eintrag zu machen: Beispiel: aprol-druck.directory [Desktop Entry] Icon=/opt/aprol/doc/html/Icons/printer.png Name=Print Name[de]=Druck Name[en_US]=Print Name[zh_CN]=XXX Bisher wurde noch kein Mechanismus zum Verwalten und Rückführen dieser Dateien bereitgestellt. Anmerkung: Die Arbeit mit kmenuedit ist an dieser Stelle recht umständlich und wird dabei nicht in Erwägung gezogen.

12.4.4 Übersetzung innerhalb der caedb (projektspezifische Daten oder B&R-Bibliotheken) Es ist zwar einerseits möglich, innerhalb des CaeManager Übersetzungen in die Zielsprache zu tätigen, andererseits können mit dem Datenbank-Tool "tbio" die sprachabhängigen Teile eines Bereichs der caedb in Form einer ASCII-Datei exportiert werden, um die Übersetzungen in dieser Datei mit einem Editor (z.B. kwrite) effektiver durchzuführen und anschließend zurückzuführen (in die caedb sowie im Falle der B&R-Bibliotheken in die APROL Sourcen). Die B&R-Bibliotheken (APROL, DCS, IEC61131, ISO10628, SYSTEM, SYSTEM_RIO und STANDARD) sowie die Bibliothek "SampleTrigRec" (Beispiele zur Verwendung kundenspezifischer Aufzeichnungs-Bausteine) beinhalten sprachspezifische "Beschreibungen", die je nach Art der Beschreibung (Kurzbeschreibung, normale Beschreibung, Kommentar, Hinweise, url-Eintrage für htm-Hilfeseiten, usw.) in speziellen Feldern der Form <feldname><lang> abgelegt sind.

Bei <feldname> handelt es sich um die Art der Beschreibung (derzeit: caption, comment, desc, hints, info, introduction, maindesc, reference, rem, restrictions, short, text, url) und bei <lang> um den Ländercode (001 für englisch, 049 für deutsch, 086 für chinesisch, ...). Beispiel: desc049.

12-9

Das Exportieren sowie das - nach erfolgter Übersetzungsleistung vorzunehmende - Importieren mit dem Datenbank-Tool "tbio" wird beispielhaft an der Bibliothek "Standard" und der Zielsprache Chinesisch (Ländercode 086) erläutert. Für die Export-Funktion muss der exakte Pfad des zu exportierenden Bereichs angegeben werden (hier: \L\L/STANDARD). Über die Option "-g" wird darüber hinaus der Ländercode der zu exportierenden Zielsprache übergeben. Der tbio-Aufruf lautet für den Export: tbio –S ”” /home/engine/ENGIN/caedb -x '\L\L/STANDARD' -g 086 > caedb_export_libSTANDARD.txt

Anmerkung: Der Export wird in eine ASCII-Datei (caedb_export_libSTANDARD.txt) umgeleitet. Diese enthält nur die sprachspezifischen Anteile der Standard-Bibliothek, wie weiter unten exemplarisch gezeigt wird. Falls schon ein Eintrag in der Zielsprache vorliegt, wird dieser ausgegeben, ansonsten, falls vorhanden, der englische oder der deutsche Eintrag (d.h. Suchordnung: 001, 049, ... , erster Treffer wird ausgegeben), jede Zeile wird beim Export durch den "tbio" entsprechend kommentiert, wie folgende Auszüge zeigen: // desc086: original entry.

\L\L/STANDARD\G/Zeitbausteine (

desc086 = "schon vorhandene chinesische Übersetzung"

)

// no attribute named "desc001", using "desc049".

\L\L/STANDARD\INTERN\GlobalVar (

desc086 = "Globale Variablen der Bibliothek"

)

// no attribute named "desc001", using "desc049".

\L\L/STANDARD\OS\PLC/m68k/V0232 (

desc086 = "No specific aspects for this OS version in this library."

)

// using "desc001".

\L\L/DCS\B/DcsHmAdj\V3.0\FP-CODE\IB/95 (

desc086 = "Desired value on locking"

)

Nach dem Exportieren können anschließend die Übersetzungen in dieser ASCII-Datei vorgenommen werden (Die in der Regel vorhandenen englischen Einträge werden in die Zielsprache übersetzt). Das Re-Importieren in die caedb erfolgt wiederum über den tbio: tbio caedb -S localhost -i –m caedb_export_libSTANDARD.txt

Die Option "-m" (Merge-Modus) führt dazu, dass schon vorhandene Übersetzungen (in der caedb) und die zusätzlichen, zu importierenden, Übersetzungen zusammengeführt werden, wobei die importierte Übersetzung eine in der caedb bereits vorhandene überschreibt.

Im Falle einer B&R-Bibliothek muss zudem die ASCII-Datei in die APROL Sourcen zurückgeführt werden.

12-10

12.5 Test der Übersetzungsleistung Das Umschalten auf die Testsprache "th" bzw. den Ländercode "099" dient nur zu Testzwecken. Dazu werden mit APROL die zugehörigen Sprachdateien (/opt/aprol/share/locale/th/*.mo) ausgeliefert. Sie enthalten die Quellbezeichner (englisch), welchen ein Unicode-Sonderzeichen vorangestellt ist. So kann im Zweifelsfall geprüft werden, ob - ein in der Oberfläche angezeigter Bezeichner tatsächlich durch die Sprachumschaltung geschleust wird (Unicode-Sonderzeichen muss angezeigt werden) - die Anzeige tatsächlich unicode-fähig ist (Zeichen muss korrekt angezeigt werden) Interne Anmerkung: Derzeit ist keine globale Umschaltung auf "th" noch nicht möglich (AprolSelectLanguage 099), es muss somit die Anwendung explizit in einem xterm unter Angabe der Sprache gestartet werden: Beispiel: AprolStartCaeManager -languageCode 099

12.6 Werkzeuge für die Eingabe chinesischer Zeichen Es gibt eine vielfältige Anzahl von Eingabe-Werkzeugen (xcin, scim/skim, fcitx, ...). Diese werden als 'An X Input Method Server for Chinese' bezeichnet. Detail-Informationen zu den verwendeten KDE-Fonts: Name: ttf-arphic-20001125-589

Summary: Chinese TrueType fonts by Arphic Technology (only license in this package) Beispiel eines Font: AR PL KaitiM GB,12,-1,5,50,0,0,0,0,0 Name: ttf-arphic-gkai00mp-20001125-589 Summary: "AR PL KaitiM GB" Chinese TrueType font by Arphic Technology Name: ttf-founder-simplified-0.20040419-6 Summary: simplified Chinese TrueType fonts made by Beijing Founder Electronics Beispiel eines Font: FZSongTi,20,-1,5,50,0,0,0,0,0 Detail-Info zu den verwendeten X11-Fonts: rpm-Paket "ifntchia", X11-Font für Chinese simplified (GB2312.1980), im bdf-Format (guob16.bdf GB2312 + GB8565-88 by Koichi Yasuoka), ermittelbar durch Eingabe des Kommandos "xslfonts":

Diese Fonts unterstützen nur die Medium-Einstellung des xterm! Sichtbares Problem: Nicht alle Zeichen werden korrekt angezeigt! Bitte benutzen Sie xiterm anstatt xterm (Internationalized Terminal Emulator for X11), dann werden alle chinesischen Zeichen korrekt angezeigt!

12-11

12.7 Arbeiten mit dem Werkzeug fcitx a) Umgebung einstellen und fcitx starten export LC_CTYPE="zh_CN.UTF-8"

Die Erweiterung "UTF-8" ist zwingend erforderlich, da ansonsten Eingabezeichen z.B. im DisplayEditor nicht korrekt abgespeichert werden!

export XMODIFIERS="@im=fcitx"

export XIM=fcitx

export XIM_PROGRAM=fcitx

export GTK_IM_MODULE=fcitx

export QT_IM_MODULE=fcitx

fcitx in dieser Umgebung starten: Eingabe-Tool poppt hoch. Anmerkung: Soll diese Umgebung für aproltr immer aktiv sein bzw. schon beim Start von KDE aktiviert werden , muss diese in einem der Skripte, die beim Start des X-Window Systems automatisch geladen werden, hinzugefügt werden (z.B. ~/.xinitrc oder ~/.xsession, bei SuSE Linux am besten in der Datei "~/.xim). Durch Erzeugen der Datei .xim im Heimatverzeichnis mit den oben aufgeführten Einträgen (Setzen der Umgebungsvariablen für fcitx) wird für das vorliegende System nun "fcitx" aktiviert. Wenn für dieses System das graphische KDE in einer chinesischen Sprachumgebung gestartet wird, wird nun nicht mehr das Eingabewerkzeug "xcin" automatisch gestartet, das sonst standardmäßig aktiviert ist, bedingt durch die Default-Einstellung unter /etc/X11/xim.d/xcim. Das Eingabewerkzeug "fcitx" ist manuell zu starten (z. B. auf der Kommandozeile durch Eingabe des Befehls 'fcitx &').

Diese Umgebung muss natürlich auch für das Engineering-, wie Runtime- und Operator-System eingestellt werden können, um zum Beispiel mit dem CaeManager Bibliotheks-Bausteine in der Fremdsprache zu beschreiben.

Eingabe chinesischer Zeichen "Ctrl + Space" aktiviert das Eingabetool bzw. schaltet das Eingabefenster für chinesische Zeichen hoch. Durch erneute Betätigung von "Ctrl + Space" wird dieses geschlossen und es sind wieder "normale" Eingaben möglich. b) In der unter (a) eingestellten Umgebung den TranslationManager (oder einen KDE-Editor wie z. B. kbabel, kwrite) starten, um die po-Sprachdateien zu editieren; oder den CaeManager starten, um chinesische Eingaben (Projektbeschreibungen, Bibliotheks-Beschreibungen eingeben, ...) vorzunehmen.

Die fcitx-Umgebung ist notwendig, da nur so der KDE-Editor eine "Verbindung" zum "X Input Server" aufnimmt und die Eingabe chinesischer Zeichen ermöglicht.

Exkurs:

12-12

Die "APROL Suchmaschine" gestattet eine Suche sowohl über die Produkt-Dokumentation, über die B&R Hardware-Dokumentation, über die Dokumentation zu den Bibliotheken und auch über die kundenspezifische Projekt-Dokumentation. Die Suchmaschine ist in die APROL Sprachumschaltung integriert und besitzt somit Mehr-Sprachen-Fähigkeit.

Die im Kapitel Sprachumschaltung für die APROL Datenbank aufgeführten beschreibenden Texte werden innerhalb eines Vsets (spezielle APROL-interne Datenstruktur) in einem Feld mit Feldnamen descxxx (xxx steht für das jeweilige Land als Ländercode) und entsprechendem Feldwert gehalten. Übersetzungen in der caedb (projektspezifische Daten oder auch B&R- Bibliotheken)

Die Ausgangssprache von APROL ist Englisch. Ist die Umgebung in einer anderen Sprache gestartet und für diese noch keine Übersetzungsleistung erbracht, enthalten die Stellen an denen grundsätzlich eine Übersetzungsleistung erbracht werden kann, einen blauen Balken als Markierung. Innerhalb des Feldes steht der Eintrag auf die Fallback-Sprache Englisch mit dem dazugehörigen Ländercode.

12.8 Detail-Informationen zur Sprachumschaltung Zur Sprachumschaltung wird der GNU gettext-Mechanismus genutzt: Die Sprachinformation wird in "Referenztabellen" (Bezeichner in Quellsprache(=englisch), Bezeichner in Zielsprache) gehalten. Dies sind Dateien, die im "GNU message catalog"-Format (Dateierweiterung; .mo) abgelegt sind. Für jedes Binär-Programm (Anwendungen...), jede Shared-Library, jedes Skript (Bash, Perl, Python) und für die produktspezifischen Teile der CAE-Datenbank wird eine eigene mo-Datei gehalten. Beispiele: CaeManager + zugehörige shared Libraries: CaeManager-mo , sowie PccCaeExpl.mo PccCaePrj.mo . CAE-Datenbank: CAEDB_AprolHwc.mo CAEDB_AprolPnkMod.mo CAEDB_AprolRules.mo CAEDB_AprolSystem.mo CAEDB_UserRights.mo CAEDB_sysinfo.mo CAEDB_Tipps.mo Skripte: AprolConfig: AprolConfig.mo XSL-und CLT-Bereich: *_xsl-Dateien. Diese Dateien liegen im Verzeichnis /opt/aprol/share/locale/<localeCode>/LC_MESSAGES.

Auf diese wird zur Laufzeit zugegriffen (Stichwort: GNU gettext-Mechanismus).

<localeCode> steht für den 'locale code' der Zielsprache (en für englisch, de für deutsch, zh_CN für Chinesich (simplified chinese), ...).

12-13

12.9 Technische Anmerkungen (intern) In der CAE-Datenbank sind alle Bezeichner, die durch den po-Sprachmechanismus behandelt werden, auf spezielle Weise gekennzeichnet: Bsp. desc_tr = TR("englischer Bezeichner"), info_tr=TR("xxx"), ... Beim Erzeugen der CAE-Datenbank anhand der imp-Dateien werden die solchermaßen gekennzeichneten Bezeichner mittels xgettext-Tool aus den imp-Dateien geparst und in die zugehörige pot-Datei übernommen. Die eigentliche Übersetzung der Textausgaben (z.B. Menü- oder Meldungstexte) einer Anwendung geschieht in ASCII-Dateien, die mit der Extension ".po" gekennzeichnet sind. Dabei steht die Abkürzung PO für "Portable Object". Grundlage der Dateien sind PO-Templates, die die Extension .pot haben. Diese Templates werden während der Erzeugung (Kompilation) der ausführbaren Programme bzw. Bibliotheken automatisch generiert und enthalten alle zu übersetzenden Bezeichner aus dem Quellcode der Anwendung. Dabei ermitteln Aufrufe des GNU-Werkzeugs xgettext, welche Texte im Quellcode zur Sprachumschaltung vorgesehen sind und trägt diese in die zur Anwendung gehörende POT-Datei ein. Die POT-Dateien bilden somit die einheitlichen Vorlagen für alle Übersetzungen, die zu den Anwendungen erzeugt werden sollen. Aus den POT-Dateien werden die PO-Dateien für die unterschiedlichen Sprachen abgeleitet. In den PO-Dateien werden den Strings einer Anwendung die entsprechenden Übersetzungen zugewiesen. Dabei ist eine einzelne PO-Datei als Referenztabelle genau einer Sprache und einer Anwendung zugeordnet. Aus den PO-Dateien werden mit Hilfe des GNU-Werkzeugs "msgfmt" die maschinenlesbaren Binärdateien mit der Endung .mo erzeugt. Dies sind Dateien, auf die die Anwendungen bei einer Sprachumschaltung zugreifen. Die Generierung dieser Binärdateien wird dem Übersetzer durch ein make-Skript abgenommen. Nach der Installation sind die MO-Files im Verzeichnis /opt/aprol/share/locale/<language>/LC_MESSAGES zu finden. Der Bezeichner <language> gibt dabei das Kürzel für die gewählte Sprache an. (z.B. de für Deutsch, en für Englisch)

13 Datenbank für das Parameter Management .

13.1 Allgemeines zur Datenbank für das Parameter Management .

13.1.1 Allgemeines zur Datenbank-Struktur Alle im Runtime-System benötigten Daten für das Parameter-Management (z.B. für den Upload und Download von Parametersätzen) werden in der relationalen SQL-Datenbank MySQL™ gehalten.

Bitte beachten Sie die besonderen Hinweise zur Lizenzierung im Kapitel Hinweise zur Lizenzierung.

Das zugrunde liegende Datenbank-Konzept garantiert hierbei eine sichere Trennung zwischen den im APROL-System (Engineering-System oder Runtime-System) erzeugten Daten und den über die offen gelegte Schnittstelle importierten Daten. Somit wird eine Veränderung von intern erzeugten Daten via SQL-Schnittstelle oder eine Manipulation externer Daten im Parameter Center aus Sicherheitsgründen unterbunden. Als Datenbank-Management-System dient der MySQL-Max Server, der intern Tabellen des Typs "innodb" verwendet.

Im Rahmen des Datenbank-Management-Systems wird für jedes APROL Runtime-System eine gleichnamige Datenbank im Verzeichnis /var/lib/mysql/ angelegt.

Jede angelegte Datenbank enthält:

sieben Tabellen für die Parameter-Daten des Engineering-Systems sowie der im Runtime-System erzeugten Parametersätze.

drei Tabellen für die Ankopplung externen Systemen (gekennzeichnet durch den Suffix "_EXT")

Für jede Datenbank werden standardmäßig folgende Benutzer eingerichtet:

Datenbank-Benutzer: Password:

doku_<Name der Datenbank> .doku ext_<Name der Datenbank> .extern

Die zugewiesenen Passwörter können nachträglich wie folgt geändert werden: mysqladmin -u <Datenbank-Benutzer> -p.doku password "<Neues Passwort>"

Der Benutzer "doku_<Name der Datenbank>" hat ausschließlich lesenden Zugriff auf alle Tabellen dieser Datenbank. Der Benutzer "ext_<Name der Datenbank>" darf darüber hinaus in den Tabellen für externe Ankopplungen Daten einfügen, ändern und löschen.

13-2

13.1.2 Beschreibung der Tabellen-Struktur Für die nachfolgende Beschreibung der Tabellen-Struktur gelten folgende Konventionen:

Tabellen-Namen werden in Großbuchstaben und Fettschrift dargestellt

Primärschlüssel werden in Fettschrift dargestellt

Fremdschlüssel werden kursiv dargestellt

Beachten Sie die im Übersichtsbild dargestellten Zusammenhänge und Abhängigkeiten. DESCRIPTION D_ID LangCode DescText INT NOT NULL (A)

INT NOT NULL

TEXT NOT NULL

Die Tabelle "DESCRIPTION" enthält alle Beschreibungen der einzelnen Anlagenteile, Parameter, Templates und Parametersätze. Das Feld "D_ID" enthält eine eindeutige Kennung der Beschreibung. Im Feld "LangCode" wird ein numerischer Ländercode verwendet um die Sprache des Beschreibungstextes im Feld "DescText" zu identifizieren. Eine bestimmte Beschreibung in einer vorgegebenen Sprache kann also an Hand des zusammengesetzten Primärschlüssels (D_ID, LangCode) abgefragt werden. In den Tabellen "EQUIPMENT", "PARAMETER", "TEMPLATE" und "PARAMSET" wird jeweils im Feld "D_ID" eine Referenz auf die entsprechende Beschreibung abgelegt. EQUIPMENT E_Instance E_Name Deleted D_ID VARCHAR(64) NOT NULL

VARCHAR(64) NOT NULL

BOOL NOT NULL

INT

Die Tabelle "EQUIPMENT" enthält alle definierten Anlagenteile. Als Primärschlüssel wird die Instanzbezeichnung im Feld "E_Instance" verwendet. Die Namen der Anlagenteile sind im Feld "E_Name" abgelegt. Das Feld "Deleted" wird intern verwendet um gelöschte Anlagenteile zu kennzeichnen, auf welche aus vorher definierten Templates referenziert wird und die aus diesem Grunde nicht gelöscht werden können. PARAMETER P_Name E_Instance Datatype Min Max VARCHAR(64) NOT NULL



DOUBLE DOUBLE

PARAMETER (Fortsetzung)

DefaultValue Unit isConst Deleted D_ID TEXT Not NULL

VARCHAR(30) BOOL NOT NULL

BOOL NOT NULL

INT

13-3

Die Tabelle "PARAMETER" enthält alle definierten Parameter. Als Primärschlüssel dient hier die Kombination aus dem Namen des Parameters im Feld "P_Name" und der Instanzbezeichnung des Anlagenteils. Bei dem Feld "E_Instance" handelt es sich um eine Referenz auf das gleichnamige Feld der Tabelle "EQUIPMENT". Die Felder "Datatype", "Min", "Max", "DefaultValue" und "Unit" enthalten die Attribute des Parameters, wie sie im Engineering angegeben wurden. Der Default-Wert in "DefaultValue" wird als TEXT-Typ innerhalb der Datenbank gehalten, um größtmögliche Flexibilität zu bieten. Dieser Wert wird intern an Hand der Datentyp-Information im Feld "Datatype" konvertiert. Das Flag vom Typ "Bool" im Feld "isConst" gibt an, ob es sich um einen Parameter (isConst = FALSE) oder um eine Anlagen-Konstante (isConst = TRUE) handelt. Das Feld "Deleted" wird wie bei den Anlagenteilen dazu verwendet, noch referenzierte Parameter als gelöscht zu markieren. TEMPLATE T_Instance T_Name Modified AprolUser D_ID VARCHAR(64) NOT NULL


BIGINT NOT NULL

VARCHAR(64) INT

TEMPLATE (Fortsetzung)

Persist BOOL NOT NULL

Die Tabelle "TEMPLATE" benutzt als Primärschlüssel die eindeutige Instanzbezeichung der Templates im Feld "T_Instance". Im Feld "T_Name" wird der Name des Templates abgelegt. Das Feld "Modified" enthält einen UNIX-Zeitstempel, welcher den Zeitpunkt der letzten Änderung angibt. Im Feld "AprolUser" wird der Name des APROL Benutzers abgelegt, welcher die letzte Änderung am Template vorgenommen hat. Das Flag "Persist" wird nur intern verwendet und kennzeichnet das Template als Satz remanenter Daten. PARAMSET PS_Name T_Instance AprolUser Modified RO D_ID VARCHAR(64) NOT NULL



BIGINT NOT NULL

BOOL NOT NULL

INT

In der Tabelle "PARAMSET" werden die Parametersätze abgelegt. Als Primärschlüssel dient hier die Kombination aus Parametersatz-Namen (Feld "PS_Name") und zugehöriger Template-Instanzbezeichung. Bei dem Feld "T_Instance" handelt es sich um eine Referenz auf das gleichnamige Feld der Tabelle "TEMPLATE". Das Feld "Modified" enthält einen UNIX-Zeitstempel, welcher den Zeitpunkt der letzten Änderung angibt. Im Feld "AprolUser" wird der Name des APROL Benutzers eingetragen, welcher die letzte Änderung vorgenommen hat.

13-4

Das Feld "RO" wird intern verwendet, um zwischen Parametersätzen aus dem Engineering-System (RO = TRUE) und Parametersätzen, die im Runtime-System angelegt wurden, (RO = FALSE) zu unterscheiden. Parametersätze, bei denen der Wert des Feldes "RO" = "TRUE" ist, können im Runtime-System nicht geändert werden, da sie bei einem Download aus dem Engineering-System zunächst gelöscht und anschließend aus dem Engineering-System erneut übertragen werden. TEMPLATE_PARAMS T_Instance P_Name E_Instance Fix VARCHAR(64) NOT NULL



BOOL NOT NULL

In der Tabelle "TEMPLATE_PARAMS" werden alle zu einem Template gehörigen Parameter gespeichert. Die Zusammensetzung der Templates wird durch Referenzen auf Einträge der Tabelle "PARAMETER" ("P_Name" und "E_Instance") und Templates aus der Tabelle "TEMPLATE" (referenziert durch "T_Instance") definiert. Der Wert des Feldes "Fix" für den Parameter eines Templates, wird im Projekt-Engineering festgelegt. Ist der Wert des Feldes "Fix" = "TRUE", so darf der Wert dieses Parameters im Runtime-System nicht geändert werden. PARAMSET_PARAMS T_Instance PS_Name P_Name E_Instance Value VARCHAR(64) NOT NULL




TEXT NOT NULL

PARAMSET_PARAMS (Fortsetzung) Fix BOOL NOT NULL

In der Tabelle "PARAMSET_PARAMS" werden analog zur Tabelle "TEMPLATE_PARAMS" nochmals alle Parameter eines Parametersatzes referenziert. Die Felder "T_Instance" und "PS_Name" referenzieren auf genau einen Parametersatz aus der Tabelle "PARAMSET". Die Felder "P_Name" und "E_Instance" referenzieren auf einen Parameter der Tabelle "PARAMETER". Das Feld "Value" enthält den Wert des Parameters innerhalb des Parametersatzes. Der Wert des Feldes "Fix" für den Parameter eines Templates wird im Projekt-Engineering festgelegt. Ist der Wert des Feldes "Fix" = "TRUE", so darf der Wert dieses Parameters im Runtime-System nicht geändert werden. Durch die erneute Speicherung der Parameter eines Parametersatzes bleiben auch (im Runtime erzeugte) Parametersätze eines (im Engineering) geänderten Templates in ihrer ursprünglichen Zusammensetztung erhalten. Durch einen Vergleich der enthaltenen Parameter eines Parametersatzes mit den Parametern des zugehörigen Templates können somit geänderte Templates im ParameterCenter markiert werden.

13-5

PARAMSET_EXT PS_Name T_Instance User Modified D_ID VARCHAR(64) NOT NULL


VARCHAR(64) BIGINT NOT NULL

INT

PARAMSET_PARAMS_EXT T_Instance PS_Name P_Name E_Instance Value VARCHAR(64) NOT NULL




TEXT NOT NULL

DESCRIPTION_EXT D_ID LangCode DescText VARCHAR(64) NOT NULL



Die Tabellen "PARAMSET_EXT", "PARAMSET_PARAMS_EXT" und "DESCRIPTION_EXT" (gekennzeichnet durch den Suffix "_EXT") dienen der Ankopplung externer Systeme. Anhand dieser Tabellen können, sofern der Datenbank-Benutzer über entsprechende Rechte verfügt, Daten hinzugefügt werden.

Der Datenbank-Benutzer "ext_<Name der Datenbank>" verfügt über die notwendigen Rechte. Das zugehörige Passwort lautet: ".extern".

Die Struktur der externen Tabellen ist weitgehend identisch zu den entsprechenden internen Tabellen. Lediglich die Felder "RO" der Tabelle "PARAMSET" sowie das Feld "Fix" der Tabelle "PARAMSET_PARAMS" sind in den entsprechenden externen Tabellen nicht enthalten. Um Daten in die externen Tabellen einfügen zu können, müssen die als Fremdschlüssel markierten Felder auf bereits bestehende Einträge in den internen Tabellen verweisen. Somit muss z. B. beim Einfügen eines Parametersatzes bereits der Eintrag im Feld "T_Instance" im gleichnamigen Feld der Tabelle "TEMPLATE" existieren. Gleiches gilt für alle Felder der externen Tabelle "PARAMSET_PARAMS_EXT" (Ausnahme: Feld "Value"). Weiterhin müssen sich die Werte eines Parameters (Feld "Value") in der Tabelle "PARAMSET_PARAMS_EXT" innerhalb der Min- bzw. Max-Werte befinden, die in der Tabelle "PARAMETER" anhand der Felder "Min" bzw. "Max" angegeben wurden. Die Namen der externen Parametersätze, die in der Tabelle "PARAMSET_EXT" anhand des Feldes "PS_Name" festgelegt werden, müssen sich von den Namen, die in der internen Tabelle "PARAMSET" enthalten sind, unterscheiden. Sofern der Name eines Parametersatzes doppelt verwendet wird, so wird der Name der internen Tabelle vorrangig verwendet. Das bedeutet, dass im ParameterCenter der Eintrag aus der internen Tabelle "PARAMSET" dargestellt wird.

13-6

Die Beschreibungen zu den externen Parametersätzen sollten in der Tabelle "DESCRIPTION_EXT" abgelegt werden, wobei ein gültiger Ländercode und eine eindeutige Kennung vergeben werden müssen.

Einzelheiten entnehmen Sie bitte der Beschreibung zu Tabelle "DESCRIPTION".

Die Kennung wird im Feld "D_ID" der Tabelle "PARAMSET_EXT" angegeben, um die Beschreibung dem Parametersatz zuzuordnen. Der Ländercode wird Programmintern aus den Systemeinstellungen ermittelt und bei der Anzeige berücksichtigt.

13.1.2.1 Diagramm "Abhängigkeiten" Das Diagramm "Abhängigkeiten" stellt alle Tabellen in Ellipsenform dar. Anhand von Pfeilen zwischen den Ellipsen wird eine Fremdschlüssel-Abhängigkeit symbolisiert. Die Namen der Schlüsselfelder sind hierbei an den jeweiligen Pfeilen eingetragen. Beispiel: Der dargestellte Pfeil zwischen "PARAMSET" und "TEMPLATE" mit der Beschriftung "T_Instance" besagt, dass das Feld "T_Instance" aus der Tabelle"PARAMSET" auf das entsprechende Feld in der Tabelle "TEMPLATE" verweist. Anhand des Diagramms wird die vorgegebene Reihenfolge für das Einfügen von Datensätzen ersichtlich: Soll ein Parametersatz eingefügt werden, so muss zunächst die Beschreibung in der Tabelle "DESCRIPTION_EXT" erfolgen. Anschließend muss der Parametersatz selbst in die Tabelle "PARAMSET_EXT" eingetragen werden. Daraufhin können die zugehörigen Parameter in die Tabelle "PARAMSET_PARAMS_EXT" eingefügt werden. Letzteres setzt die Existenz der verwendeten Parameter in der Tabelle "PARAMETER" voraus.

13.2 mySQL-Befehle für das Arbeiten mit der Datenbank


13.2.1 AprolConfigParameterManagement MySQL .


13.3 Allgemeines zur Replikation .

13-7


13.3.1 AprolConfigParameterManagement Replikation .


13.4 Backup .


13.5 Purge BinLog-Files .


13.6 Diagnose .


13.6.1 BuRMySQLToolbox .


13-8

13.7 Hinweise zur Lizenzierung

Bei der Verwendung des APROL Parameter-Managements sind besondere Lizenzbedingungen für MySQL-Anwendungen zu berücksichtigen. Beachten Sie bitte, dass der gesamte MySQL-spezifische Quelltext des Servers, die mysqlclient-Bibliothek und der Client sowie die GNU-readline-Bibliothek der GNU General Public License unterliegen.

Eine kommerzielle Nutzung von MySQL im Rahmen des APROL Parameter-Managements ist somit nur mit einer gültigen MySQL-Lizenz erlaubt.

Vergewissern Sie sich bitte, dass Ihre APROL Lizenz auch über eine gültige MySQL Lizenz verfügt. Falls Sie sich nicht sicher sind, ob für Ihr APROL-System eine gültige MySQL-Lizenz vorliegt, sind Sie verpflichtet, sich über den Umfang Ihrer APROL Lizenz zu informieren. Kontaktieren Sie in diesem Fall bitte Ihren zuständigen APROL-Vertrieb. Beachten Sie bitte auch, dass pro Maschine, auf der der MySQL-Server läuft eine MySQL-Lizenz benötigt wird. Es gibt keine Beschränkung hinsichtlich der Anzahl von MySQL-Servern, die auf einer Maschine laufen, oder hinsichtlich der Anzahl von Clients, die zur gleichen Zeit mit einem Server verbunden sind, der auf dieser Maschine läuft! Sie benötigen daher bei Verwendung des APROL Parameter-Managements für jeden prozessführenden Control Computer eine MySQL-Lizenz. Bei Verwendung eines Redundanz-Systems mit zwei prozessführenden Control Computern werden somit zwei Lizenzen benötigt.

14 Authentifizierung via LDAP / Active Directory-Server Zur Authentifizierung eines Engineering-Benutzers oder eines Operators kann optional ein separater openLDAP-Server bzw. Active Directory Server verwendet werden. Das Lightweight Directory Access Protocol (LDAP)ist ein Anwendungsprotokoll aus der Netzwerktechnik. Es erlaubt die Abfrage und die Modifikation von Informationen eines Verzeichnisdienstes (eine im Netzwerk verteilte hierarchische Datenbank) über ein IP-Netzwerk. Die Pluggable Authentication Modules (PAM) sind eine Softwarebibliothek, die eine allgemeine Programmierschnittstelle (API) für Authentisierungsdienste zur Verfügung stellt.

Grundlegende Information über LDAP und PAM finden Sie unter http://de.wikipedia.org

Hierbei werden die in der APROL Benutzer-Verwaltung oder im OperatorManager definierten Benutzer / Operatoren im LDAP-Server als konfigurierte Benutzer erwartet. Diese werden hinsichtlich ihres im LDAP-Server hinterlegten Passworts authentifiziert.

Die Vergabe der Rechte für das Prozessleitsystem wird ausschließlich über APROL realisiert.

Der LoginServer muss immer aktiv sein. Wird der LoginServer mutwillig oder durch einen Absturz gestoppt, so ist die Authentifizierung eines weiteren Benutzers nicht mehr möglich und das Auto-Log-Off bei eingestellter Leerlaufzeit wird nicht mehr durchgeführt. Ein Absturz oder das mutwillige Stoppen des LoginServers führt aber keinesfalls zu einer Behinderung beim Arbeiten mit APROL. Auch bei gestopptem LoginServer bleibt der bereits authentifizierte Benutzer angemeldet und gemäß seiner zugeordneten Rechte arbeitsfähig. Ein openLDAP-Server kann auf jedem Linux-Server im Netzwerk installiert werden, sofern er durch die APROL-Server, die eine Authentifizierung über LDAP durchführen, erreichbar ist. Es ist empfehlenswert, den openLDAP-Server auf einem Runtime-Server zu installieren, da ein Engineering-System für den laufenden Betrieb nicht zwingend notwendig ist und eine Operator-Station möglicherweise nicht immer verfügbar ist. Ein Active Directory Server kann auf jeden Windows-Server im Netzwerk installiert werden. Falls Engineering-Benutzer über LDAP authentifiziert werden sollen, muss auf jedem Engineering-Server der LDAP-Client eingerichtet werden. Falls Operatoren über LDAP authentifiziert werden sollen, muss auf jeder Operator-Station der LDAP-Client eingerichtet werden. Entscheiden Sie auf welchen Rechner Sie den Server installieren möchten und in welchem Umfang die Authentifizierung erfolgen soll (Engineering-Benutzer und/oder Operatoren). Nachfolgend finden Sie ein Leitfaden für openLDAP and Active Directory. Optionale Schritte werden am Anfang des jeweiligen Kapitels kenntlich gemacht.

Hierbei gilt: (S) = Server, (C) = Client, (A) = APROL

14-2

Abbildung 160: LDAP-Client-Konfiguration (Linux)

Grundsätzlicher Ablauf für ein openLDAP-Server:

Schritt: Kapitel

1 (S)Wie wird ein openLDAP-Server unter Linux mit dem YaST2 eingerichtet? (Kapitel: 14.5.1)

2 (S) Wie wird ein openLDAP-Server konfiguriert? (Kapitel: 14.5.3)

3 (S) Wie wird die Default-Passwortrichtlinie angepasst? (Kapitel: 14.5.3.1)

4 (S) Wie wird eine minimale Datenbank-Struktur eingerichtet? (Kapitel: 14.5.3.2)

5 (S) Wie wird ein LDAP-Query-Benutzer für den openLDAP Server eingerichtet? (Kapitel: 14.5.3.3)

6 (S) Wie wird ein Apache Directory Studio (ADS) unter Linux konfiguriert? (Kapitel: 14.5.6)

7 (S) Benutzer-Verwaltung openLDAP (Kapitel: 14.7)

8 (S) Wie wird ein Benutzer auf dem openLDAP-Server angelegt? (Kapitel: 14.7.4)

9 (C) Anbindung von APROL mit openLDAP / Active Directory Server (Kapitel: 14.9)

10 (S) Wie wird das PAM-LDAP-Modul für die Anbindung an den openLDAP-Server konfiguriert? (Kapitel: 14.9.3)

11 (S) Wie wird die Sicherheit der Verbindung zwischen einem APROL-Server und einem openLDAP-Server erhöht? (Kapitel: 14.10.1)

14-3

12 (S) Wie wird das für die SSL-Verbindung benötigte Zertifikat für einen openLDAP-Server erstellt? (Kapitel: 14.10.2)

13 (S) Wie werden unverschlüsselte Verbindungen zum openLDAP-Server unterbunden? (Kapitel: 14.10.3)

14 (C) Wie wird die SSL-Verschlüsselung auf dem APROL-Server aktiviert? (Kapitel: 14.10.4)

15 (C) Wie wird die Sicherheit der SSL-Verbindung verschärft? (Kapitel: 14.10.5)

16 (A) Wie wird die LDAP-Authentifizierung für das Engineering-System im CaeManager konfiguriert? (Kapitel: 14.11.1)

17 (A) Wie wird die LDAP-Authentifizierung für das Runtime-System im CaeManager konfiguriert? (Kapitel: 14.11.2)

18 (A) Wie wird für die lokale Authentifizierung die Komplexitäts-Überprüfung für Passwörter aktiviert? (Kapitel: 14.11.2.1)

Abbildung 161: LDAP-Client-Konfiguration (Windows)

Grundsätzlicher Ablauf für ein Active Directory Server:

Schritt: Kapitel

1 (S) Wie wird ein Active Directory-Server installiert? (Kapitel: 14.5.2)

2 (S) Wie wird ein Active Directory Server konfiguriert? (Kapitel: 14.5.5)

14-4

3 (S) Wie wird ein Apache Directory Studio (ADS) unter Linux konfiguriert? (Kapitel: 14.5.6)

4 (S) Benutzer-Verwaltung auf einem Active Directory Server (Kapitel: 14.8)

5 (S) Wie wird ein Benutzer auf einem Active Directory Server angelegt? (Kapitel: 14.8.1)

6 (S) Passwortrichtlinien / Account-Richtlinien auf einem Active Directory Server? (Kapitel: 14.12)

7 (S) Wie wird die maximale Anzahl der in der Historie gespeicherten Passwörter festgelegt? (Kapitel: 14.12.1.1)

8 (S) Wie wird das Höchstalter eines Passwortes festgelegt? (Kapitel: 14.12.1.2)

9 (S) Wie wird die minimale Länge eines Passwortes festgelegt? (Kapitel: 14.12.1.3)

10 (S) Wie wird die Komplexitäts-Überprüfung für neue Passwörter aktiviert? (Kapitel: 14.12.1.4)

11 (S) Wie wird die maximale Anzahl der Falsch-Anmeldungen konfiguriert? (Kapitel: 14.12.1.5)

12 (C) Wie wird einen APROL-Server an einen Active Directory-Server angebunden? (Kapitel: 14.9.4)

13 (C) Wie wird das PAM-Kerberos-Modul für die Anbindung an einen Active Directory-Server konfiguriert? (Kapitel: 14.9.4.2)

14 (A) Wie wird die LDAP-Authentifizierung für das Engineering-System im CaeManager konfiguriert? (Kapitel: 14.11.1)

15 (A) Wie wird die LDAP-Authentifizierung für das Runtime-System im CaeManager konfiguriert? (Kapitel: 14.11.2)

16 (A) Wie wird für die lokale Authentifizierung die Komplexitäts-Überprüfung für Passwörter aktiviert? (Kapitel: 14.11.2.1)

14-5

14.1 Aufschlüsselung der Platzhalter für die LDAP-Beispiele Die in diesem Kapitel dargestellten Beispiele enthalten nachfolgende Platzhalter und entsprechen: Platzhalter Verwendet im Beispiel <Domainname> my-domain

<Top-Level-Domainname> com

<IP-Adresse> 10.49.83.107 <Vorname> Max

<Nachname> Mueller

<Land> Germany

<Stadt> Essen

<Abteilung> Development

<Hostname> tcz400.my-domain.com

Bitte passen Sie den Basis-DN an die eigene Domäne an.

Der Domänenname Ihres Netzwerkes ist ein Vorschlag für aussagekräftige Basis-DN. Sie können aber auch beliebige andere Bezeichner wählen. Der Basis-DN wird automatisch aus dem Namen des Rechners ermittelt (Domäne). Für die Domäne 'my-domain.com' ergibt sich damit der Basis-DN in unserem Beispiel wie folgt:

dc=my-domain,dc=com

Die in den Shell-Kommandos angegebene Reihenfolge der Parameter ist zwingend einzuhalten (z. B. bei 'ldapdelete', die Reihenfolge der Parameter ou=<Abteilung>ou=<Stadt>ou=<Land>).

14.2 Verwendung der B&R Beispiel-Konfigurationen

Die unter /opt/aprol/etc/LDAP/server bzw. /opt/aprol/etc/LDAP/client ausgelieferten '*.ldif' Konfigurationen dienen ausschließlich als Beispielkonfigurationen.

'LDIF' ist die Abkürzung für LDAP Data Interchange Format.

Es ist jedoch in jedem Fall notwendig, die Konfiguration an Ihre betrieblichen und organisatorischen Belange anzupassen. Die Verwendung der exemplarischen Konfigurationen ermöglicht das direkte Aufsetzen und die Verwendung eines LDAP-Servers unter Nutzung eines einfachen inetOrgPerson-Schemas.

14-6

Bei der Ausführung eines LDAP-Befehls, z. B. ldapadd, muss darauf geachtet werden, dass der Aufruf entweder aus dem gleichen Verzeichnis heraus erfolgt, in dem sich die LDIF-Dateien befinden, oder absolute Pfade zu den LDIF-Dateien angeben werden.

'root'-Rechte sind für die Ausführung von LDAP-Befehlen nicht notwendig.

14.3 Welche Vorteile ergeben sich durch die Verwendung eines LDAP-Servers zur Authentifizierung auf einem APROL-Server?

Durch die Verwendung eines LDAP-Servers kann die Authentifizierung je nach verwendetem LDAP-Server um folgende Funktionalitäten erweitert bzw. Server-seitig konfiguriert werden: Vorwarnzeit bei abgelaufenem Passwort: Es kann optional eine Vorwarnzeit für die Funktion des 'password expires' eingestellt werden, so dass bei einem Login ein Warndialog darauf hinweist, dass das Passwort in 'n' Tagen / Minuten ablaufen wird.

Abbildung 162: Vorwarnzeit bei abgelaufenem Passwort

Password expires: Wurde dem LDAP-User eine Richtlinie mit 'password expires' zugeordnet, wird bei Ablauf des Passwortes beim nächsten Login über den LoginServer ein neues Passwort angefordert und das Login durchgeführt.

Abbildung 163: Hinweis bei Ablauf des Passwortes

Grace-Logins nach Ablauf des Passwortes: Optional kann bei Verwendung der Funktion 'password expires' eine Anzahl von sog. 'Grace-Logins' konfiguriert werden, die trotz abgelaufenem Passwort das Login nochmals mit dem alten Passwort ermöglicht.

14-7

Abbildung 164: Grace-Logins nach Ablauf des Passwortes

14.4 Wie ändert sich das Verhalten des Authentifizierungsprozesses in APROL bei Verwendung eines LDAP-Servers?

Ablauf des Authentifizierungsprozesses in APROL:

Bei manuellem Starten des LoginServers über die Kommandozeile muss unbedingt das Skript 'AprolStartLoginServer' verwendet werden. Der Aufruf des LoginServers darf nicht mit 'LoginServer' erfolgen, da dann die notwendige Laufzeitumgebung nicht bereitgestellt wird.

Bei Verwendung eines LDAP-Servers für die Authentifizierung, erfolgt zunächst die Prüfung, ob der Benutzer in der APROL-Benutzerverwaltung angelegt wurde.

Danach wird die Existenz des Benutzers auf dem LDAP-Server überprüft.

Anschließend wird das im APROL LoginServer (Security-Login Dialog) eingegebene Passwort mit dem auf dem LDAP-Server hinterlegten Passwort verglichen.

Abbildung 165: LDAP-Authentifizierung

Falls der konfigurierte LDAP-Server nicht kontaktiert werden kann oder der Benutzer nicht auf diesem Server konfiguriert wurde, wird ein Fallback der Authentifizierung unter Verwendung des in der APROL-Benutzerverwaltung hinterlegten Passwortes angeboten.

Abbildung 166: Fallback auf APROL System-Authentifizierung

14-8

Somit stellt der LDAP-Server keinen 'single point of failure' dar, d. h. es ist auch dann eine Prozessführung gewährleistet, wenn der LDAP-Server temporär nicht verfügbar ist.

Die im LDAP-Server geänderten LDAP-Passworte, die auch via LoginServer geänderten werden können, sind bei korrekter Konfiguration ohne Download auf allen Operator-Stationen verfügbar. Voraussetzung dafür ist das der LDAP-Server erreichbar ist und kein Fallback auf die APROL-Authentifizierung dadurch erfolgt.

Die Verbindung zum LDAP-Server wird vom LoginServer überwacht und der Verbindungsstatus alle 5 Minuten aktualisiert. Der Status ist im Infobereich der Kontrollleiste (Tray) ersichtlich und kann bei Bedarf auch manuell über das Kontextmenü 'Verfügbarkeit des LDAP-Servers prüfen' aktualisiert werden.

14.5 Installation und Konfiguration eines LDAP-Servers / Active Directory-Servers

.

14.5.1 Wie wird ein openLDAP-Server unter Linux mit dem YaST2 eingerichtet?

Voraussetzung für die Verwendung des openLDAP-Servers ist eine Installation des APROL R 3.6-04 und der zugehörigen AutoYaST-DVD. Folgende RPM-Pakete werden in diesem Fall automatisch installiert:

openldap2-2.4.20-0.5.1.x86_64.rpm

yast2-ldap-server-2.17.35-0.2.1.x86_64.rpm

yast2-ca-management-2.17.17-0.2.34.noarch.rpm

Der openLDAP-Server wird im Beispiel wie folgt konfiguriert:

In den Passwortablauf-Richtlinien wird ein Zeitraum für die Gültigkeit der Passwörter (password expires) vorgegeben (hier: 30 Tage). Die zulässige Verwendungshäufigkeit von abgelaufenen Passwörtern (grace logins) wird auf den Wert '3' eingestellt. Außerdem wird ein Query-Benutzer eingerichtet, der später in der Konfiguration der LDAP-Clients bei der Authentifizierung über LDAP verwendet wird.

14-9

Informationen über die Vorlagedateien in /opt/aprol/etc/LDAP/ finden Sie im Kapitel Verwendung der B&R Beispiel-Konfigurationen (Kapitel: 14.2) Informationen über die Platzhalter finden Sie im Kapitel Aufschlüsselung der Platzhalter für die LDAP-Beispiele

(Kapitel: 14.1)

Die Konfiguration des LDAP-Servers erfolgt im YaST-Kontrollzentrum. Beim ersten Start der Konfiguration des LDAP-Servers über das Icon 'LDAP-Server' werden nachfolgende Konfigurationen vorgenommen.

Abbildung 167: Konfiguration des LDAP-Servers

Navigation: YaST2 / Netzwerkdienste / LDAP-Server /Allgemeine Einstellungen

LDAP-Server starten Ja

LDAP-Server starten / Bei einem SLP-Daemon anmelden Aktiviert

Firewall-Einstellungen / Firewall-Port öffnen (entspricht den APROL Defaulteinstellungen)

Aktiviert

Firewall-Einstellungen / [Firewall Details] / Netzwerkschnittstellen Schnittstelle auswählen

Mit [Weiter] bestätigen

Durch die Anmeldung des LDAP-Servers bei einem SLP-Daemon wird die LDAP-Client-Konfiguration vereinfacht. Das Service Location Protocol (SLP) ist ein Protokoll zum Auffinden von Netzdiensten in einem TCP/IP-basierten Netz.

14-10

Grundlegende Information über SLP finden Sie unter http://de.wikipedia.org

Servertyp auswählen

Abbildung 168: Auswählen des LDAP-Servertyps

Navigation: YaST2 / Netzwerkdienste / LDAP-Server /Allgemeine Einstellungen / Servertyp auswählen

Dies ist ein eigenständige Server Aktiviert


Abbildung 169: TLS-Einstellungen

Navigation: YaST2 / Netzwerkdienste / LDAP-Server /Allgemeine Einstellungen / Servertyp auswählen / TLS-Einstellungen

Mit [Weiter] bestätigen Neue Datenbank erstellen:

14-11

Abbildung 170: Datenbank-Grundeinstellungen

Navigation: YaST2 / Netzwerkdienste / LDAP-Server /Allgemeine Einstellungen / Servertyp auswählen / TLS-Einstellungen /Neue Datenbank

Datenbanktyp hdb

Basis-DN dc=<Domainname>,dc=<Top-Level-Domainname>

Administrator-DN cn=Administrator

Basis-DN anhängen aktiviert

Passwort des LDAP-Administrators <Passwort> Verzeichnis für Datenbank /var/lib/ldap

Verwenden Sie diese Datenbank... aktiviert

Mit [Weiter] bestätigen Der 'Administrator-DN' wird zur späteren Verwaltung der LDAP-Datenbank verwendet. Das hier gesetzte Passwort kann anschließend wieder via 'YaST / Netzwerkdienste / LDAP-Server / Datenbanken / <Domain hdb-Eintrag>' geändert werden.

Der Domänenname Ihres Netzwerkes ist ein Vorschlag für aussagekräftige Basis-DN. Sie können aber auch beliebige andere Bezeichner wählen. Der Basis-DN wird automatisch aus dem Namen des Rechners ermittelt (Domäne). Für die Domäne 'my-domain.com' ergibt sich damit der Basis-DN in unserem Beispiel wie folgt:

dc=my-domain,dc=com

Der Basis-DN muss, betrachtet über alle LDAP-Server im Netzwerk (-segment), eindeutig sein.

Die Abkürzung 'hdb' steht für Hierarchical Data Base. HDB ist eine Berkeley-Datenbank mit einer hierarchischen Struktur und basiert auf 'bdb'.

Die Abkürzung' bdb' steht hierbei für Balanced Tree Data Base. Im folgenden Dialog erfolgt eine Zusammenfassung der Serverkonfiguration:

14-12

Startkonfiguration LDAP-Server starten: JA Bei SLP-Service registrieren: JA Datenbank mit den folgenden Parametern initialisieren Datenbank-Endung:dc=my-domain,dc=com Administrator-DN:cn=Administrator,dc=my-domain,dc=com

Übersichtsdialog

Navigation: YaST2 / Netzwerkdienste / LDAP-Server /Allgemeine Einstellungen / Servertyp auswählen / TLS-Einstellungen /Neue Datenbank / Bestätigungsdialog

Inhalt des Übersichtsdialogs überprüfen

Mit [Beenden] bestätigen

Test des openLDAP-Servers nach erfolgter Einrichtung: In der Kommandozeile auf dem LDAP-Server

ps aux | grep slapd Output: ldap 21677 0.0 0.3 245716 15196 ? Ssl Mar30 0:01 /usr/lib/openldap/slapd -h ldap:// ldaps:// ldapi:// -F /etc/openldap/slapd.d -u ldap -g ldap -o slp=on

Nächster Konfigurationsschritt: Kapitel Wie wird ein openLDAP-Server konfiguriert? (Kapitel: 14.5.3)

14.5.2 Wie wird ein Active Directory-Server installiert?

Die Installation eines Active Directory Servers ist entsprechend der Microsoft Installations-Hinweise durchzuführen.

Die Konfiguration für die Verwendung in APROL wird jetzt ausgeführt.

Nächster Konfigurationsschritt: Kapitel Wie wird ein Active Directory Server konfiguriert? (Kapitel: 14.5.5)

14.5.3 Wie wird ein openLDAP-Server konfiguriert? Nachdem der LDAP-Server erfolgreich eingerichtet wurde, muss die Konfiguration des LDAP-Servers über das Icon 'LDAP-Server' erneut aufgerufen werden.

14-13


(Kapitel: 14.1)

Nun erscheint eine Maske zur Konfiguration weiterer Optionen des LDAP-Servers.

Abbildung 171: Startkonfiguration

Navigation: YaST2 / Netzwerkdienste / LDAP-Server / Startkonfiguration

LDAP-Server starten Ja

LDAP Aktiviert

LDAP über SSL (ldaps) Deaktiviert

LDAP über IPC Aktiviert

Firewall-Port öffnen Aktiviert

Eintrag 'Schema-Dateien' in der Navigation auswählen Hier wird zunächst nur die Konfiguration ohne 'SSL' beschrieben.

Weitere Informationen zur Verwendung von SSL finden Sie im Erweiterte Sicherheit durch Verwendung von SSL / TLS

(Kapitel: 14.10)

14-14

.

Die Option 'LDAP über IPC' (unter 'Protocol Listener') darf nicht ausgeschaltet werden, da ansonsten eine weitere Konfiguration über den YaST nicht mehr möglich ist. Sollte die Option ausgeschaltet worden sein, so kann ein manuelles Einschalten über die folgende Konfigurationsdatei erfolgen: /etc/sysconfig/openldap Hier ist der folgende Eintrag vorzunehmen: OPENLDAP_START_LDAPI=yes

Alle weiteren Grundeinstellungen müssen nicht angepasst werden.

Die Einstellung 'Protocol Listener / LDAP' verwendet Port 389. Die Einstellung 'Protocol Listener / LDAP über SSL' verwendet Port 636.

Zur Verwaltung von Benutzern in Verzeichnisdienst-Servern werden für die Datenhaltung bzw. für die Festlegung der verfügbaren Datenfelder sog. Schema-Dateien verwendet. Ein LDAP-Schema beschreibt die Liste möglicher Typen von Einträgen (Objektklassen) zusammen mit hiermit verknüpften Attributen. Eine Objektklasse kann Pflichtattribute und optionale Attribute besitzen. Beispielkonfiguration: schema core cosine dnszone inetorgperson rfc2307bis ppolicy

Schema hinzufügen.

Abbildung 172: Schema-Datei auswählen und hinzufügen

Navigation: YaST2 / Netzwerkdienste / LDAP-Server / Schema-Dateien

[Hinzufügen] Datei ppolicy.schema auswählen

14-15

Eintrag 'Datenbanken / dc=<Top-Level-Domainname>,dc=<Top-Level-Domainname>' in der Navigation auswählen

Grundsätzlich kann die Vorgabe zu den Schemata übernommen werden. Es können jedoch auch eigene Schema-Dateien hinzugefügt werden. Datenbanken Hier findet sich die eingangs eingerichtete Default-Datenbank dc=my-domain,dc=com wieder. Passwortrichtlinien-Konfiguration:

Abbildung 173: Passwortrichtlinien-Konfiguration

Navigation: YaST2 / Netzwerkdienste / LDAP-Server / Datenbanken / dc=<Top-Level-Domainname>,dc=<Top-Level-Domainname>

Passwortrichtlinien aktivieren aktiviert

Weiter mit [Richtlinie bearbeiten] Wie wird die Default-Passwortrichtlinie angepasst? (Kapitel: 14.5.3.1)

Bei dieser Passwortrichtlinie handelt es sich um die Defaultrichtlinie, die angewendet wird, wenn dem Benutzer nicht explizit (über das Attribut 'pwdPolicySubentry') eine andere Richtlinie zugewiesen wurde.

14.5.3.1 Wie wird die Default-Passwortrichtlinie angepasst? Über [Richtlinien bearbeiten] und nach Eingabe des Administrator-Passworts können Richtlinien wie z. B. Passwortablauf-Richtlinien (password expires) und Passwortänderungs-Richtlinien eingestellt werden.

Dieses Kapitel behandelt das Einrichten der Default-Passwortrichtlinien. Eine detaillierte Erklärung entnehmen Sie bitte dem Kapitel Wie wird eine Passwortrichtlinie auf einem openLDAP-Server manuell angelegt?

(Kapitel: 14.7.3)

14-16


(Kapitel: 14.1)

Passwortänderungs-Richtlinien:

Abbildung 174: Passwortänderungsrichtlinien

Navigation: YaST2 / Netzwerkdienste / LDAP-Server / Datenbanken / dc=<Top-Level-Domainname>,dc=<Top-Level-Domainname> / [Richtlinie bearbeiten] / Passwortänderungsrichtlinien

Nur überprüfte Passwörter akzeptieren aktiviert

Mindestlänge des Passworts 8

Weiter mit Reiter Passwortablaufrichtlinien

Das angeforderte Passwort ist das Passwort des LDAP-Administrators 'Administrator'.

Passwortablaufrichtlinien:

Abbildung 175: Passwortablaufrichtlinien

14-17

Navigation: YaST2 / Netzwerkdienste / LDAP-Server / Datenbanken / dc=<Top-Level-Domainname>,dc=<Top-Level-Domainname> / [Richtlinie bearbeiten] / Passwortablaufrichtlinien

Höchstalter des Passworts 30

Zeitpunkt für Warnung vor Passwortablauf 2

Zulässige Verwendungshäufigkeit von abgelaufenen Passwörtern (grace logins)

3

Weiter mit Reiter Sperrrichtlinien Sperrrichtlinien:

Abbildung 176: Sperrrichtlinien

Navigation: YaST2 / Netzwerkdienste / LDAP-Server / Datenbanken / dc=<Top-Level-Domainname>,dc=<Top-Level-Domainname> / [Richtlinie bearbeiten] / Sperrrichtlinien

Anzahl der Bind-Fehler vor Passwortsperrung 3

Zurück zur vorherige Dialog mit [OK] Navigation: YaST2 / Netzwerkdienste / LDAP-Server / Datenbanken / dc=<Domainname>,dc=<Top-Level-Domainname>

Konfiguration mit [OK] abschließen

Nächster Konfigurationsschritt: Kapitel Wie wird eine minimale Datenbank-Struktur eingerichtet? (Kapitel: 14.5.3.2)

14.5.3.2 Wie wird eine minimale Datenbank-Struktur eingerichtet? Zur Verwaltung der LDAP-Benutzer in der LDAP-Datenbank wird eine Datenbankstruktur benötigt. Beispielhaft wird hier eine minimale Struktur importiert.


(Kapitel: 14.1)

Hinzufügen einer Struktur:

14-18

In der Kommandozeile vi struktur.ldif Manuell anpassen

dn: cn=Administrator,dc=<Domainname>,dc=<Top-Level-Domainname> objectClass: organizationalRole

cn: Administrator

dn: CN=Users,DC=<Domainname>,DC=<Top-Level-Domainname> objectClass: top

objectClass: inetOrgPerson

cn: Users

sn: Users

dn: ou=<Land>,dc=<Domainname>,dc=<Top-Level-Domainname> objectClass: organizationalUnit

ou: <Land>

dn: ou=<Stadt>,ou=<Land>,dc=<Domainname>,dc=<Top-Level-Domainname> objectClass: organizationalUnit

ou: <Stadt>

dn: ou=<Abteilung>,ou=<Stadt>,ou=<Land> ,dc=<Domainname>,dc=<Top-Level-Domainname> objectClass: organizationalUnit

ou: <Abteilung>

In der Kommandozeile Allgemeine Syntax: ldapadd -h <IP-Adresse> -x -W -D cn=Administrator,dc=<Domainname>,dc=<Top-Level-Domainname> -f struktur.ldif

Beispiel: ldapadd -h 10.49.83.107 -x -W -D cn=Administrator,dc=my-domain,dc=com -f struktur.ldif

Konfiguration abgeschlossen

Nächster Konfigurationsschritt: Kapitel Wie wird ein LDAP-Query-Benutzer für den openLDAP Server eingerichtet? (Kapitel: 14.5.3.3)

14-19

1) Das angeforderte Passwort ist das Passwort des LDAP-Administrators 'Administrator'. 2) Die hierarchische Baumstruktur wird als Directory Information Tree (DIT) bezeichnet, der den gesamten, von einem Server vorgehaltenen Namensraum abbildet. Mit dem Directory Information Tree wird im Allgemeinen die Hierarchie der Organisation / Firma in der Datenbank des openLDAP-Servers abgebildet.

14.5.3.3 Wie wird ein LDAP-Query-Benutzer für den openLDAP Server eingerichtet?

Der openLDAP-Server lässt (per Default) keinen anonymen Zugriff für Abfragen zu. Daher wird von den LDAP-Clients ein LDAP-Query-Benutzer benötigt, um Anfragen an den LDAP-Server zu richten. Der LDAP-Query-Benutzer benötigt eine eigene Passwortrichtlinie, um zu verhindern, dass das Passwort des LDAP-Query-Benutzers ungültig wird (password expires). Würde der LDAP-Query-Benutzer die Default-Passwortrichtlinie verwenden, müsste sein Passwort ggf. regelmäßig geändert werden, was auch eine Anpassung aller LDAP-Clients nach sich ziehen würde.


(Kapitel: 14.1)

An dieser Stelle sollten die Parameter entsprechend den eigenen Bedürfnissen angepasst werden.

In der Kommandozeile Allgemeine Syntax: ldapadd -h <IP-Adresse> -x -W -D cn=Administrator,dc=<Domainname>,dc=<Top-Level-Domainname> -f ldap_query_user_ppolicy.ldif

Beispiel: ldapadd -h 10.49.83.107 -x -W -D cn=Administrator,dc=my-domain,dc=com -f ldap_query_user_ppolicy.ldif

Nächster Konfigurationsschritt: LDAP-Query-Benutzer hinzufügen

Daraufhin wird der LDAP-Query-Benutzer hinzugefügt, der später für die Konfiguration der Client-Authentifikation mit APROL benötigt wird.

LDAP-Query-Benutzer hinzufügen.

14-20

In der Kommandozeile

Allgemeine Syntax: ldapadd -h <IP-Adresse> -x -W -D cn=Administrator,dc=<Domainname>,dc=<Top-Level-Domainname> -f ldap_query_user.ldif

Beispiel: ldapadd -h 10.49.83.107 -x -W -D cn=Administrator,dc=my-domain,dc=com -f ldap_query_user.ldif

Nächster Konfigurationsschritt: Dem LDAP-Benutzer 'LDAP Query' ein neues Passwort zuwiesen

Zuweisen einer Passwortrichtlinie: Um einem Benutzer eine andere als die Default-Passwortrichtlinie zuzuweisen, wird das Attribut pwdPolicySubentry verwendet. Als Wert wird der komplette Pfad zu der zu verwendenden Passwortrichtlinie eingetragen. Die verwendete Passwortrichtlinie heißt in diesem Fall LDAP-Query User Policy und wird nur dem LDAP-Query-Benutzer zugewiesen. Die LDIF-Datei ldap_query_user.ldif enthält aus diesem Grund den folgenden Eintrag: pwdPolicySubentry: cn=LDAP-Query User Policy,dc=my-domain,dc=com

Dem LDAP-Benutzer 'LDAP Query' ein neues Passwort zuwiesen: In der Kommandozeile

Allgemeine Syntax: ldappasswd -h <IP-Adresse> -x -W -S -D cn=Administrator,dc=<Domainname>,dc=<Top-Level-Domainname> "cn=LDAP Query,cn=Users,dc=<Domainname>,dc=<Top-Level-Domainname>"

Beispiel: ldappasswd -h 10.49.83.107 -x -W -S -D cn=Administrator,dc=my-domain,dc=com "cn=LDAP Query,cn=Users,dc=my-domain,dc=com"

Konfiguration abgeschlossen Zunächst wird das zu setzende (neue) Passwort des Benutzers 'LDAP Query' zweimalig abgefragt, anschließend das LDAP-Passwort des Benutzers 'Administrator'.

Nächster Konfigurationsschritt: Kapitel Wie wird ein Apache Directory Studio (ADS) unter Linux konfiguriert? (Kapitel: 14.5.6)

14-21

14.5.4 Wie wird die Verbindung zu einem LDAP-Server getestet? Mit folgendem Befehl kann getestet werden, ob der Zugriff auf den LDAP-Server möglich ist.


(Kapitel: 14.1)

In der Kommandozeile Allgemeine Syntax: ldapsearch -h <IP-Adresse> -p <Port> -s sub -D "cn=Administrator,dc=<Domainname>,dc=<Top-Level-Domainname>" -b "DC=<Domainname>,DC=<Top-Level-Domainname>" "cn=Administrator" -W

Beispiel: ldapsearch -h 10.49.83.107 -p 389 -s sub -D "cn=Administrator,dc=my-domain,dc=com" -b "DC=my-domain,DC=com" "cn=Administrator" -W


Das bei der Verwendung der ldap*-Befehle abgefragte LDAP-Passwort ist das Passwort des eingerichteten LDAP-Administrators.

Bei einem erfolgreichen Zugriff auf den LDAP-Server erfolgt folgende Ausgabe im Beispiel: # extended LDIF # # LDAPv3 # base <DC=my-domain,DC=com> with scope subtree # filter: cn=Administrator # requesting: ALL # # Administrator, my-domain.com dn: cn=Administrator,dc=my-domain,dc=com objectClass: organizationalRole cn: Administrator # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1

14.5.5 Wie wird ein Active Directory Server konfiguriert? Kerberos ist ein verteilter Authentifizierungsdienst (Netzwerkprotokoll) für offene und unsichere Computernetze (zum Beispiel das Internet). Microsoft verwendet Kerberos als Standardprotokoll

14-22

für die Authentifizierung unter Windows 2000/2003 basierten Netzwerken sowie für den Windows 2000/XP-Client. Unter Linux wird dagegen das entsprechende PAM-Modul installiert (pam_krb5).

Grundlegende Information über Kerberos finden Sie unter http://de.wikipedia.org

Bei einem bestehenden Active Directory Server müssen nachfolgende Punkte sichergestellt werden: Vorname, Nachname und Login-Name der Benutzer und Operatoren.

1) Der Distinguished Name (DN) eines Benutzers muss eindeutig sein. Da die Benutzer-Namen im Active Directory Server in Verzeichnissen verwaltet werden, muss daher das Wertepaar (Vorname, Nachname) eindeutig sein. 2) Die Tupel Vorname, Nachname, sowie Login-Name müssen den Einträgen in der APROL Benutzerverwaltung bzw. im OperatorManager entsprechen.

3) Der Login-Name (uid) im Active Directory Server darf nur einmal vorkommen. Hier findet keine Plausibilitätsprüfung durch den LDAP-Server statt!

Login-Name (uid) Eine doppelte 'uid' könnte z. B. entstehen, wenn eine Namensänderung (z. B. Heirat) stattfindet. Somit ist es möglich, einen LDAP-Benutzer mit neuen Name zu duplizieren aber die Eindeutigkeit der uid zu verlieren.

Dies kann im APROL-System nicht passieren da eine Prüfung stattfindet.

Die Richtlinien der Benutzer und Operatoren stimmen mit denen von APROL überein (bezüglich die Fallback-Mechanismus).

Eine Änderung des Passwortes im OperatorManager wird nur bei Download auf die Operator-Stationen wirksam werden.

Bei gestörter LDAP-Verbindung wird als Fallback mit lokaler APROL-Authentifizierung das Einloggen immer noch gewährleistet.

Kerberos Zeitsynchronisation.

Bei der Verwendung von Kerberos ist zwingend eine Zeitsynchronisation auf allen betroffenen Rechnern zu konfigurieren!

Auf dem APROL-Server kann die NTP-Zeitsynchronisation via AprolConfig parametriert werden.

Nächster Konfigurationsschritt: Kapitel Wie wird ein Apache Directory Studio (ADS) unter Linux konfiguriert? (Kapitel: 14.5.6)

14-23

14.5.6 Wie wird ein Apache Directory Studio (ADS) unter Linux konfiguriert?

Das 'Apache Directory Studio' (ADS) ist unter dem APROL-KDE-Menü 'Werkzeuge' erreichbar und ermöglicht eine umfangreiche Analyse und Konfiguration des openLDAPv3- oder Active Directory-Servers. Dieses Werkzeug ist auch für den Import / Export von LDIF-Dateien geeignet, so dass die Verwendung der Konsolen-Kommandos zur Anlage neuer Benutzer im LDAP-Server obsolet ist.

Im Passwort-Editor des Apache Directory Studio kann ein Passwort eines Benutzers, der mit dem APROL OperatorManager bzw. der Benutzerverwaltung exportiert wurde, nicht über die Schaltfläche [Verifizieren] direkt geprüft werden. Stattdessen kann das Passwort über die Schaltfläche [Bind] direkt mit dem verbundenen LDAP-Server getestet werden.

Alternativ zur Verwendung des ADS stehen die nicht so komfortablen Möglichkeiten der Konfiguration via YaST2 oder via manuelle Einstellungen zur Verfügung. Um das ADS verwenden zu können, muss zunächst eine Verbindung zum LDAP-Server hergestellt/erstellt werden.

Abbildung 177: Konfiguration der Verbindung zum LDAP-Server (Schritt 1/3)

Navigation: ADS / Ansicht 'Verbindungen' / Kontextmenü 'Neue Verbindung' (Schritt 1/3)

Verbindungsname <beliebige Bezeichnung>

Hostname <Hostname>

Port 389

Verschlüsselungs-Methode Keine Verschlüsselung

Mit [Netzwerkparameter überprüfen] die Konfiguration und Erreichbarkeit des LDAP-Servers testen.


14-24

Um eine gesicherte Verbindung über SSL herzustellen, müssen der Port und die Verschlüsselungs-Methode angepasst werden (vorausgesetzt der LDAP Server ist für SSL Verbindungen konfiguriert).

Port 636

Verschlüsselungs-Methode SSL Verschlüsselung (ldaps://)



Authentifizierungs-Methode Einfache Authentifizierung

Bind DN oder Benutzer cn=Administrator,dc=my-domain,dc=com

Bind Passwort <Passwort>

Passwort speichern deaktiviert

Mit [Authentifizierung überprüfen] die Konfiguration testen. Dies kann nur durchgeführt werden, wenn die Checkbox 'Passwort speichern' kurzzeitig aktiviert ist.


Der angegebene 'Bind DN' bzw. Benutzer muss der Administrator sein!

Um Zugriffe nicht autorisierter Mitarbeiter auf das LDAP-Verzeichnis zu verhindern, wird empfohlen das Passwort nicht zu speichern!

14-25

Hinweis zum 'Herstellen einer Verbindung über SSL': Wurde das Zertifikat selbst erstellt und nicht von einer Zertifizierungsstelle beglaubigt, dann wird beim Überprüfen der Authentifizierung eine Warnung ausgegeben. Ist das Zertifikat vertrauenswürdig, kann 'Diesem Zertifikat immer vertrauen' ausgewählt werden und anschließend mit [OK] bestätigt werden. Diese Warnung erscheint nur bei ungültigen Zertifikaten, denen noch nicht vertraut wurde.



Basis-DNs mittels Root DSE bestimmen aktiviert

Max. Anzahl 1000

Max. Suchzeit (s) 0

Finden des Basis-DN aktiviert

Suchen aktiviert

Verweisbehandlung Verweisen manuell folgen

'ManageDsaIT Control' während des Browsens verwenden

deaktiviert

Sub-Einträge während des Browsens abrufen deaktiviert

Seitenweise Suche deaktiviert

Operationale Attribute während des Browsens abrufen

aktiviert

Mit [Fertig stellen] bestätigen

Wird das Feld 'Operationale Attribute während des Browsens abrufen' aktiviert, so werden bei den Objekteigenschaften zusätzliche Informationen angezeigt. Z. B. wird in der Ansicht eines Benutzers das Attribut 'pwdPolicySubentry' zusätzlich angezeigt, das den Namen der zugewiesenen LDAP-Passwortrichtlinie enthält.

14-26

Nächster Konfigurationsschritt für openLDAP-Server: Kapitel Benutzer-Verwaltung openLDAP (Kapitel: 14.7)

Nächster Konfigurationsschritt für Active Directory Server: Kapitel Benutzer-Verwaltung auf einem Active Directory Server (Kapitel: 14.8)

14.6 Übertragung der APROL Benutzerdaten in den LDAP-Server

In früheren APROL Releases mussten Daten von Benutzern und Operatoren interaktiv als LDIF-Dateien aus der APROL Benutzerverwaltung bzw. dem OperatorManager exportiert werden. Anschließend erfolgte wiederum ein interaktiver Import der LDIF-Dateien in den LDAP-Server, z.B. über das ApacheDirectoyStudio (ADS).

APROL R4.0 vereinfacht die Übertragung der Benutzer- und Operatordaten in einen dafür konfigurierten LDAP-Server. Die Aufgabe des Datenimports in den LDAP-Server übernimmt der 'AprolJobDispatcher'.

Ein interaktiver Export als LDIF Datei ist weiterhin möglich! Vergleichen Sie hierzu die Kapitel Wie wird ein APROL-System für den LDIF-Export vorkonfiguriert? sowie Wie wird eine LDIF-Datei in den openLDAP-Server mit Apache Directory Studio importiert?

14.6.1 Einrichtung des AprolJobDispatchers für die Übertragung der Benutzerdaten in den LDAP-Server

Für den automatischen Import der APROL Benutzerdaten in den LDAP-Server empfehlen wir, diesen auf Ihrem APROL Protokollserver einzurichten. Die Beschreibung zur Konfiguration des LDAP-Servers finden Sie im Kapitel Wie wird ein openLDAP-Server konfiguriert?

Auf jedem APROL-Server befindet sich jeweils ein 'AprolJobDispatcher'. Der auf dem Protokollserver befindliche 'AprolJobDispatcher' benötigt keine weitere Konfiguration. Der Konfigurationsaspekt'Job-Dispatcher' (im AprolConfig) muss jedoch auf jedem beteiligten APROL-Server aktiviert werden. Der 'AprolJobDispatcher' stellt sein Jobverzeichnis und die darin vorhandenen Jobs zur Verfügung. Jeder 'AprolJobDispatcher' schaut dort regelmäßig nach neuen Jobs. Der 'AprolJobDispatcher'auf dem Engineering-System benötigt den Hostnamen des Protokollservers. Starten Sie dazu AprolConfig und wählen Sie den Konfigurationsaspekt 'Job-Dispatcher'. Geben Sie im Feld 'Hostname' den qualifizierten Hostnamen (FQDN) des Protokollservers ein. Das Feld 'Server path' sollte nicht geändert werden. Das folgende Schaubild zeigt die empfohlene Konfiguration:

14-27

Abbildung 180: Schematische Übersicht zum JobDispatcher mit LDAP-Konfiguration

14.6.2 Übertragen der LDAP-Daten aus der Benutzerverwaltung und dem OperatorManager

Stellen Sie zunächst sicher, dass Sie mit dem CC-Account eines Engineering Benutzers angemeldet sind und zusätzlich in APROL Rechte zum Bearbeiten von Benutzern und Operatoren haben. Starten Sie die Benutzerverwaltung (Aufruf z.B. im CaeManager über das Menü 'Extras/Benutzerverwaltung'). Sie haben die Möglichkeit, einen oder mehrere Benutzer an den LDAP-Server zu übertragen. Wählen Sie dazu im Kontextmenü des bzw. der selektierten Benutzer(s) den Eintrag 'Übertrage zum LDAP-Server'. Daraufhin werden die Benutzerdaten im LDIF Format exportiert und ein Auftrag (Job) für den 'AprolJobDispatcher' generiert. Der Job wird als Datei im Jobverzeichnis abgelegt. Der 'AprolJobDispatcher' auf dem Rechner, auf dem der LDAP-Server läuft (Protokollserver), verarbeitet die Jobdatei und leitet den Job an den LDAP-Server weiter. Dieser importiert schließlich die Benutzerdaten. Analog dazu ist es möglich, die Operatordaten eines Projektes über den Operatormanager (Aufruf z.B. im CaeManager Hauptmenü 'Extras/OperatorManager') zu übertragen. Wählen Sie dazu im Kontextmenü einer Operatorgruppe oder eines Operators den Menüpunkt 'Übertrage zum LDAP-Server'. Der Vorgang wird in einem ChronoLog Report aufgezeichnet. Dadurch können Sie beispielsweise eine Fehlkonfiguration in den Benutzerdaten erkennen. Der Report kann über den Button [Zeigen] nach der Übertragung angezeigt werden. Beim ersten Aufruf muss der verantwortliche Protokollserver angegeben werden.

14-28

Der OperatorManager kann im Runtime-System über das KDE-Menü oder über das zugehörige Desktop-Icon aufgerufen werden.

14-29

14.6.3 Funktionsweise des AprolJobDispatcher Mechanismus

Im Release APROL R4.0 wurde die neue Komponente 'AprolJobDispatcher' eingeführt. Dieser übernimmt die Aufgabe des automatischen LDIF-Dateiimports zum LDAP-Server. Allgemein ist der 'AprolJobDispatcher' in der Lage, Aufträge (Jobs) anzunehmen und entsprechend des Typs an eine ausführende Instanz zuzuweisen. Der 'AprolJobDispatcher' benötigt die Teilnehmer 'Auftraggeber' und 'Auftragnehmer'. Die Aufträge selbst werden in einem spezifizierten Dateiformat dem konfigurierten Jobverzeichnis übergeben.

Aus Sicherheitsgründen ist für die Jobübergabe ein NFS-Verzeichnis mit entsprechenden Zugriffsrechten für Auftraggeber und Auftragnehmer erforderlich. Das NFS-Verzeichnis wird mit AprolConfig auf dem Rechner erzeugt, der dort als Server angegeben ist.

Der 'AprolJobDispatcher' prüft in zyklischen Zeitabständen das Jobverzeichnis auf neue Aufträge. Diese werden nacheinander betrachtet, auf Gültigkeit geprüft und dem jeweiligen Auftragnehmer zugewiesen. Das folgende Schaubild veranschaulicht den Zusammenhang der Komponenten 'Auftraggeber', 'Auftragnehmer', 'JobDispatcher' und 'Jobverzeichnis':

Abbildung 181: Schematische Darstellung zur Funktionsweise des AprolJobDispatcher

14-30

14.6.4 Sicherheit Ein Job ist eine Datei, die innerhalb des Netzwerkes auf der Leitebene übertragen und ausgeführt wird. Deshalb ist die Absicherung gegen ungewolltes Einschleusen und die Manipulation von Jobs notwendig. Die ungewollte Manipulation eines Jobs (Code-Injektion) wird durch eine zuverlässige Integritätsprüfung verhindert. Dazu wird jeder Job gegen eindeutige Prüfsummen geprüft. Jeder Job wird mit APROL-internen SSL-Zertifikaten signiert und kann somit nicht mit anderen Werkzeugen erzeugt und auch nicht ohne registrierten Zielprozess ausgeführt werden. Es ist also nicht möglich, einen Prozess als Job zu tarnen und direkt auszuführen (Trojaner). Weiter wird durch den NFS-Mechanismus verhindert, dass andere Prozesse außer dem JobDispatcher selbst in das Verzeichnis schreiben können. Zusätzlich sorgt die Reportgenerierung (Protokollierung) für einen hohen Grad an Transparenz. Die Einzelaktivitäten ausgeführter Jobs sind dadurch leichter erkennbar und nachvollziehbar.

14.7 Benutzer-Verwaltung openLDAP Das vorliegende Kapitel beschreibt die Benutzer-Verwaltung auf Basis der Kommandozeile und alternativ mit dem YaST.

1) Der Distinguished Name (DN) eines Benutzers muss eindeutig sein. Da die Benutzer-Namen im openLDAP Server in Verzeichnissen verwaltet werden, muss daher das Wertepaar (Vorname, Nachname) eindeutig sein. 2) Die Tupel Vorname, Nachname, sowie Login-Name müssen den Einträgen in der APROL Benutzerverwaltung bzw. im OperatorManager entsprechen.

3) Der Login-Name (uid) im openLDAP-Server darf nur einmal vorkommen. Hier findet keine Plausibilitätsprüfung durch den open LDAP-Server statt!



Nächster Konfigurationsschritt (Empfohlen): Kapitel Wie werden weitere Passwortrichtlinien auf einem openLDAP-Server mit dem Apache Directory Studio angelegt? (Kapitel: 14.7.1)

Nächster Konfigurationsschritt (Alternativ): Kapitel Wie werden weitere Passwortrichtlinien auf einem openLDAP-Server mit dem YaST angelegt? (Kapitel: 14.7.2)

14-31

Nächster Konfigurationsschritt (Alternativ): Kapitel Wie wird eine Passwortrichtlinie auf einem openLDAP-Server manuell angelegt? (Kapitel: 14.7.3)

14.7.1 Wie werden weitere Passwortrichtlinien auf einem openLDAP-Server mit dem Apache Directory Studio angelegt?

Das 'Apache Directory Studio' ist unter dem APROL-KDE-Menü 'Werkzeuge' erreichbar. An dieser Stelle bestehen grundsätzlich 2 Möglichkeiten: Sie können entweder die Default Policy kopieren und modifizieren (empfohlen) oder einen Export / Import der Default Policy als LDIF-Datei (alternativ) durchführen. Methode 1: Kopieren der Default Policy (empfohlen)

Abbildung 182: Bestehende Default Policy kopieren

Navigation: KDE Werkzeuge / ADS / LDAP Browser 'Default Policy' / Kontextmenü 'DN kopieren'

14-32

Abbildung 183: Kopie der Default Policy einfügen

Wählen Sie den Eintrag des Basis-DN aus. Navigation: ADS / LDAP Browser 'Basis-DN' / Kontextmenü 'Eintrag einfügen'

Abbildung 184: Auflösen desNamenskonflikts beim Einfügen

Navigation: ADS / LDAP Browser 'Basis-DN' (Stelle für das Einfügen ) / Kontextmenü 'Eintrag einfügen' / Kopierstrategie

Eintrag umbennenen und fortfahren aktiviert

RDN Attribut cn

RDN-Name <New Policy Name>

Weiter mit [OK] Im Feld 'RDN' das Attribut 'cn' auswählen (Default) und den neuen Namen der Policy eintragen. Navigation: ADS / LDAP Browser '<New Policy Name>' / Reiter 'cn=<New Policy Name>...'

Änderung / Anpassung der Attribute

14-33

Eine Beschreibung der Attribute finden unter dem Kontextmenü der jeweiligen Attribute unter 'Öffne Schema Browser / Attribut-Type Beschreibung'.

Abbildung 185: Informationen zu den Attributen in der ADS-Hilfe

Detallierte Beschreibungen zu den Optionen finden Sie im Kapitel Wie wird eine Passwortrichtlinie auf einem openLDAP-Server manuell angelegt?

Konfigurationsschritt abgeschlossen

Nächster Konfigurationsschritt: Kapitel Wie wird ein Benutzer auf dem openLDAP-Server angelegt? (Kapitel: 14.7.4)

14-34

Methode 2: Export / Import der Default Policy als LDIF-Datei (alternativ)

Abbildung 186: Exportieren der Passwort Richtlinien als LDIF-Datei

14-35

Abbildung 187: Einstellungen zum LDIF-Export

Navigation: ADS / LDAP Browser 'Default Policy' / Kontextmenü 'Exportieren, LDIF exportieren' / LDIF Export

Verbindung <Verbindungsname>

Suchbasis cn=Default Policy,dc=<Domainname>,dc=<Top-Level-Domainname>

Filter (objectClass=*)

Abgerufene Attribute <leer>

Alle Benutzer Attribute aktiviert

Operationale Attribute deaktiviert

Steuerung deaktiviert

ManageDsaIT deaktiviert

Sub-Einträge deaktiviert

Seitenweise Suche deaktiviert

Scope: Subtree ausgewählt

Limits / Max. Anzahl 1000

14-36

Limits / Max. Suchzeit (s) 0

Alias Dereferenzierung Finden des Basis-DN

Suchen aktiviert

Verweisbehandlung: Verweisen automatisch folgen

ausgewählt

Weiter mit [Weiter]

Abbildung 188: Einstellungen zum LDIF-Export

Navigation: ADS / LDAP Browser 'Default Policy' / Kontextmenü 'Exportieren, LDIF exportieren' / LDIF Export

Ziel-Datei auswählen /home/<CC-Account>/ENGIN/EXCHANGE/<New Policy Name>.ldif

Weiter mit [Fertig stellen] Bearbeiten / Apassen der LDIF Datei In der Kommandozeile

vi /home/<CC-Account>/ENGIN/EXCHANGE/<Neue Policy Name>.ldif manuell anpassen

dn: cn=<New Policy Name>,dc=<Domainname>,dc=<Top-Level-Domainname> cn: <New Policy Name>

objectClass: pwdPolicy

objectClass: namedObject

pwdAttribute: userPassword

14-37

pwdCheckQuality: 2

pwdExpireWarning: 129600

pwdFailureCountInterval: 300

pwdGraceAuthNLimit: 3

pwdInHistory: 5

pwdLockout: TRUE

pwdLockoutDuration: 120

pwdMaxAge: 172800

pwdMaxFailure: 1

pwdMinAge: 86400

pwdMinLength: 8

pwdMustChange: TRUE

pwdSafeModify: TRUE

Konfigurationsschritt abgeschlossen

Detallierte Beschreibungen zu den Optionen finden Sie im Kapitel

Wie wird eine Passwortrichtlinie auf einem openLDAP-Server manuell angelegt?

Nächster Konfigurationsschritt (danach hier weiter): Kapitel Wie wird eine LDIF-Datei in den openLDAP-Server mit Apache Directory Studio importiert? (Kapitel: 14.7.5.3)


14.7.2 Wie werden weitere Passwortrichtlinien auf einem openLDAP-Server mit dem YaST angelegt?

Alternativ zur manuellen Methode kann eine neue Passwortrichtlinie auch mit YaST angelegt werden. Die Default-Passwortrichtlinie wird immer dann verwendet, wenn dem Benutzer keine andere Passwortrichtlinie zugewiesen wurde. Aus Sicherheitsgründen kann eine Mindest-Passwortlänge von 6 Zeichen (via PAM-LDAP Modul begrenzt) bei der Vergabe eines neuen LDAP-Passworts nicht unterschritten werden. Diese Begrenzung hat Vorrang vor allen am LDAP-Server konfigurierbaren Passwort-Richtlinien.

14-38


(Kapitel: 14.1)

Abbildung 189: Konfiguration LDAP-Clients

Das erstellen einer zusätzlichen Passwortrichtlinie ist nicht zwingend notwendig.

Navigation:

YaST2 / Netzwerkdienste / LDAP-Client

Weiter mit [Erweiterte Konfiguration]

Abbildung 190: Erweiterte Konfiguration

Navigation: YaST2 / Netzwerkdienste / LDAP-Client / [Erweiterte Konfiguration] / Verwaltungseinstellungen

Weiter mit [Hinzufügen]

14-39

Abbildung 191: Name des Passwortrichtlinienobjekts

Navigation: YaST2 / Netzwerkdienste / LDAP-Client / [Erweiterte Konfiguration] / Verwaltungseinstellungen / Hinzufügen

Name des Passwortrichtlinienobjekts <Name> Weiter mit [OK]

Abbildung 192: Passwortrichtlinienkonfiguration

Navigation: YaST2 / Netzwerkdienste / LDAP-Client / [Erweiterte Konfiguration] / Verwaltungseinstellungen / Hinzufügen

Entweder Default-Einstellungen belassen oder gewünschte Richtlinien einstellen

Detallierte Beschreibungen zu den Optionen finden Sie im Kapitel

Wie wird eine Passwortrichtlinie auf einem openLDAP-Server manuell angelegt?

Weiter mit [OK]


14-40

14.7.3 Wie wird eine Passwortrichtlinie auf einem openLDAP-Server manuell angelegt?

Eine Passwortrichtlinie erlaubt es dem openLDAP-Administrator Regelwerke für das Passwort eines Benutzers zu definieren. Diese Passwortrichtlinie kann ausgewählten Benutzern zugewiesen werden. Die Default-Passwortrichtlinie wird immer dann verwendet, wenn dem Benutzer keine andere Passwortrichtlinie zugewiesen wurde. Diese Regelwerke enthalten unter anderem die folgenden Angaben:

maximales Passwortalter,

minimales Passwortalter,

minimale Passwortlänge,

maximale Anzahl von fehlschlagenden Anmeldungsversuchen mit anschließender Blockierung des Benutzers,

Angaben zur geforderten Komplexität eines neuen Passworts,

Das Schema ppolicy muss in den openLDAP-Server geladen worden sein. Detaillierte Information erhalten Sie im Kapitel Wie wird ein openLDAP-Server konfiguriert?

(Kapitel: 14.5.3)

Passwortrichtlinien werden durch Kopieren und Anpassen der Vorlagendatei im LDIF-Format vorbereitet und anschließend in den LDAP-Server importiert. Die Platzhalter müssen hierbei mit konkreten Werten versehen werden.


(Kapitel: 14.1)

Manuelles Anlegen einer Passwortrichtlinie: Das erstellen einer zusätzlichen Passwortrichtlinie ist nicht zwingend notwendig. In der Kommandozeile

cp default_user_ppolicy.ldif new_user_policy.ldif

vi new_user_policy.ldif manuell anpassen

14-41

dn: cn=<New Policy Name>,dc=<Domainname>,dc=<Top-Level-Domainname> cn: <New Policy Name>

objectClass: pwdPolicy

objectClass: namedObject

pwdAttribute: userPassword

pwdCheckQuality: 2

pwdExpireWarning: 129600

pwdFailureCountInterval: 300

pwdGraceAuthNLimit: 3

pwdInHistory: 5

pwdLockout: TRUE

pwdLockoutDuration: 120

pwdMaxAge: 172800

pwdMaxFailure: 1

pwdMinAge: 86400

pwdMinLength: 8

pwdMustChange: TRUE

pwdSafeModify: TRUE


Allgemeine Syntax: ldapadd -h <IP-Adresse> -x -W -D cn=Administrator,dc=<Domainname>,dc=<Top-Level-Domainname> -f new_user_policy.ldif

Beispiel: ldapadd -h 10.49.83.107 -x -W -D cn=Administrator,dc=my-domain,dc=com -f new_user_policy.ldif

Konfiguration abgeschlossen Inhalt der Datei default_user_ppolicy.ldif mit konfigurierten Richtlinien: dn: cn=Default User Policy,dc=my-domain,dc=com cn: Default User Policy objectClass: pwdPolicy objectClass: namedObject pwdAttribute: userPassword pwdMustChange: TRUE pwdCheckQuality: 1 pwdExpireWarning: 86400 pwdGraceAuthNLimit: 3 pwdInHistory: 5 pwdMaxAge: 2592000 pwdMinAge: 864000 pwdMinLength: 8 pwdSafeModify: TRUE

Diese Richtlinie zeigt beispielhaft unter anderem nachfolgende Punkte:

14-42

Einen Tag vor dem Ablauf der Gültigkeit des Passworts wird der Benutzer darüber informiert, dass sein Passwort abläuft Ein abgelaufenes Passwort kann noch 3-mal verwendet werden, bevor der Benutzer-Account gesperrt wird Beschränkt die Gültigkeit des Benutzer-Passworts auf 30 Tage Schreibt eine minimale Passwortlänge von 8 Zeichen vor Die Zeitangaben erfolgen grundsätzlich in [s]. Über das Attribut pwdPolicySubentry kann einem Benutzer auch eine andere Passwort-Policy zugewiesen werden. Wird das Attribut nicht angegeben, so wird die beim Einrichten des openLDAP-Servers automatisch angelegte 'Default Policy' verwendet.


Erklärung der Attribute: Attribut: Default: Beschreibung: pwdExpireWarning 129600 Vorwarnzeit [s] für den Ablauf des Passwortes

pwdFailureCountInterval 300 Zeit in [s] nach der der Zähler für ungültige Eingaben des Passwortes zurückgesetzt wird (siehe <pwdMaxFailure>)

pwdGraceAuthNLimit 3 Anzahl der 'Grace'-Logins mit denen ein Login mit altem Passwort ermöglicht wird

pwdInHistory 5 Anzahl der n letzten Passwörter, die eine Wiederholung desselben Passwortes ausschließen

pwdLockout TRUE Sperre aktivieren bei mehrfach <pwdMaxFailure> ungültigem Passwort

pwdLockoutDuration 120 Sperrzeit [s] bei mehrfach ungültigem Passwort und aktivierter Sperre

pwdMaxAge 172800 Gültigkeit in [s] des Passwortes (password expires)

pwdMaxFailure 3 Anzahl der ungültigen Eingaben, die ggf. zum Sperren des Accounts führen

pwdMinAge 86400 Minimale Zeit in [s], nach der das Passwort zum ersten Mal geändert werden kann

pwdMinLength 8 Minimale Passwortlänge in Zeichen

pwdMustChange TRUE Notwendigkeit zum Ändern des Passworts beim erstmaligen Login Dieser Eintrag wird nicht ausgewertet

pwdSafeModify TRUE Beim Setzen eines neuen Passworts muss zunächst die Authentifizierung mit dem alten Passwort durchgeführt werden

14-43

Attribut: Default: Beschreibung:

pwdCheckQuality 2 Aktivierung der Überprüfung der Passwort-Qualität

Eine detaillierte Beschreibung der Attribute finden Sie unter:

'http://www.zytrax.com/books/ldap/ch6/ppolicy.html#pwdpolicyattributes'

14.7.4 Wie wird ein Benutzer auf dem openLDAP-Server angelegt?

Nächster Konfigurationsschritt: (empfohlen) Kapitel Wie wird ein Benutzer auf dem openLDAP-Server mit Apache Directory Studio angelegt? (Kapitel: 14.7.5)

Nächster Konfigurationsschritt: (alternativ) Kapitel Wie wird ein Benutzer auf dem openLDAP-Server manuell angelegt? (Kapitel: 14.7.6)

14.7.5 Wie wird ein Benutzer auf dem openLDAP-Server mit Apache Directory Studio angelegt?

In der APROL Benutzerverwaltung angelegte Benutzer sowie im OperatorManager verwaltete Operatoren können als LDIF-Datei exportiert und ins LDAP-System importiert werden. Hier wird ein Import über die über das Apache Directory Studio (ADS) mittels grafischer Benutzeroberfläche beschrieben.

Die aus der APROL Benutzerverwaltung / dem OperatorManager exportierten LDIF-Dateien sind Base-64 kodiert, so dass eine Anzeige im Klartext verhindert wird.

Für die aus der APROL Benutzerverwaltung / dem OperatorManager exportierten LDIF-Dateien ist zu beachten, dass das in APROL vergebene Passwort als StartUp-Passwort auch für die Authentifizierung via LDAP verwendet wird. Dieses Passwort kann je nach Passwort-Richtlinie bei Erstanmeldung vom Benutzer geändert werden.

Nächster Konfigurationsschritt: Kapitel Wie wird ein APROL-System für den LDIF-Export vorkonfiguriert? (Kapitel: 14.7.5.1)

14-44

14.7.5.1 Wie wird ein APROL-System für den LDIF-Export vorkonfiguriert? Vor einem Export der Benutzer / Operatoren müssen die LDAP-Server Eigenschaften konfiguriert werden. Für die Runtime-Umagebung wird der Dialog in den Projekt-Eigenschaften unter dem Reiter 'Runtime-Optionen/Operator-Authentifizierung' verwendet. Für das Engineering-System sind diese Konfigurationen global unter 'Extras/Globale Engineering-Optionen' zu tätigen. In diesen Dialogen kann auch das Template zur Erstellung der LDIF-Dateien ausgewählt werden. LDAP-Server Eigenschaften zum Benutzer-Export

Abbildung 193: LDAP-Server Eigenschaften zum Benutzer-Export

Navigation: CaeManager / Extras / Globale Engineering-Optionen / LDAP-Server Eigenschaften


Basis-DN für Benutzer ou=<Organisationseinheit>

Benutzer-Template Pfad ist bereits eingetragen

Mit [OK] bestätigen

Basis-DN für Benutzer: Aus der Benutzerverwaltung exportierte Benutzer werden beim Import in das LDAP-Verzeichnis unter dem hier eingetragenen Verzeichnis angelegt.

LDAP-Server Eigenschaften zum Operator-Export

Abbildung 194: LDAP-Server Eigenschaften zum Operator-Export

Navigation: CaeManager / Projekt auswählen / Eigenschaften aus dem Kontextmenü aufrufen / Reiter Runtime-Optionen / LDAP-Server Eigenschaften

14-45





Basis-DN für Operatoren: Aus dem OpertatorManager exportierte Operatoren werden beim Import in das LDAP-Verzeichnis unter dem hier eingetragenen Verzeichnis angelegt.

Nächster Konfigurationsschritt: Kapitel Wie werden Benutzer und Operator aus dem APROL-System in LDIF-Format exportiert? (Kapitel: 14.7.5.2)

14.7.5.2 Wie werden Benutzer und Operator aus dem APROL-System in LDIF-Format exportiert?

In den Stammdaten für Benutzer und Operatoren können die LDAP-Benutzerrichtlinien namentlich eingetragen werden. Standardmäßig wird die Richtlinie mit der Bezeichnung 'Default Policy' verwendet, die nach der Installation eines openLDAP-Servers immer verfügbar ist.

1) Der Distinguished Name (DN) eines Benutzers muss eindeutig sein. Da die Benutzer-Namen im Active Directory Server in Verzeichnissen verwaltet werden, muss daher das Wertepaar (Vorname, Nachname) eindeutig sein. 2) Die Tupel Vorname, Nachname, sowie Login-Name müssen den Einträgen in der APROL Benutzerverwaltung bzw. im OperatorManager entsprechen. 3) Der Login-Name (uid) im Active Directory-Server darf nur einmal vorkommen. Hier findet keine Plausibilitätsprüfunf durch den open LDAP-Server statt!



Vorbereitung eines Benutzers für den LDIF-Export

14-46

Abbildung 195: Vorbereitung eines Benutzers für den LDIF-Export

Navigation: CaeManager / Benutzerverwaltung / Detailansicht des Benutzers

LDAP: Lokale Authentifizierung zulassen aktiviert

LDAP Password Policy Default Policy


Vorbereitung eines Operators für den LDIF-Export

Abbildung 196: Vorbereitung eines Operators für den LDIF-Export

Navigation: OperatorManager / Operator editieren / Stammdaten

LDAP: Lokale Authentifizierung zulassen aktiviert

LDAP Password Policy Default Policy


Benutzer-Export

14-47

Abbildung 197: Auswahl des Dateinamens und des Zielverzeichnisses

Navigation: CaeManager / Extras / Benutzerverwaltung / Benutzer auswählen / Kontextmenü 'Export für LDAP-Server (LDIF)'

Dateiname <Dateinamen wählen>

Mit [Speichern] bestätigen Operator-Export

Abbildung 198: Auswahl des Dateinamens und des Zielverzeichnisses

Navigation: OperatorManager / Operator auswählen / Kontextmenü 'Export für LDAP-Server (LDIF)'

Dateiname <Dateinamen wählen>

Mit [Speichern] bestätigen

Nächster Konfigurationsschritt: Kapitel Wie wird eine LDIF-Datei in den openLDAP-Server mit Apache Directory Studio importiert? (Kapitel: 14.7.5.3)

Nächster Konfigurationsschritt: Kapitel Anbindung von APROL mit openLDAP / Active Directory Server (Kapitel: 14.9)

14-48

14.7.5.3 Wie wird eine LDIF-Datei in den openLDAP-Server mit Apache Directory Studio importiert?

Im ADS bestehen nachfolgende Möglichkeiten, den Import Wizard aufzurufen:

Ansicht 'Verbindungen' Ansicht Verbindungen / Verbindung auswählen / Import > LDIF Import aus dem Kontextmenü

Ansicht 'LDAP Browser' Ansicht LDAP Browser / Eintrag auswählen / Import > LDIF Import aus dem Kontextmenü

Menü Leiste Menü Leiste / Datei / Import... / LDIF in LDAP

Abbildung 199: Import Wizard des ADS

Navigation: Import Wizard

LDIF Datei <LDIF Datei mit Benutzer / Operator>

Import nach <Verbindung auswählen>

Loggen aktivieren aktiviert

Verwende vorgegebene Logdatei aktiviert

Bestehende Logdatei überschreiben aktiviert

Aktualisiere bestehende Einträge deaktiviert

Bei einem Fehler weiterfahren deaktiviert

Mit [Fertig stellen] bestätigen

14-49

Import nach: Das Feld ist bis auf eine Ausnahme schon mit der aktuellen Verbindung vorbelegt. Nur wenn der Import Wizard über das Menü 'Datei / Import... / LDIF in LDAP' aufgerufen wird, dann muss eine Verbindung manuell ausgewählt werden.

Verwende vorgegebene Logdatei: Statt eine bestehende Logdatei zu überschreiben, kann auch eine neue Datei über die Option 'Verwende eigene Logdatei' angelegt werden.

Bestehende Logdatei überschreiben: Falls nicht aktiviert, werden Sie bei jedem Import aufgefordert, einen neuen Dateinamen anzugeben.

Aktualisiere bestehende Einträge: Falls ein bestehender Benutzer (cn) aktualisiert werden soll, muss dieses Feld aktiviert werden.

Nächster Konfigurationsschritt: Informationen zur weiteren Bearbeitungsreihenfolge entbnehmen Sie bitte dem vorangegangenen Kapitel.

14.7.6 Wie wird ein Benutzer auf dem openLDAP-Server manuell angelegt? Benutzer werden manuell durch Kopieren und Anpassen der Vorlagendatei im LDIF-Format vorbereitet und anschließend in den LDAP-Server importiert.

Die im LDAP zu authentifizierenden Benutzer / Operatoren müssen im APROL bekannt sein, da die APROL-Rechte dort konfiguriert werden. Daher müssen neue Operatoren via Download den Operator-Stationen bekannt gemacht werden.


(Kapitel: 14.1)

14-50

1) Der Distinguished Name (DN) eines Benutzers muss eindeutig sein. Da die Benutzer-Namen im openLDAP Server in Verzeichnissen verwaltet werden, muss daher das Wertepaar (Vorname, Nachname) eindeutig sein. 2) Die Tupel Vorname, Nachname sowie Login-Name müssen den Einträgen in der APROL Benutzerverwaltung bzw. im OperatorManager entsprechen. 3) Der Login-Name (uid) im openLDAP-Server darf nur einmal vorkommen. Hier findet keine Plausibilitätsprüfunf durch den open LDAP-Server statt!



Legen Sie anschließend einen neuen Benutzer an:

In der Kommandozeile cp user_template_inetOrgPerson.ldif new_user.ldif

vi new_user.ldif Manuelle Anpassung dn: CN=<Vorname> <Nachname>,OU=<Abteilung>,OU=<Stadt>,OU=<Land>,

DC=<Domainname>,DC=<Top-Level-Domainname>

objectClass: top

objectClass: person

objectClass: inetOrgPerson

pwdPolicySubentry: cn=<Default User Policy|New_user_policy name>,dc=<Domainname>,dc=<Top-Level-Domainname>

cn: <Vorname> <Nachname>

uid: <Loginname>

sn: <Nachname>

In der Kommandozeile Allgemeine Syntax: ldapadd -h <IP-Adresse> -x -W -D cn=Administrator,dc=<Domainname>,dc=<Top-Level-Domainname> -f new_user.ldif

Beispiel: ldapadd -h 10.49.83.107 -x -W -D cn=Administrator,dc=my-domain,dc=com -f muellerm.ldif

Nächster Konfigurationsschritt: Passwort festlegen

Über das Attribut pwdPolicySubentry kann einem Benutzer auch eine andere Passwort-Policy zugewiesen werden. Wird das Attribut nicht angegeben, so wird die beim Einrichten des openLDAP-Servers automatisch angelegte 'Default Policy' verwendet.

14-51

Abschließend muss das Passwort wie folgt gesetzt werden:


Allgemeine Syntax:

ldappasswd -h <IP-Adresse> -x -W -S -D cn=Administrator,dc=<Domainname>,dc=<Top-Level-Domainname> "cn=<Vorname> <Nachname>,ou=<Abteilung>,ou=<Stadt>,ou=<Land>, dc=<Domainname>,dc=<Top-Level-Domainname>"

Beispiel: ldappasswd -h 10.49.83.107 -x -W -S -D cn=Administrator,dc=my-domain,dc=com "cn=Max Mueller,ou=Development,ou=Essen,ou=Germany,dc=my-domain,dc=com"


Nächster Konfigurationsschritt: Kapitel Anbindung von APROL mit openLDAP / Active Directory Server (Kapitel: 14.9)

14.7.7 Wie wird ein Benutzer auf einem openLDAP-Server entfernt? Ein Benutzer kann mit dem folgenden Befehl entfernt werden.


(Kapitel: 14.1)

In der Kommandozeile Allgemeine Syntax: ldapdelete -h <IP-Adresse> -x -W -D cn=Administrator,dc=<Domainname>,dc=<Top-Level-Domainname> "cn=<Vorname> <Nachname>,ou=<Abteilung>,ou=<Stadt>,ou=<Land>, dc=<Domainname>,dc=<Top-Level-Domainname>" Beispiel: ldapdelete -h 10.49.83.107 -x -W -D cn=Administrator,dc=my-domain,dc=com "cn=Max Mueller,ou=Development,ou=Essen,ou=Germany,dc=my-domain,dc=com"


14-52

14.7.8 Wie wird ein gesperrter Benutzer-Account im openLDAP-Server frei gegeben?

Freigabe eines gesperrten Accounts im openLDAP-Server. Ist der Benutzer-Account verriegelt, (pwdLockout ist TRUE) kann er durch den Administrator durch Verwendung einer der folgenden Verfahren entriegelt werden: Löschen Sie das ausführbare Attribut pwdAccountLockedTime. Hierdurch wird dem Benutzer ermöglicht, mit dem aktuellen Passwort fortzufahren, sofern das Passwort nicht abgelaufen ist. Fügen Sie dem ausführbaren Attribut pwdReset mit dem Wert TRUE oder FALSE hinzu. Der Wert FALSE wird ausschließlich verwendet, wenn das Passwort NICHT abgelaufen ist und hat die selbe Auswirkung wie das Löschen des Attributs.


(Kapitel: 14.1)

Die zweite Methode (Attribut 'pwdReset') wird hier angewendet:

In der Kommandozeile vi benutzer.ldif Manuelle Anpassung dn: CN=<Vorname> <Nachname>,OU=<Abteilung>, OU=<Stadt>,OU=<Land>,dc=<Domainname>, DC=<Top-Level-Domainname>

changetype: modify

replace: pwdReset

pwdReset: TRUE

-- In der Kommandozeile Allgemeine Syntax: ldapmodify -h <IP-Adresse> -x -W -D cn=Administrator,dc=<Domainname>,dc=<Top-Level-Domainname> -f benutzer.ldif

Beispiel: ldapmodify -h 10.49.83.107 -x -W -D cn=Administrator,dc=my-domain,dc=com -f benutzer.ldif


14-53

dn: cn=Max Mueller,ou=Development,ou=Essen,ou=Germany,dc=my-domain,dc=com changetype: modify replace: pwdReset pwdReset: TRUE --

14.7.9 Wie wird einem bestehenden Benutzer auf einem openLDAP Server eine Passwortrichtlinie zugewiesen?

Anpassen der Vorlage-Datei 'benutzer.mod.ldif'.


(Kapitel: 14.1)

In der Kommandozeile vi benutzer.mod.ldif manuell anpassen dn: cn=<Vorname> <Nachname>,ou=<Abteilung>, ou=<Stadt>,ou=<Land>,dc=<Domainname>, dc=<Top-Level-Domainname>

changetype: modify

replace: pwdPolicySubentry

pwdPolicySubentry: cn=<Default User Policy|New User Policy Name>,dc=<Domainname>,dc=<Top-Level-Domainname>

Speichern und weiter mit LDAP-Befehl dn: cn=Max Mueller,ou=Development,ou=Essen,ou=Germany,dc=my-domain,dc=com changetype: modify replace: pwdPolicySubentry pwdPolicySubentry: cn=New User Policy,dc=my-domain,dc=com


Allgemeine Syntax: ldapmodify -h <IP-Adresse> -x -W -D cn=Administrator,dc=<Domainname>,dc=<Top-Level-Domainname> -f benutzer.mod.ldif

Beispiel: ldapmodify -h 10.49.83.107 -x -W -D cn=Administrator,dc=my-domain,dc=com -f benutzer.mod.ldif


14-54

14.7.10 Wie wird eine Benutzer auf einem openLDAP Server editiert? Mit 'replace' wird das Attribut angegeben, das modifiziert werden soll.

Anpassen der Vorlage-Datei 'benutzer.mod.ldif'.


(Kapitel: 14.1)

In der Kommandozeile vi benutzer.mod.ldif manuell anpassen dn: cn=<Vorname> <Nachname>,ou=<Abteilung>,ou=<Stadt>,ou=<Land>, dc=<Domainname>,dc=<Top-Level-Domainname>

changetype: modify

replace: <Attribut>

<Attribut>: <Ersatzwert>

--

In der Kommandozeile Allgemeine Syntax: ldapmodify -h <IP-Adresse> -x -W -D cn=Administrator,dc=<Domainname>,dc=<Top-Level-Domainname> -f benutzer.mod.ldif

Beispiel: ldapmodify -h 10.49.83.107 -x -W -D cn=Administrator,dc=my-domain,dc=com -f benutzer.mod.ldif

Speichern und weiter mit LDAP-Befehl

14.7.11 Wie wird das Passwort eines Benutzers auf einem openLDAP Server geändert?

Änderung des Passworts auf einem openLDAP-Server:


(Kapitel: 14.1)

14-55

In der Kommandozeile Allgemeine Syntax:

ldappasswd -h <IP-Adresse> -x -W -S -D cn=Administrator,dc=<Domainname>,dc=<Top-Level-Domainname> "cn=<Vorname> <Nachname>,ou=<Abteilung>,ou=<Stadt>,ou=<Land>, dc=<Domainname>,dc=<Top-Level-Domainname>"

Beispiel: ldappasswd -h 10.49.83.107 -x -W -S -D cn=Administrator,dc=my-domain,dc=com "cn=Max Mueller,ou=Development,ou=Essen,ou=Germany,dc=my-domain,dc=com"


14.7.12 Wie werden alle konfigurierten Benutzer auf einem openLDAP Server aufgelistet?


(Kapitel: 14.1)

In der Kommandozeile Allgemeine Syntax: ldapsearch -h <IP-Adresse> -p <Port> -D cn=Administrator,dc=<Domainname>,dc=<Top-Level-Domainname> -b "DC=<Domainname>,DC=<Top-Level-Domainname>" "uid=*" -W

Beispiel: ldapsearch -h 10.49.83.107 -p 389 -D cn=Administrator,dc=my-domain,dc=com -b "DC=my-domain,DC=com" "uid=*" -W


14.8 Benutzer-Verwaltung auf einem Active Directory Server Nachfolgend wird das Anlegen von Benutzer-Accounts an einem Kerberos-fähigem Windows Active Directory Server und die Konfiguration von Account- bzw. Passwortrichtlinien exemplarisch (anhand eines Windows Server 2003) beschrieben. Die Kerberos-Authentifizierung wird aus Sicherheitsgründen und zur Auswertung der Passwortrichtlinien eines Windows Servers benötigt.

14-56

Der Distinguished Name eines Benutzers muss eindeutig sein. Da der DN eines Benutzers Vor- und Nachname enthält, muss daher das Wertepaar (Vorname, Nachname) eindeutig sein. Die Tupel Vorname, Nachname, sowie Login-Name müssen die Einträge in der APROL Benutzerverwaltung bzw. OperatorManager entsprechen.

Bei der Verwendung von Kerberos ist zwingend eine Zeitsynchronisation auf allen betroffenen Rechnern zu konfigurieren!

Auf dem APROL-Server kann die NTP-Zeitsynchronisation via AprolConfig parametriert werden.

Nächster Konfigurationsschritt: Kapitel Wie wird ein Benutzer auf einem Active Directory Server angelegt? (Kapitel: 14.8.1)

14.8.1 Wie wird ein Benutzer auf einem Active Directory Server angelegt? Legen Sie einen neuen Benutzer mit dem Programm 'Active Directory Users and Computers' an.


(Kapitel: 14.1)

14-57

Abbildung 200: Benutzer erstellen

Navigation: Start / Administrative Tools / Active Directory Users and Computers / <Datenbank> / Users / Kontextmenü 'New' / User

Weiter mit Kontextmenü 'User' Es erfolgt die Eingabe der allgemeinen Account-Informationen. Für die Authentisierung der Benutzer bzw. Operatoren im APROL muss ein Account-Name ('User logon name') verwendet werden, der ebenfalls im APROL-System (Benutzerverwaltung / OperatorManager) mit entsprechenden Rechten konfiguriert ist: Es erfolgt die Eingabe der allgemeinen Account-Informationen:



First name eingeben

Last name eingeben

14-58

Full name eingeben

User logon name eingeben

User logon name (2.te Teil) @<Computername>.local

User logon name (Pre Windows 2000) eingeben

Weiter mit [Next] Anschließend muss ein Initialpasswort vergeben werden, das später durch den Benutzer geändert werden kann (Option: 'User must change password at next logon'):



Password eintragen

Confirm password eintragen

Weiter mit [Next]

Kapitel Wie wird ein Benutzer auf einem Active Directory Server editiert? (Kapitel: 14.8.2)

14.8.2 Wie wird ein Benutzer auf einem Active Directory Server editiert? Über den Eintrag 'Eigenschaften' des Kontextmenüs können die Benutzerdaten eingegeben werden.

14-59

Abbildung 203: Benutzer editieren

Navigation: Start / Administrative Tools / Active Directory Users and Computers / <Datenbank> / Users / <User wählen> / Kontextmenü 'Properties'

Weiter mit Kontextmenü 'Properties'

Für die Authentifizierung der Benutzer bzw. Operatoren im APROL muss ein Vor- und Nachname im Reiter 'General' verwendet werden, der ebenfalls im APROL-System (Benutzerverwaltung / OperatorManager) mit entsprechenden Rechten konfiguriert ist.

Abbildung 204: Benutzer-Eigenschaften 'General'

Navigation: Start / Administrative Tools / Active Directory Users and Computers / <Datenbank> / Users / <User wählen> / Kontextmenü 'Properties'/ General

14-60

First name eintragen

Last name eintragen

Display name eintragen

Weiter mit Reiter 'Account'

Abbildung 205: Benutzer-Eigenschaften 'Account'

Navigation: Start / Administrative Tools / Active Directory Users and Computers / <Datenbank> / Users / <User wählen> / Kontextmenü 'Properties'/ Account

User logon name eintragen

User logon name (Teil 2) eintragen

User logon name (Pre Windows 2000) eintragen

Do not require Kerberos preauthentication deaktiviert

Weiter mit eigene Anpassungen Folgende Account-Optionen (Account options) können am Active Directory Server als Benutzer-Eigenschaft konfiguriert werden und werden im APROL-System entsprechend berücksichtigt:

Option: User must change password at next logon

openLDAP: Nicht direkt konfigurierbar Durch Hinzufügen des Attributs pwdReset und Setzen auf TRUE kann beim nächsten Einloggen ein neues Passwort angefordert werden.

Das Attribut pwdMustChange der Passwortrichtlinie muss auf TRUE gesetzt sein.

Änderung des Initialpasswortes erzwingen. Beim nächsten Anmeldeversuch wird der Benutzer zur Neuvergabe des Passwortes aufgefordert.

14-61

Im APROL-System erfolgt diese Aufforderung genau wie bei einem abgelaufenem Passwort. Option: Account is disabled

openLDAP: Nicht direkt konfigurierbar Kann durch das Setzen des Attributs pwdAccountLockedTime mit einem gültigen Zeitstempel mit der aktuellen Zeit im Format YYYMMDDhhmmssZ erreicht werden, z. B. 20110317160517Z.

Die Sperrung des Accounts wird durch Entfernen des Attributs wieder aufgehoben. Eine Änderung des Passworts wird nach dem Entsperren nicht angefordert.

Im APROL-System erfolgt bei einem gesperrten Account kein Login und es wird eine entsprechender Hinweis angezeigt. Alternative:

Der Account kann auch über die Benutzer- / Operatorverwaltung von APROL gesperrt werden. Option: Do not require Kerberos preauthentication

Es wird empfohlen, diese Option nicht zu setzen! Ist die Account-Option 'Do not require Kerberos preauthentication' gesetzt, sind nachfolgende Einschränkungen zu berücksichtigen: 1. Windows Server 2003: Es erfolgt keine Überprüfung, ob ein Passwort abgelaufen oder initial gesetzt werden muss. Es erfolgt in jedem Fall ein Login. 2. Windows Server 2000: Ist der Account deaktiviert und das Passwort abgelaufen, so erfolgt kein entsprechender Hinweis, dass der Account gesperrt ist.

Navigation: Start / Administrative Tools / Active Directory Users and Computers / <Datenbank> / Users / <User wählen> / Kontextmenü 'Properties'/ Account

Gewünschte Richtlinien Aktivieren / deaktivieren


Nächster Konfigurationsschritt: Kapitel Passwortrichtlinien / Account-Richtlinien auf einem Active Directory Server? (Kapitel: 14.12)

14-62

14.8.3 Wie wird das Passwort eines Benutzers auf einem Active Directory Server geändert?


(Kapitel: 14.1)

Abbildung 206: Passwort zurücksetzen

Navigation: Start / Administrative Tools / Active Directory Users and Computers / <Datenbank> / Users / <User wählen>

Weiter mit Kontextmenü 'Reset Password...'

Abbildung 207: Passwort-Eingabe

Navigation: Start / Administrative Tools / Active Directory Users and Computers / <Datenbank> / Users / <User wählen> / Kontextmenü 'Reset Password...'

New password <Password> Confirm password <Password>


14-63

14.9 Anbindung von APROL mit openLDAP / Active Directory Server Das nachfolgende Kapitel erläutert die Anbindung eines Linux-Servers mit einem LDAP-Client an einen openLDAP-Server bzw. an einen Active Directory Server. openLDAP-Server: Nächster Konfigurationsschritt (Alternativ): Kapitel Wie wird ein APROL-Server an einen openLDAP-Server mit YaST angebunden? (Kapitel: 14.9.1)

Nächster Konfigurationsschritt (Empfohlen): Kapitel Wie wird ein APROL-Server manuell an einen openLDAP-Server angebunden? (Kapitel: 14.9.2)

Active Directory Server: Nächster Konfigurationsschritt: Kapitel Wie wird einen APROL-Server an einen Active Directory-Server angebunden? (Kapitel: 14.9.4)

14.9.1 Wie wird ein APROL-Server an einen openLDAP-Server mit YaST angebunden?

Beim ersten Starten der Konfiguration des LDAP-Clients über das Icon 'LDAP-Client' müssen folgende Konfigurations-Einstellungen durchgeführt werden.


(Kapitel: 14.1)

14-64

Abbildung 208: Konfiguration des LDAP-Clients

Navigation: YaST2 / Netzwerkdienste / LDAP-Client

LDAP nicht verwenden aktiviert

Adressen von LDAP-Servern <Fully-Qualified Domain Name> des Rechners, auf dem der openLDAP-Server eingerichtet und gestartet ist

LDAP-Basis-DN dc=<Domainname>,dc=<Top-Level-Domainname>

LDAP TLS/SSL deaktiviert (zunächst)

LDAP Version 2 deaktiviert (zunächst)

Automounter starten deaktiviert

Home-Verzeichnis bei Anmeldung erstellen

deaktiviert

Weiter mit [Erweiterte Konfiguration]

Der Domain Name muss für die spätere Verwendung von SSL als Fully-Qualified Domain Name angegeben werden.

Der openLDAP-Server unterstützt ebenfalls das Protokoll LDAPv2. Nachfolgend wird jedoch das Protokoll LDAPv3 verwendet.

Die Basis-Konfiguration erfolgt zunächst ohne die Unterstützung von SSL. Weitere Informationen im Kapitel Erweiterte Sicherheit durch Verwendung von SSL / TLS (Kapitel: 14.10)

14-65

Der Basis-DN kann über den Button [DN holen] auch automatisch abgefragt und ausgewählt werden. Der obere Eintrag im sich öffnenden Dialog ist der Basis-DN und kann mit [OK] übernommen werden.

Reiter 'Verwaltungseinstellungen':

Abbildung 209: Reiter 'Verwaltungseinstellungen'

Navigation: YaST2 / Netzwerkdienste / LDAP-Client / [Erweiterte Konfiguration] / Verwaltungseinstellungen

Administrator-DN cn=Administrator

Basis-DN anhängen aktiviert

Standardkonfigurationsobjekte erzeugen deaktiviert

Heimverzeichnisse auf diesem Computer deaktiviert


Unter dem Reiter 'Client-Einstellungen' sind keine weiteren Einstellungen notwendig. Die Vorgaben werden übernommen.

Nächster Konfigurationsschritt: Kapitel Welche zusätzlichen manuellen Anpassungen müssen durchgeführt werden? (Kapitel: 14.9.1.1)

14.9.1.1 Welche zusätzlichen manuellen Anpassungen müssen durchgeführt werden?

Anpassung der ldap.conf

14-66


(Kapitel: 14.1)

In der Datei /etc/ldap.conf müssen folgende Einträge nachgetragen werden:


vi /etc/ldap.conf Manuelle Änderungen durchführen

binddn cn=LDAP Query,cn=Users, dc=<Domainname>,dc=<Top-Level-Domainname>

bindpw <Passwort>

Der Eintrag pam_filter einfügen / ändern. #pam_filter objectClass=posixAccount auskommentieren pam_filter objectClass=inetOrgPerson einfügen / ändern

Der Eintrag pam_filter darf nur genau einmal in der Konfigurationsdatei aktiv sein! Da der Eintrag pam_filter in der Konfigurationsdatei an mehreren Stellen verwendet wird, muss überprüft werden, ob nur ein Eintrag aktiv ist.

Wenn in der Passwortrichtlinie (Reiter 'Passwortänderungsrichtlinien') die Option 'Altes Passwort für Passwortänderung erforderlich' gesetzt ist oder das Attribut 'pwdSafeModify' aktiviert ist, muss folgende Anpassung des bestehenden Eintrags 'pam_password' in der Datei /etc/ldap.conf erfolgen:


14-67

Wenn das Passwortänderungsprotokoll 'exop_send_old' verwendet (altes Passwort für Passwortänderung erforderlich) wird und die Überprüfung von mehrfach verwendeten Passwörtern anhand der Passwort-Historie eingeschaltet ist (maximale Anzahl der in der Historie gespeicherte Passwörter) und fehlschlägt dann wird keine Fehlermeldung angezeigt. Stattdessen wird eine Meldung zurückgegeben, dass das Passwort erfolgreich geändert worden ist obwohl dies nicht der Fall ist.

Aufgrund weiterer festgestellter Fehlverhalte, empfiehlt B&R das Passwortänderungsprotokoll 'exop_send_old' nicht zu verwenden.

pam_password exop


Nächster Konfigurationsschritt: Kapitel Wie wird das PAM-LDAP-Modul für die Anbindung an den openLDAP-Server konfiguriert? (Kapitel: 14.9.3)

14.9.2 Wie wird ein APROL-Server manuell an einen openLDAP-Server angebunden?

Wenn Sie keinen YaST verwenden müssen nachfolgende Dateien zunächst kopiert und manuell angepasst werden: Kapitel Wie wird ein APROL-Server an einen openLDAP-Server mit YaST angebunden? (Kapitel: 14.9.1)


(Kapitel: 14.1)

Datei kopieren:

In der Kommandozeile cp /opt/aprol/etc/LDAP/client/pam.d/aprolloginserver /etc/pam.d/

Teil-Konfiguration abgeschlossen Manuelle Anpassungen in /etc/ldap.conf In der Kommandozeile

14-68

vi /etc/ldap.conf Manuelle Änderungen durchführen

host <Fully Qualified Domain Name> base dc=<Domainname>,dc=<Top-Level-Domainname>

binddn cn=LDAP Query,cn=Users,dc= <Domainname>,dc=<Top-Level-Domainname>

bindpw <Passwort des Abfragebenutzers 'Query'>

ssl no

ldap_version 3

pam_filter objectClass=inetOrgPerson

tls_checkpeer no

#ssl on

#ssl start_tls

Eventuelle weitere Anpassung

Der Eintrag 'host' muss für die Verwendung von SSL als Fully-Qualified Domain Name angegeben werden.

Wenn in der Passwortrichtlinie (Reiter 'Passwortänderungsrichtlinien') die Option 'Altes Passwort für Passwortänderung erforderlich' gesetzt ist oder das Attribut 'pwdSafeModify' aktiviert ist, muss folgende Anpassung des bestehenden Eintrags 'pam_password' in der Datei /etc/ldap.conf erfolgen:


14-69

Wenn das Passwortänderungsprotokoll 'exop_send_old' verwendet (Altes Passwort für Passwortänderung erforderlich) wird und die Überprüfung von mehrfach verwendeten Passwörtern anhand der Passwort-Historie eingeschaltet ist (Maximale Anzahl der in der Historie gespeicherte Passwörter) und fehlschlägt dann wird keine Fehlermeldung angezeigt. Stattdessen wird eine Meldung zurückgegeben, dass das Passwort erfolgreich geändert worden ist obwohl dies nicht der Fall ist.

Aufgrund weiterer festgestellter Fehlverhalte, empfiehlt B&R das Passwortänderungsprotokoll 'exop_send_old' nicht zu verwenden.

pam_password exop

Manuelle Anpassungen in /etc/nsswitch.conf Die Einträge services, netgroup und aliases werden um ldap ergänzt, der Eintrag passwd_compat werden hinzugefügt.


vi /etc/nsswitch.conf manuelle Änderungen durchführen

passwd: compat

group: files ldap

hosts: files mdns4_minimal [NOTFOUND=return] dns

networks: files dns

services: files ldap

protocols: files

rpc: files

ethers: files

netmasks: files

netgroup: files ldap

publickey: files

bootparams: files

automount: files nis

aliases: files ldap

passwd_compat: ldap


Nächster Konfigurationsschritt: Kapitel Wie wird das PAM-LDAP-Modul für die Anbindung an den openLDAP-Server konfiguriert? (Kapitel: 14.9.3)

14-70

14.9.3 Wie wird das PAM-LDAP-Modul für die Anbindung an den openLDAP-Server konfiguriert?

Die Pluggable Authentication Modules (PAM) sind eine Softwarebibliothek, die eine allgemeine Programmierschnittstelle (API) für Authentisierungsdienste zur Verfügung stellt.

Grundlegende Information über PAM finden Sie unter http://de.wikipedia.org

Im Verzeichnis /etc/pam.d wird die Datei aprolloginserver hinzugefügt.

In der Kommandozeile cp /opt/aprol/etc/LDAP/client/pam.d/aprolloginserver /etc/pam.d/

Konfiguration abgeschlossen Nächster Konfigurationsschritt: Kapitel Wie wird die Sicherheit der Verbindung zwischen einem APROL-Server und einem openLDAP-Server erhöht? (Kapitel: 14.10.1)

14.9.4 Wie wird einen APROL-Server an einen Active Directory-Server angebunden?

Die im Folgenden beschriebene manuelle Konfiguration ist notwendig, um eine Kerberos-Authentifizierung am Windows-Server zu ermöglichen. Die Kerberos-Authentifizierung wird aus Sicherheitsgründen und zur Auswertung der Passwortrichtlinien (u. a. password expires) benötigt.

Die Anbindung eines APROL Rechners über Kerberos an einen Windows basierten Active Directory Server sollte nicht mit dem YaST2 durchgeführt werden. Grund: Durch die Konfiguration mit dem YaST2 werden alle Konfigurationsdateien der PAM-Module automatisch angepasst und überschrieben. Dies führt dazu, dass bei Linux-Logins eine Authentifizierung nur über den ActiveDirectory-Server durchgeführt wird.

14.9.4.1 Wie wird Kerberos zur Anbindung an den Active Directory-Server konfiguriert?

Die Kerberos-Authentifizierung wird aus Sicherheitsgründen und zur Auswertung der Passwortrichtlinien eines Active Directory-Servers benötigt.

14-71


(Kapitel: 14.1)

Anpassung der Datei krb5.conf:

In der Kommandozeile cp /opt/aprol/etc/LDAP/client/krb5.conf /etc/krb5.conf

vi /etc/krb5.conf

[libdefaults] default_realm

<REALM DES KERBEROS-SERVERS>

in Großbuchstaben.

[realms] <DOMAINNAME>.<TOP-LEVEL-DOMAINNAME>

in Großbuchstaben. Domainname des Realms

[realms] kdc

<IP-Addresse | Hostname>

des Kerberos-Servers [realms] default_domain

<Domainname>.<Top-Level-Domainname>

[realms] admin_server

<IP-Addresse | Hostname>

des Kerberos-Servers

[domain_realm] .<Domainname>.<Top-Level-Domainname>

<DOMAINNAME>.<TOP-LEVEL-DOMAINNAME>

in Großbuchstaben.


14-72

Beispiel: [libdefaults] default_realm = MY-DOMAIN.COM clockskew = 300 [realms] MY-DOMAIN.COM = { kdc = 10.49.80.51 default_domain = my-domain.com admin_server = 10.49.80.51 } [logging] kdc = FILE:/var/log/krb5/krb5kdc.log admin_server = FILE:/var/log/krb5/kadmind.log default = SYSLOG:NOTICE:DAEMON [domain_realm] .my-domain.com = MY-DOMAIN.COM [appdefaults] pam = { ticket_lifetime = 1d renew_lifetime = 1d forwardable = true proxiable = false minimum_uid = 1 external = sshd use_shmem = sshd clockskew = 300 banner = "" ignore_unknown_principals = false no_ccache = true

Der Realm des Kerberos-Servers (Administrationsbereich) entspricht in den meisten Fällen der Realm der Domäne. bzw. <Domainname>.<Top-Level-Domainname>.

In die Sektion [domain_realm] wird die Kopplung der Domäne an den Realm definiert.

Nächster Konfigurationsschritt: Kapitel Wie wird das PAM-Kerberos-Modul für die Anbindung an einen Active Directory-Server konfiguriert? (Kapitel: 14.9.4.2)

14.9.4.2 Wie wird das PAM-Kerberos-Modul für die Anbindung an einen Active Directory-Server konfiguriert?

Die Konfigurationsdatei /etc/aprolloginserver für PAM muss für die Verwendung mit Kerberos angepasst werden.

In der Kommandozeile cp /opt/aprol/etc/LDAP/client/pam.d/aprolloginserver.krb5 /etc/pam.d/aprolloginserver¶

Konfiguration abgeschlossen auth required pam_krb5.so no_user_check¶ account required pam_krb5.so try_first_pass no_user_check¶ password required pam_krb5.so no_user_check¶ session optional pam_krb5.so no_user_check¶

14-73

Nächster Konfigurationsschritt: Kapitel Wie wird die LDAP-Authentifizierung für das Engineering-System im CaeManager konfiguriert? (Kapitel: 14.11.1)

14.10 Erweiterte Sicherheit durch Verwendung von SSL / TLS für den openLDAP-Server

SSL wird ausschließlich auf dem openLDAP-Server verwendet. Auf dem Active Directory Server wird Kerberos verwendet, das schon eine erweiterte Sicherheit beinhaltet.

Neben der Verbindung zum LDAP-Server über den LDAP-Port 389 kann unter Angabe eines Zertifikates auch eine SSL-Verbindung über den Port 636 aufgebaut werden.

14.10.1 Wie wird die Sicherheit der Verbindung zwischen einem APROL-Server und einem openLDAP-Server erhöht?

Die TLS / SSL-Verschlüsselung wird mit dem YaST2 über die LDAP-Server-Verwaltung aktiviert. Das YaST-Modul 'LDAP-Server' befindet sich unter 'Netzwerkdienste'. Konfiguration auf einem openLDAP-Server:

Abbildung 212: TLS-Einstellungen

Das Erhöhen der Sicherheit ist nicht zwingend notwendig. um ein funktionierendes System zu gewährleisten.

Navigation: YaST2 / Netzwerkdienste / LDAP-Server / Globale Einstellungen / TLS-Einstellungen

TLS aktivieren aktiviert

14-74

Falls kein allgemeines Server-Zertifikat vorhanden ist, weiter mit [CA-Verwaltungsmodul starten], Kapitel Wie wird das für die SSL-Verbindung benötigte Zertifikat für einen openLDAP-Server erstellt? (Kapitel: 14.10.2) und anschließend hier weiter machen.

Allgemeines Server-Zertifikat verwenden aktiviert

Mit [OK] abschließen Nächster Konfigurationsschritt: Kapitel Wie werden unverschlüsselte Verbindungen zum openLDAP-Server unterbunden? (Kapitel: 14.10.3)

Mit Aktivierung der Option 'TLS aktivieren' wird automatisch die Option 'LDAP über SSL (ldaps)-Schnittstelle aktivieren' ebenfalls aktiviert. Am einfachsten ist es, das allgemeine Server-Zertifikat zu verwenden. Alternativ kann ein manuell erzeugtes Zertifikat importiert werden, z. B. ein käuflich erworbenes X.509 (SSL) Zertifikat einer Zertifizierungsstelle.

14.10.2 Wie wird das für die SSL-Verbindung benötigte Zertifikat für einen openLDAP-Server erstellt?

Benötigt wird zunächst ein Root-CA. Dieses Root-CA dient als Container. In diesen Container wird später ein Server-CA für den openLDAP-Server hinzugefügt.


(Kapitel: 14.1)

Eine detaillierte Beschreibung der Attribute (How to recreate SMT 11 CA and server certificate) finden Sie unter: http://www.novell.com/support/php/search.do?cmd =displayKC&docType=kc&externalId=7006024

Es muss nur ein Zertifikat erstellt werden, wenn bislang kein Zertifikat vorhanden ist. Im Beispiel wird ein Zertifikat für den Linux-Server angelegt. Daher ist der nachfolgend angegebene Name 'YaST_Default_CA' zu verwenden:

14-75

Abbildung 213: Erzeugen eines neuen Root-CA

Navigation: YaST2 / Netzwerkdienste / LDAP-Server / Globale Einstellungen / TLS-Einstellungen / [CA-Verwaltungsmodul starten] / [Root-CA erzeugen] (Schritt 1/3)

CA-Name YaST_Default_CA

Allgemeiner Name YaST_Default_CA

Die übrigen Felder <Ihre Firmendaten> Mit [Weiter] fortsetzen

Leerzeichen sind im Allgemeinen CA-Namen nicht zugelassen!


Schlüssellänge Voreinstellung übernehmen

Gültiger Zeitraum Voreinstellung übernehmen

Gültigkeitszeitraum kundenspezifisch

[Erweiterte Einstellungen] kundenspezifisch

Mit [Weiter] fortsetzen

Über den Button [Erweiterte Einstellungen] sind z. Zt. keine Änderungen durchzuführen.


Übersichtsdialog überprüfen

Mit [Erzeugen] fertig stellen

14-76

CA-Name: YaST_Default_CA Allgemeiner Name: YaST_Default_CA Organisation/Firma: B&R Industrie Elektronik GmbH Organisatorische Einheit: B&R Essen E-Mail-Adresse: [email protected] (default) Ort: Essen Bundesland: Nordrheinwestfalen Land: DE Schlüssellänge: 2048 bit Gültiger Zeitraum: 3650 Tage Basic Constaints: CA:true (kritisch) Issuer Alt Name: Subject Alt Name von CA kopieren Key Usage: cRLSign keyCertSign nsComment: "YaST Generated CA Certificate" nsCertType: sslCA emailCA Subject Alt Name: Standard-E-Mail-Adresse kopieren Subject Key Identifier: hash Authority Key Identifier: keyid:always,issuer:always

Erstellen eines allgemeinen Serverzertifikats: Navigation: YaST2 / Netzwerkdienste / LDAP-Server / Globale Einstellungen / TLS-Einstellungen / [CA-Verwaltungsmodul starten] / [CA betreten] / Zertifikate / [Hinzufügen] Schritt (1/3)

Allgemeiner Name <Fully Qualified Domain Name> Mit [Weiter] weiter

Als 'Allgemeiner Name' muss der Fully Qualified Domain Name verwendet werden, damit das Zertifikat referenziert werden kann.

Im Beispiel ist der Name: tcz400.my-domain.com

Navigation: YaST2 / Netzwerkdienste / LDAP-Server / Globale Einstellungen / TLS-Einstellungen / [CA-Verwaltungsmodul starten] / [CA betreten] / Zertifikate / [Hinzufügen] Schritt (2/3)

Passwort <Passwort>

Schlüssellänge Voreinstellung übernehmen

Gültigkeitszeitraum kundenspezifisch

[Erweiterte Einstellungen] kundenspezifisch

Mit [Weiter] weiter Navigation: YaST2 / Netzwerkdienste / LDAP-Server / Globale Einstellungen / TLS-Einstellungen / [CA-Verwaltungsmodul starten] / [CA betreten] / Zertifikate / [Hinzufügen] Schritt (2/3)

Übersichtsdialog überprüfen

[Export] / Als allgemeines Server-Zertifikat exportieren Zertifikat exportieren

Mit [OK] diese Konfiguration abschließen

14-77

Allgemeiner Name: tcz400.my-domain.com Organisation/Firma: B&R Automation GmbH Organisatorische Einheit: Essen E-Mail-Adresse: [email protected] (default) Ort: Essen Bundesland: Nordrheinwestfalen Land: DE Schlüssellänge: 2048 bit Gültiger Zeitraum: 5 Tage Basic Constaints: CA:false Issuer Alt Name: Subject Alt Name von CA kopieren Key Usage: digitalSignature keyEncipherment nsComment: "YaST Generated Server Certificate" nsCertType: server Subject Alt Name: Standard-E-Mail-Adresse kopieren Subject Key Identifier: hash Authority Key Identifier: keyid,issuer:always

Nächster Konfigurationsschritt: Kapitel Wie werden unverschlüsselte Verbindungen zum openLDAP-Server unterbunden? (Kapitel: 14.10.3)

14.10.3 Wie werden unverschlüsselte Verbindungen zum openLDAP-Server unterbunden?

Wenn Sie SSL-Verbindungen auf dem LDAP-Server eingeschaltet haben, ist es immer noch möglich unverschlüsselte Verbindungen zum LDAP-Server herzustellen. Der Protokoll-Listener 'LDAP' wird bei der Erstkonfiguration der Server normalerweise eingeschaltet.

Abbildung 214: Startkonfiguration

Navigation: YaST2 / Netzwerkdienste / LDAP-Server / Startkonfiguration

Protokoll-Listner / LDAP deaktiviert


14-78

Nächster Konfigurationsschritt: Kapitel Wie wird die SSL-Verschlüsselung auf dem APROL-Server aktiviert? (Kapitel: 14.10.4)

14.10.4 Wie wird die SSL-Verschlüsselung auf dem APROL-Server aktiviert?

Auf dem APROL-Server (LDAP-Client) muss die Verwendung von TLS / SSL manuell aktiviert werden.

Der SSL-Eintrag darf auf dem Client nur manuell eingestellt werden. Eine Konfiguration via YaST sollte vermieden werden, da es zu einem mit APROL nicht kompatiblen SSL-Eintrag führt.


vi /etc/ldap.conf

ssl on


Der Eintrag ssl darf nur genau einmal in der Konfigurationsdatei aktiv sein! Da der Eintrag in der Konfigurationsdatei an mehreren Stellen verwendet wird, muss überprüft werden, ob nur ein Eintrag aktiv ist.

Die SSL-Verschlüsselung wird eingeschaltet und verwendet den ldaps-Port 636.

Nächster Konfigurationsschritt: Kapitel Wie wird die Sicherheit der SSL-Verbindung verschärft? (Kapitel: 14.10.5)

14.10.5 Wie wird die Sicherheit der SSL-Verbindung verschärft?

Auf dem APROL-Server (LDAP-Client) muss der Public-Key des Server-Zertifikats hinterlegt werden, um dem Client eine Authentifizierung des Server-Zertifikats zu ermöglichen.

Die Datei /etc/ldap.conf des Clients muss ebenfalls angepasst werden:

In der Kommandozeile scp root@<LDAP-Server>:/etc/ssl/certs/YaST-CA.pem /etc/ssl/certs/ldapca.pem

vi /etc/ldap.conf anpassen

14-79

tls_checkpeer yes

tls_cacertfile /etc/ssl/certs/ldapca.pem

tls_cacertdir /etc/ssl/certs


Der Eintrag tls_checkpeer darf nur genau einmal in der Konfigurationsdatei aktiv sein! Da der Eintrag in der Konfigurationsdatei an mehreren Stellen verwendet wird, muss überprüft werden, ob nur ein Eintrag aktiv ist.

Nächster Konfigurationsschritt: Kapitel Wie wird die LDAP-Authentifizierung für das Engineering-System im CaeManager konfiguriert? (Kapitel: 14.11.1)

14.10.6 Wann wird ein Zertifikat endgültig aktiviert? Bei einem Zertifikatswechsel ist ein Neustart des LDAP-Servers notwendig: /etc/init.d/ldap restart

14.11 Konfiguration der LDAP-Authentifizierung für das Engineering- und Runtime-System

APROL muss für die Kommunikation mit einem LDAP-Server entsprechend eingestellt werden. Nachfolgende Punkte sind hierbei zu betrachten:

Aktivierung in der Benutzer-Verwaltung (Engineering-Benutzer)

Aktivierung im OperatorManager (Operatoren)

Auf allen Engineering-Servern und Operator-Stationen, deren Benutzer bzw. Operatoren eine Authentifizierung über den LDAP-Server durchführen sollen, muss die LDAP-Client Konfiguration durchgeführt werden.

Detail-Informationen entnehmen Sie bitte dem Kapitel Anbindung von APROL mit openLDAP / Active Directory Server

(Kapitel: 14.9)

14-80

Der Distinguished Name eines Benutzers muss eindeutig sein. Da der DN eines Benutzers Vor- und Nachname enthält, muss daher das Wertepaar (Vorname, Nachname) eindeutig sein. Die Tupel Vorname, Nachname, sowie Login-Name müssen die Einträge in der APROL Benutzerverwaltung bzw. OperatorManager entsprechen.

14.11.1 Wie wird die LDAP-Authentifizierung für das Engineering-System im CaeManager konfiguriert?

Aktivierung für Engineering-Benutzer:

Abbildung 215: Konfiguration der LDAP-Authentifizierung für Engineering-Benutzer

Navigation:

CaeManager / Extras / Globale Engineering-Optionen

LDAP Authentifizierung aktiviert

Login-Stack aktiviert

LDAP-Server Eigenschaften

Abbildung 216: LDAP-Server Eigenschaften

Navigation: CaeManager / Extras / Globale Engineering-Optionen / LDAP-Server Eigenschaften



14-81



Nächster Konfigurationsschritt: Kapitel Wie wird die LDAP-Authentifizierung für das Runtime-System im CaeManager konfiguriert? (Kapitel: 14.11.2)

14.11.2 Wie wird die LDAP-Authentifizierung für das Runtime-System im CaeManager konfiguriert?

Aktivierung für Operatoren:

Abbildung 217: Konfiguration der Operator Authentifizierung

Navigation:

CaeManager / Projekteigenschaften / Runtime (1/2)

LDAP Authentifizierung aktiviert

Login-Stack aktiviert


LDAP-Server Eigenschaften

Abbildung 218: LDAP-Server Eigenschaften

Navigation: CaeManager Navigation:

CaeManager / Projekteigenschaften / Runtime (1/2) / LDAP-Server Eigenschaften




14-82

Mit [OK] bestätigen Grundsätzlich ist eine Web-Authentifizierung auch über den LDAP-Server möglich. Im Gegensatz zum LoginServer erfolgt kein Fallback auf die im APROL eingetragenen Operatoren, wenn ein Operator dem LDAP-Server nicht bekannt ist. Dieser Fallback wird nur durchgeführt, wenn der LDAP-Server nicht erreichbar oder die Konfiguration fehlerhaft ist. Somit können sich bei aktivierter LDAP-Authentifizierung ausschließlich die im LDAP-Server bekannten Operatoren via Web-Authentifizierung anmelden.

Eine Änderung des Passwortes im OperatorManager wird nur bei Download auf die Operator-Stationen wirksam werden.

Bei gestörter LDAP-Verbindung wird als Fallback mit lokaler APROL-Authentifizierung das Einloggen immer noch gewährleistet.

Nächster Konfigurationsschritt: Kapitel Wie wird für die lokale Authentifizierung die Komplexitäts-Überprüfung für Passwörter aktiviert? (Kapitel: 14.11.2.1)

14.11.2.1 Wie wird für die lokale Authentifizierung die Komplexitäts-Überprüfung für Passwörter aktiviert?

Bei der lokalen APROL-Authentifizierung kann die Komplexitäts-Überprüfung wie folgt aktiviert werden. Die Aktivierung der Option 'Erweiterte Überprüfung der Passwort-Sicherheit' bewirkt, dass in der Benutzermanagement / OperatorManager neu vergebene Passwörter mit der 'cracklib' auf ihre Sicherheit geprüft werden. Eine der Prüfungen, die dann durchgeführt werden, ist der Abgleich des Passworts mit einer Negativ-Liste. Diese Liste liegt im Klartext in die Datei /opt/aprol/share/cracklib/aprol_dict.txt und kann wie beschrieben angepasst werden. Das Erhöhen der Sicherheit ist nicht zwingend notwendig. um ein funktionierendes System zu gewährleisten.

Navigation:

CaeManager / Extras / Globale Engineering-Optionen

Erweiterte Überprüfung der Passwort-Sicherheit aktiviert

vi /opt/aprol/share/cracklib/aprol_dict.txt anpassen

AprolCreateCracklibDict Skript als root im Verzeichnis /opt/aprol/share/cracklib/ aufrufen


14-83

14.12 Passwortrichtlinien / Account-Richtlinien auf einem Active Directory Server?

Nachfolgend wird die Konfiguration von Account- bzw. Passwortrichtlinien exemplarisch (anhand eines Windows Server 2003) beschrieben.

14.12.1 Wie werden Passwortrichtlinien auf einem Active Directory Server konfiguriert?

Die im Folgenden beschriebenen Passwort- und Account-Richtlinien können am Active Directory Server und am openLDAP-Server konfiguriert werden. Die konfigurierten Richtlinien werden im APROL-System ausgewertet und entsprechend berücksichtigt.

Abbildung 219: Windows 2003 Server / Passwort-Richtlinien

Abbildung 220: Windows 2008 Server / Passwort-Richtlinien öffnen

14-84

Abbildung 221: Windows 2008 Server / Passwort-Richtlinien bearbeiten

Nächster Konfigurationsschritt: Kapitel Wie wird die maximale Anzahl der in der Historie gespeicherten Passwörter festgelegt? (Kapitel: 14.12.1.1)

14.12.1.1 Wie wird die maximale Anzahl der in der Historie gespeicherten Passwörter festgelegt?

Enforce password history Navigation:

Start / Administrative Tools / Domain Security Settings / Security Settings / Account Policies / Password Policy

Enforce password history 5


Zum Vergleich openLDAP-Server: Maximale Anzahl der in der History gespeicherten Passwörter

Attribut der Passwortrichtlinie: pwdInHistory

In der Konfiguration der Passwortänderungsrichtlinien kann die maximale Anzahl der in der History gespeicherten Passworte angegeben werden. Somit kann beispielsweise definiert werden, dass das neue Passwort nicht einem der z.B. letzten 5 Passworte gleichen darf.

Im APROL-System kommt es zu einer Fehlermeldung, wenn eine Passwort-Regel bei der Passwortneuvergabe nicht eingehalten wurde.

Nächster Konfigurationsschritt: Kapitel Wie wird das Höchstalter eines Passwortes festgelegt? (Kapitel: 14.12.1.2)

14.12.1.2 Wie wird das Höchstalter eines Passwortes festgelegt? Maximum password age

14-85

Navigation:


Maximum password age 30


Zum Vergleich openLDAP-Server: Höchstalter des Passworts

Attribut der Passwortrichtlinie: pwdMaxAge (Einheit: [s])

Hier können Sie den Passwortablauf konfigurieren. Diese Sicherheitseinstellung legt den Zeitraum fest, in dem das Passwort verwendet werden kann, bevor der Benutzer aufgefordert wird, das Passwort zu ändern.

Bei entsprechender Konfiguration wird im APROL-System bei Passwortablauf ein Neusetzen des Passwortes ermöglicht.

Nächster Konfigurationsschritt: Kapitel Wie wird die minimale Länge eines Passwortes festgelegt? (Kapitel: 14.12.1.3)

14.12.1.3 Wie wird die minimale Länge eines Passwortes festgelegt? Minimum password length Navigation:


Minimum password length 8


Zum Vergleich openLDAP-Server: Mindestlänge des Passworts

Attribut der Passwortrichtlinie: pwdMinLength

Diese Sicherheitseinstellung legt die Mindestanzahl von Zeichen fest, die ein Passwort für ein Benutzer-Accout enthalten muss.


Nächster Konfigurationsschritt: Kapitel Wie wird die Komplexitäts-Überprüfung für neue Passwörter aktiviert? (Kapitel: 14.12.1.4)

14-86

14.12.1.4 Wie wird die Komplexitäts-Überprüfung für neue Passwörter aktiviert?

Password must meet complexity requirements Navigation:


Password must meet complexity requirements Enabled

Mit [OK] bestätigen Diese Prüfungen können nur in Ihrem Gesamtheit aktiviert oder deaktiviert werden. Durch einen Windows 2003 Server werden folgende Komplexitätsprüfungen durchgeführt: Das Passwort muss Komplexitätsanforderungen entsprechen Diese Sicherheitseinstellung bestimmt, ob Passwörter Komplexitätsanforderungen entsprechen müssen. Falls diese Richtlinie aktiviert wurde, müssen Passwörter den folgenden Mindestanforderungen entsprechen. Der Account-Name des Benutzers darf nicht enthalten sein, oder Teile des Account-Namens, die als mehr als zwei aufeinender folgenden Zeichen bestehen. Mindestlänge: 6 Zeichen Es müssen Zeichen aus mindestens drei der folgenden Kategorien enthalten sein: Englische Großbuchstaben (A bis Z) Englische Kleinbuchstaben (a bis z) Base 10 Zeichen (0 bis 9) Nichtalphabetische Zeichen (z. B. !, $, #, %) Komplexitätsanforderungen werden erzwungen, wenn Passwörter geändert oder vergeben werden.

Standardmäßig entsprechen die Einstellungen der zu einer Domäne zugewiesenen Computer den Einstellungen des Domain Controllers.

14-87

Zum Vergleich openLDAP-Server: Nur überprüfte Passwörter akzeptieren Attribut der Passwortrichtlinie: pwdCheckQuality Hier sind 3 Einstellungen möglich: Falls der Wert dieses Parameters '0' ist, (Default) werden keine Richtlinienüberprüfungen durchgeführt. Ist der Wert dieses Parameters '1' und das gelieferte Passwort ist im Klartext, dann wird eine von Benutzer bereitgestellte Funktion (definiert mit dem Attribut pwdCheckModule) - falls definiert - aufgerufen um die Passwortqualität zu überprüfen. Ist diese Funktion nicht verfügbar, wird das Passwort akzeptiert werden (vorausgesetzt alle weiteren Überprüfungen, die in den unterschiedlichen pwdPolicy Attributen definiert wurden, sind erfüllt). Ist der Wert '2' und das gelieferte Passwort ist im Klartext, dann wird eine von Benutzer bereitgestellte Funktion aufgerufen um die Passwortqualität zu überprüfen. Ist diese Funktion nicht verfügbar, wird das Passwort zurückgewiesen. Wenn kein von Benutzer bereitgestelltes Modul vorhanden ist, kann das Attribut pwdCheckQuality mit Sicherheit ausgelassen werden.

Die Einstellung schaltet die Passwort-Komplexitäts-Überprüfung ein. Informationen zu den durchgeführten Überprüfungen können der Hilfe des Windows Servers entnommen werden.


Nächster Konfigurationsschritt: Kapitel Wie wird die maximale Anzahl der Falsch-Anmeldungen konfiguriert? (Kapitel: 14.12.1.5)

14.12.1.5 Wie wird die maximale Anzahl der Falsch-Anmeldungen konfiguriert?

Account lockout threshold

14-88

Abbildung 222: Account Lockout Policy, Windows Server 2003

Navigation:

Start / Administrative Tools / Domain Security Settings / Security Settings / Account Policies / Account Lockout Policy

Account lockout threshold 3


Abbildung 223: Account Lockout Policy, Windows Server 2008 (zum Vergleich)

Zum Vergleich openLDAP-Server: Anzahl der Bind-Fehler vor Passwortsperrung

Attribut der Passwortrichtlinie: pwdMaxFailure

Diese Einstellung legt fest, ob und wann eine Sperrung eines Accounts durch Anmelderfehlversuche erfolgen soll. Mit Zusatzoptionen kann gegebenenfalls noch die Dauer der Sperrung verändert werden. Die Zahl '0' schaltet die Prüfung aus. Im APROL-System erfolgt bei einem gesperrten Account kein Login und es wird ein entsprechender Hinweis angezeigt.

14-89

Nächster Konfigurationsschritt: Kapitel Wie wird einen APROL-Server an einen Active Directory-Server angebunden? (Kapitel: 14.9.4)

14.12.1.6 Wie wird ein gesperrter Benutzer-Account im Active Directory Server frei gegeben?

Freigabe eines gesperrten Accounts im Active Directory Server:

Abbildung 224: Account is locked out deaktivieren, Windows Server 2003

Navigation:

Start / Administrative Tools / Active Directory Users and Computers

/ <Datenbank> / Users / <User wählen> / Properties / Account

Account is locked out deaktiviert


15 Anhang .

15.1 Änderungshistorie

Versions-Nr. des Handbuchs

Datum Änderung Autor / Geprüft von

4.06 30.04.2014 Kapitel Digitale Signatur von PDF-Dokumenten: Signieren beliebiger PDF-Dokumente Aktualisierung des Kapitels IEC zu SQL Datentyp-Mapping Kapitel APROL-SQL: Hinweise zum ARKPATH

KSc CKo, GWa, RS

30.04.2014 Kapitel Vordefinierte SQL-Tabellen aktualisiert

RN

4.05 01.04.2014 Kapitel Vordefinierte SQL-Tabellen aktualisiert

KSc

4.04 12.03.2014 Korrekturen im Kapitel APROL-SQL

KSc GW

11.03.2014 Korrekturen in den Kapiteln Offline-Engineering / Lösung und Einführung zum Offline-Engineering

KSc RM

4.03 05.03.2014 Kapitel Vordefinierte SQL-Tabellen aktualisiert

RN

27.02.2014 Neues Kapitel IosHttp KSc SO, CKo

25.02.2014 Korrekturen im Kapitel APROL-SQL

RN DB RS

4.02 13.02.2014 Neues Kapitel IosDiagnosticManager

KSc JRu, OK

27.01.2014 Kapitel Vordefinierte SQL-Tabellen aktualisiert

RN

4.01 13.12.2013 Überarbeitung des Kapitels Authentifizierung und Autorisierung. Hinweise zur SQL-Authentifizierung

RN

09.12.2013 Format auf DIN A4 RN 4.00 04.12.2013 Überarbeitung Kapitel AprolCmd RN

15-2



21.11.2013 Neues Kapitel Übertragung der APROL Benutzerdaten in den LDAP-Server

KSc

13.11.2013 Überarbeitung / Neustrukturierung des Kapitels AprolSql

RSc

07.11.2013 Überarbeitungn des Kapitels Lizenzierung der Loquendo TTS7 Software zur Sprachausgabe von Alarmen

KSc

09.10.2013 Überarbeitung des Kapitels AprolSqlServer

KSc / RSc

17.09.2013 Erweiterung Kapitel IosDiagnosticManager

RN

21.08.2013 Überarbeitung des Kapitels Wie wird die LDAP-Authentifizierung für das Runtime-System im CaeManager konfiguriert?

KSc ELa, JR

15.08.2013 Kapitel AprolSqlServer Korrektur 'TIMESTAMP', Bildverweise, Formatierung, Terminologie, Screenshots Hinweis auf Typ 3 und Typ 4 Treiber Kapitel Verfügbare SQL-Tabellen Neue SQL-Tabellen

RN DB RS

10.07.2013 Neues Kapitel AprolSqlServer KSc 24.06.2013 Kapitel IosEv:

Neue Option '-autoStop' KSc MM

15.05.2013 Überarbeitung des Kapitels Iosys-Tools

KSc DD RK

25.03.2013 Aktualisierung der Screenshots KSc 01.03.2013 Erweiterung des Kapitels

Alarmdatenabhängige Darstellung (data)

KSc

14.02.2013 Neues Kapitel Systemvariablen ApcHwInfo

KSc MHa, MHe

18.09.2012 Kapitel Konfiguration der Report-Erstellung mit dem Baustein AprCcTrigReport Änderung der TrendReport URL

RN

11.09.2012 Erweiterung des Kapitels Arbeiten im Offline-Engineering und beenden

KSc MM

15-3



07.05.2012 Korrekturen im Kapitel Arbeiten mit dem Werkzeug fcitx

KSc MWe

25.04.2012 Erweiterung des Kapitels pio KSc CKo

06.12.2011 Kapitel Wie wird ein APROL-Server an einen openLDAP-Server mit YaST angebunden? und Kapitel Wie werden weitere Passwortrichtlinien auf einem openLDAP-Server mit dem YaST angelegt?: Screenshot aktualisiert

KSc

23.11.2011 Kapitel Wie wird die LDAP-Authentifizierung für das Runtime-System im CaeManager konfiguriert?: Screenshot aktualisiert Erweiterung im Kapitel: Wie werden weitere Passwortrichtlinien auf einem openLDAP-Server mit dem YaST angelegt?

KSc

10.11.2011 Korrektur im Kapitel Übersicht zu den Request- und Response-Typen

KSc SO

10.11.2011 Überarbeitung des Kapitels Digitale Signatur von PDF-Dokumenten

KSc MRo, CK, SO

04.11.2011 Korrektur Kapitel Wie wird die Sicherheit der SSL-Verbindung verschärft? Neues Kapitel Wann wird ein Zertifikat endgültig aktiviert?

KSc AW

02.11.2011 Neues Kapitel Digitale Signatur von PDF-Dokumenten

KSc SO

3.09 07.10.2011 Neues Kapitel 'Iosys-Kopplung' KSc 09.09.2011 Erweiterung des Kapitels

Authentifizierung via LDAP / Active Directory-Server

KSc

3.08 29.07.2011 Erweiterung des Kapitels Authentifizierung via LDAP / Active Directory-Server

KSc AWo

3.07 16.06.2011 Hinweis Kapitel TranslationManager

RN

17.05.2011 Korrektur Kapitel Authentifizierung via LDAP / Active Directory-Server

RN, JH

15-4



15.04.2011 Korrektur Kapitel Wie wird das PAM-Kerberos-Modul für die Anbindung an einen Active Directory-Server konfiguriert?

RN CK

3.06 07.04.2011 Neues Kapitel Authentifizierung via LDAP

MWe, RN BSc, MT, TK

21.02.2011 Kapitel Systemvariablen, Einheit MByte und Dataentyp LREAL

RN IS

3.05 02.11.2010 Kapitel Die Web-Schnittstelle des Iosys: Abkündigung der Anwendung

KSc

09.09.2010 Korrektur im Kapitel Erweiterungen der Alarm-Layout-Konfiguration

KSc

3.04 12.08.2010 Begriffsbereinigung: ST, SFC, CFC RN 3.03 28.06.2010 Aktualisierung des Kapitels

Lizenzierung der Loquendo TTS 7 Software zur Sprachausgabe von Alarmen.

KSc SO

3.02 25.01.2010 Neues Kapitel Lizenzierung der Loquendo TTS 7 Software zur Sprachausgabe von Alarmen

KSc SO, MT, HSc

26.04.2010 Änderungen im Kapitel Systemvariablen für Speicher und Festplattenkapazität

RN

14.12.2009 Überarbeitung des Kapitels Erstellung kundenspezifischer Reports

KSc CKo

3.01 01.12.2009 Option '-alarmRepack' im Kapitel Neue Funktionalitäten in den APROL-Releases

RN SO

18.11.2009 Offline-Engineering mit Projekt-spezifischer Datenreduktion

KSc JR, MWe

02.11.2009 Aktualisierung des Kapitels Alarm-System

RN, KSc SO, AT

29.10.2009 Aktualisierung des Kapitels Vorbereitung für Offline-Engineering und Auschecken

RN, KSc SO

2.06 25.05.2009 Aktualisierung des Kapitels OPC-Server

RN JR, BS, MSc

2.05 23.01.2009 Systemvariablen zur Lizenzierung KSc 2.04 26.01.2009 Systemvariablen zum Speicher-

Management KSc

15-5



07.01.2009 Hinweis zur Syntax der Systemvariablen zur Überwachung der CC-Task

KSc IS

2.03 08.10.2008 Aktualisierung des Kapitels Verwendung des Datentyps LSTRING

KSc ELa

2.02 12.08.08 Überarbeitung des Kapitels Verwendung des Datentyps LSTRING

KSc ELa, WS

2.01 17.07.2008 Kapitel TranslationManager neu erstellt

MSa MSc, MW

2.00 02.07.2008 Aktualisierung des Kapitels Konfiguration des AlarmMonitors via XML

MSa

25.06.2008 Überarbeitung des Kapitels Systemvariablen

KSc

22.04.2008 Kapitel UTF8 STRING API um Beschreibung zum Datentyp LSTRING erweitert

KSc WS

11.03.2008 Erweiterung des Kapitels Systemvariablen

KSc WS

18.01.2008 Aktualisierung des Kapitels Konfiguration des AlarmMonitors via XML

MSa DM

Dateiname dieser Dokumentation: APROL_R40_D1_SystemManual_049.pdf

15-6

15.2 Dokument-Information Dokument-Version: ManVersion 4.06 Dokument-Datum: ManDatum 30.04.2014

16 Glossar .

$HOME

Allgemein Bezeichnung für ein home-Verzeichnis. Im Prompt in einem X-Term auch mit dem Sonderzeichen "~" dargestellt. Diese Bezeichnung wird auch oft für die Environment-Variable, die in Skripten als Inhalt die Pfadangabe des home-Verzeichnisses trägt, benutzt.

Anwendung

Ein Programm

AWS

AWS ist die Abkürzung für Anwenderspeicher. Er wird für die Speicherung der Anwenderprogramme auf dem Controller benötigt.

CPU

Zentraleinheit des Controllers.

Data Access Server

Data Access Server können einfache Programme sein, die z. B. den Zugriff auf die Register eines Controllers zur Verfügung stellen. Es sind aber auch komplexe Programme möglich, die den Zugriff auf eine Vielzahl von Variablen in einer großen Anzahl von Geräten über über umfangreiche Kommunikationsmechanismen ermöglichen. Der Data Access Server ermöglicht einem oder mehreren Data Access Clients den transparenten Zugriff auf verschiedenste Datenquellen. Data Access Clients können sehr simpel sein (z. B. Excel-Sheets) oder aber sehr umfangreich und wiederum Bestandteil größerer (z. B. SCADA-) Systeme sein.

DDE

Abkürzung für Dynamic Data Exchange. DDE beschreibt einen Mechanismus zum Austausch von Daten zwischen Windows-Anwendungen. Wurden Daten vor der Einführung von DDE durch "Copy & Paste" ausgetauscht, erfolgt bei DDE der Datenaustausch dynamisch. Die zu übertragende Information wird auf ein Item mit beliebigem Datentyp abgebildet. Der Datenaustausch erfolgte jedoch relativ langsam.

Benutzer

Unter dem Begriff Benutzer sind alle die Personen zusammengefasst, die in einem Team an der Projektierung, Konfiguration und Programmierung eines oder mehrerer Prozessleitsysteme arbeiten. Es können Ingenieure, Serviceingenieure und auch Systemadministratoren sein.

File

File ist ein weiteres Synonym für Datei.

16-2

Forcen

Dieser Begriff kommt aus dem Englischen und bedeutet: "mit Kraft aufdrücken". In Bereich der Prozessleittechnik wird einer PV auf einem Controller ein Wert von anderer Stelle (aussen) vorgeschrieben (aufgedrückt). Diese Vorgehensweise wird beim Debugging benutzt.

HMI-Interface

Realisierung der Bedienung und Anzeige des Prozesses für den Menschen.

Kommandoshell

Eine Art der Eingabe für Programme. Ein Programm wird gestartet und erwartet Eingaben über die Tastatur. Entsprechend der Eingaben werden dann Informationen vom Programm ausgegeben.

Ländercode

Ländercode ist die Bezeichnung der Sprache mit Nummern (Meistens die internationale Telefonvorwahl). Beispiele: 001=englisch(amerikanisch), 007=russisch, 031=holländisch, 033=französisch, 048=polnisch, 049=deutsch

Levenshtein

Die Levenshtein-Distanz (auch Edit-Distanz oder Editierdistanz) bezeichnet in der Informationstheorie ein Maß für den Unterschied zwischen zwei Zeichenketten bezüglich der minimalen Anzahl der Operationen Einfügen, Löschen und Ersetzen, um den eine Zeichenkette in die andere zu überführen. Benannt ist die Distanz nach dem russischen Wissenschaftler Wladimir Lewenstein, der sie 1965 einführte. Um beispielsweise von "Tier" zu "Tor" zu kommen ist eine Ersetzung und eine Löschung notwendig, die Levenshtein-Distanz beträgt also 2: Tier -->Toer (Ersetze i durch o) --> Tor (Lösche e) In der Praxis wird die Levenshtein-Distanz zur Bestimmung der Ähnlichkeit von Zeichenketten beispielsweise zur Rechtschreibkorrektur oder bei der Duplikaterkennung angewandt.

LGPL

Die GNU Lesser General Public License, kurz LGPL, ist neben GPL und GFDL eine weitere freie Lizenz der Free Software Foundation. Die LGPL wurde hauptsächlich für Programmbibliotheken geschaffen, wie der alte Name, Library General Public License, bereits andeutet. Die Bestimmungen sind sehr ähnlich der GPL, allerdings dürfen auch proprietäre Programmteile gegen eine, unter der LGPL stehende, Bibliothek gelinkt werden.

OLE

Abkürzung für Object Linking and Embedding. Der Begriff steht für das dynamische Verknüpfen von Objekten in unterschiedlichen Office-Anwendungen.

16-3

OPC

OLE for Process Control

Projektierungsteil

Ein Projektierungsteil ist eine Teil des Prozessleitsystem-Engineerings, dass bearbeitet werden kann. Beispiele: Funktionsschaltplan, Control Computer, Controller usw.

SCADA-System

Abkürzung für "Supervisory control and data aquisition system".

SV

Abkürzung für Systemvariable.

Vset

Ein Element der Datenbanken von APROL (caedb, runtimedb usw.). Ein Vset ist ein benannter assoziativer Container für Name = Wert Paare.

Vsets

Siehe Vset.

APROL R 4.0 D1 System Handbuch - B&R Industrial Automation

Documents