Schema der Konfigurationsdatei

Unter "Einführung in die Konfigurationsdatei" können Sie nachlesen wo Sie die Konfigurationsdatei finden und anlegen können. Die Regeln wie eine Konfigurationsdatei aufgebaut ist können Sie in der Microsoft-Dokumentation nachlesen.

iPlus bietet Ihnen einige spezielle Konfigurationselemente an:

• Der grundsätzliche Aufbau gibt vor dass der Abschnitt <configSections> existiert in dem zuerst die Deklaration erfolgen muss.
• Eine Deklaration besteht aus den Unterlementen <sectionGroup> und <section>.
• Im Unterlement <section> werden die iPlus-Konfigurationsklassen dem XML-Parser bekanntgegeben.
• Den Namen den Sie im Attribut "name" in den <sectionGroup> und <section> vergeben, müssen Sie in weiteren Verlauf der Datei als XML-Element verwenden.

Wie dies geschieht, sehen Sie in den folgenden Beispielen.

Entity-Framework Optionen

Mit der Konfigurations-Klasse gip.core.datamodel.EFConfiguration können Sie das Verhalten des Entity-Frameworks anpassen. Folgende Parameter stehen zur Verfügung:

CommandTimeout: Maximale Zeit in Sekunden für Abfragen und Speichervorgänge im Entity-Framework. Weitere Informationen finden Sie unter https://msdn.microsoft.com/en-us/library/system.data.objects.objectcontext.commandtimeout(v=vs.110).aspx. Der Standardwert liegt bei 30 Sekunden.

 

Kernverhalten der iPlus-Runtime

Mit der Konfigurations-Klasse gip.core.autocomponent.CoreConfiguration können Sie das Kernverhalten des iPlus-Frameworks anpassen. Folgende Parameter stehen zur Verfügung:

DefaultPrecision: Grundsätzlich erfolgt das Weiterleiten von Variablenänderungen ereignisbasiert. Damit bei Gleitkomma-Werten nicht ständig unnötiger Broadcastverkehr entsteht, wenn sich in den hinteren Kommastellen der Wert ändert, kann die Nachkommastellenanzahl definiert werden. Mit der Default-Precision verändert sich nicht der eigentliche Wert sondern es erfolgt nur eine temporäre Rundung in der Vergleichsfunktion.

 

UseSimpleMonitor, ValidateLockHierarchies

iPlus ist ein sehr stark auf Multithreading ausgelegtes System (lesen Sie Kapitel Multihreading). Somit müssen viele Programmstellen für einen zeitgleichen Zugriff ("critical sections") gesichert sein. Gleichzeitig steigt damit aber auch das Risiko von Deadlocks. Deadlocks sind dann immer sehr problematisch wenn sich ein System im Produktivbetrieb befindet. Obwohl vor der Auslieferung zum Kunden das System wohl getestet wurde kann es unter realen Bedingungen zu Problemen kommen. Um das zu verhindern ist in iPlus das Prinzip von Lock-Hierarchien implementiert.

Basis dafür ist gip.core.datamodel.ACMonitor. Die ACMonitor-Klasse ist eine Erweiterung der .NET Monitor-Klasse und sollte grundsätzlich für alle Sperren verwendet werden. Die ACMonitor-Klasse bietet folgende Vorteile gegenüber der Klassischen Monitor-Klasse:

• Sie überwacht die Einhaltung der Deadlock-Hierarchie. Sobald die Aufrufreihenfolge einen Deadlock provozieren kann wird hier eine Exception geworfen. Die Fehlermeldung ist zusätzlich im Logfile hinterlegt. Die Überwachung der Lock-Hierarchien aktivieren Sie mit dem Schalter "ValidateLockHierarchies".
• Im Falle eines Deadlocks wird der gesamte Aufrufstapel der beiden verklemmten Threads im Logfile ausgegeben und die Sperre aufgelöst. So kann es während des Produktivbetriebs zu keinem Programmstillstand kommen. Jedoch kann sich das Programm in einem inkosistenten bzw. unterwünschten Zustand befinden (UseSimpleMonitor=false).

Da die ACMonitor-Klasse wesentlich mehr CPU-und RAM-Resourcen in Anspruch nimmt, kann nach einer gewissen Testphase sobald sich das System als stabil erweist und keine Deadlockmeldungen aufgetreten sind (z.B. nach 1-2 Monaten) die Funktion der ACMonitor-Klasse abgeschaltet werden. Dafür setzen Sie die Eigenschaft "UseSimpleMonitor" auf true. Dies ist auch der Default-Wert.

 

Kernverhalten der Prozessautomatisierung

Mit der Konfigurations-Klasse gip.mes.processapplication.ProcessConfiguration können Sie das Verhalten der Prozessautomatisierungskomponenten beeinflussen:

DeactivateProcessConverter: Prozessfunktionen wie Mischen, Temperieren, Dosieren, besitzen einen Zustandsautomaten entsprechend der ISA-S88 Spezifikation. Da die eigentliche Prozessausführung per SPS-Steuerungen abgewickelt wird, kommunizieren die Prozessfunktionen mittels Konverter mit der SPS. Technisch ist es jedoch möglich, dass auf unterschiedlichen Rechnern iPlus-Anwendungen laufen, die mit der selben SPS kommunizieren (z.B. jeder Rechner hat eine Kopie der iPlus-Datenbank mit den selben Anwendungen und SPS-Verbindungen). Dies hätte zur Folge dass auch beide Rechner auf die Zustandsänderungen in der SPS reagieren was zu gefährlichen Seiteneffekten führen könnte. Wird diese Konfigurationseigenschaft auf true gesetzt, ist die Konverterlogik ausgehebelt und es erfolgt keine Reaktion auf Zustandsänderungen mehr. Diese Funktionalität ist besonders dann wichtig wenn es mehrere Inbetriebnehmer gibt, die unabhängig voneinander eine eigene iPlus-Service-Instanz laufen lassen wollen.

 

Konfiguration zur Protokollierung von Fehlern und Daten

iPlus bietet Ihnen drei Arten von Protokolliermöglichkeiten für diagnostische und analytische Zwecke:

1. Protokollierung von Fehlern, Ausnahmen, Traceausgaben
2. Langzeitspeicherung von Prozessvariablen/Eigenschaften
3. Performancemessungen

zu 1.) Protokollierung von Fehlern, Ausnahmen, Traceausgaben:

 Dafür benötigen Sie die Konfigurationsklassen aus dem Namespace "gip.core.autocomponent"

• LoggingConfiguration <LoginConfiguration>
• LogFileElement <addLogfile> + LogFileCollection <LogFiles>
• LoggingTypeElement <addLoggingType>  + LoggingTypeCollection <LoggingTypes>

 Beispiel:

 

Mit dem Element <addLoggingType> definieren Sie einen Dateitypen bzw. Filterregeln, der angibt welche Nachrichtentypen und von welchen Automation-Components in eine Datei geschrieben werden sollen. Auf diesen Dateityp verweisen Sie dann im Element <addLogFile> über das Attribut "FileType". Mit <addLogFile> definieren Sie die Logdatei, die geschrieben werden soll.

Attribute/Eigenschaften von <addLoggingType> :

• FileType: Ein frei vergebbarer Namen über den in <addLogFile> referenziert wird.
• MessageType: Gibt an welcher Nachrichtentyp geloggt werden soll. Dabei sind folgende Werte möglich die im Enumerator gip.core.datamodel.eMsgLevel definiert sind: Default, Debug, Info, Warning, Failure, Error, Exception, Command, Status, Statusdetail, Question. Wird Default angegeben, dann werden alle Nachrichtentypen geloggt.
• Source: Hier wird die ACUrl einer Komponente angegeben, die speziell geloggt werden soll. Wird Default angegeben, so werden die Nachrichten von allen Komponenten ausgegeben.

Attribute/Eigenschaften von <addLogFile> :

• FileType: Gibt an welche Dateityp bzw. welche Filterregel verwendet werden soll.
• FileName: Formatierungsbefehl für den zu erzeugenden Dateinamen. Für den Platzhalter %Date% wird der aktuelle Zeitstempel eingetragen, für den Platzhalter %ProcessId% für die aktuelle Prozessid eingetragen. Logfiles werde ausschliesslich in das temporäre Benutzerverzeichnis geschrieben (%userprofile%\AppData\Local\Temp). Ein anderer Pfad kann nicht angegeben werden. 
• MaxSizeMB: Maximal Logfilegröße in MB. Wird die Dateigröße überschritten, wird eine neue Datei erzeugt und der Zähler erhöht. Der Zähler wird immer am Ende vor der Dateinamenerweiterung gesetzt z.b. ...3.txt.
• ArchiveAfterDays: Nach diesem eingestellten Zeitraum werden alte Logfiles automatisch gezippt. Wird 0 angegeben, erfolgt keine Archivierung.

zu 2.) Langzeitspeicherung von Prozessvariablen/Eigenschaften

Die Einstellung welche Variable protkolliert werden soll, erfolgt in der iPlus-Entwicklungsumgebung in der Eigenschaftskarteikarte. Für jede Variable wird monatlich ein eigenes Datenbankfile erzeugt (https://en.wikipedia.org/wiki/Extensible_Storage_Engine). Löschung alter Archive erfolgt nach drei Monaten automatisch. Möchte man diese Default-Eintstellung verlängern, muss die Eigenschaft DeletePropLogAfterXMonths in der Klasse LoggingConfiguration definiert und der Wert in Monaten angegeben werden. 

Einstellungen für Performancemessungen

Programmierer können im Quellcode die Klasse gip.core.datamodel.PerformanceLogger verwenden um Zeitmessungen für Funktionsaufrufe oder Codeabschnitte durchzuführen. Um den PerformanceLogger zu aktivieren, müssen Sie die Konfigurationsklasse gip.core.datamodel.PerfLogConfiguration verwenden:

 

Lesen Sie im Kapitel Performancemessungen nach wie man die Messungen in eine Datei schreibt.