Funktionsweise und Philosophie des Laufzeitsystems

Das Herzstück von iPlus-framework ist ein objektorientiertes, komponentenbasiertes Framework, das auf dem .NET-Framework von Microsoft® aufsetzt. Es ist vollständig serviceorientiert aufgebaut. Das bedeutet, dass alle Klassen bzw. Komponenten nur per Konfiguration in der Datenbank zum Leben erweckt werden. Alle Instanzen können netzwerktransparent miteinander kommunizieren. Auch die Programmierung der Komponenten erfolgt netzwerktransparent. Somit ergibt sich eine grenzenlose Skalierbarkeit des Systems und es können Multitier-Architekturen per Mausklick aufgebaut werden. Das System arbeitet zudem völlig ereignisgesteuert, um eine fast echtzeitnahe Prozessabarbeitung und Visualisierung zu ermöglichen.

Aufgrund der serviceorientierten Architektur, können verschiedene Hersteller Ihre eigenen Lösungen entwickeln, die später gemeinsam auf einem Zielsystem laufen, ohne dass eine Kompilierung zu einem Gesamtsystem notwendig ist. Es ist vergleichbar mit einem herkömmlichen Paketverwaltungssystem wie z.b. nuget jedoch mit den wesentlichen Unterschieden, dass

• die Softwarekomponenten nicht durch eine Endkompilierung zusammen verbunden werden müssen,
• dass ein Softwarepaket auch nur deklarativ sein kann (keine .NET-Assemblies, sondern nur Projektkonfigurationsdateien und GUI-Beschreibungen XAML),
• die Pakete während der Laufzeit (z.B. in einem Produktivsystem) hinzugefügt werden können.

Daraus ergeben sich folgende Vorteile:

• Es können unterschiedliche Parteien (Projekteure, Berater, Entwickler, Teams) unabhängig voneinander an einer Gesamtlösung arbeiten.
• Die Erweiterung der Gesamtlösung kann für zeitkritische Systeme zum Teil sogar während des Produktivbetriebs stattfinden. Wenn dann ein geeignetes Zeitfenster zur Verfügung steht, können die iPlus-Dienste bereits mit der fertig konfigurierten Einstellung neu gestartet werden.
• Integriertes Change-Request-Management: Projektierungen die auf Testsystemen erstellt wurden (lokaler Rechner, gemeinsames Testsystem...), können per Export-/Import auf das Produktivsystem übertragen werden.

Erklärung und Einordnung von IPlus anhand der Softwareschichten und .NET-Assemblies

iPlus ist mit Visual-Studio entwickelt und setzt auf dem .NET-Framework 4.8 auf:

iPlus-framework kann entweder eigenständig oder mit MES-Funktionalitäten genutzt bzw. lizenziert werden. Für die egenständige Nutzung von iPlus werden als Mindestkonfiguration die Assemblies 1,2,3,5  benötigt (optionale 4). Für die MES-Funktionalität werden zusätzlich Assemblies vom Typ 5,6,7 (optional 4) benötigt.

Konkret sind das für

iPlus:

gip.core.datamodel
gip.core.autocomponent
gip.core.layoutengine
gip.core.dbsyncer
gip.core.ControlScriptSync
gip.core.manager
gip.core.processapplication
gip.core.reporthandler
gip.core.archiver
gip.core.communication
gip.core.visualcontrols
gip.bso.iplus
gip.mes.client
gip.iplus.console
gip.iplus.service
gip.iplus.startup
gip.tool.installerAndUpdater
gip.ext.chart
gip.ext.design
gip.ext.designer
gip.ext.editor
gip.ext.essentcollections
gip.ext.essentinterop
gip.ext.fluent
gip.ext.graphics
gip.ext.modbus
gip.ext.opctoolbox
gip.ext.widgets
gip.ext.xamldom
gip.core.scichart
gip.bso.twincat3
gip.bso.tcStudio
gip.core.tcAgent
gip.core.tcClient
gip.core.tcShared

Zusätzlich für iplus-MES:

gip.mes.datamodel
gip.mes.autocomponent
gip.mes.manager
gip.mes.facility
gip.mes.maintenance
gip.mes.processapplication
gip.mes.archiver
gip.bso.facility
gip.bso.licence
gip.bso.logistics
gip.bso.manufacturing
gip.bso.masterdata
gip.bso.purchasing
gip.bso.sales
gip.core.processfacility
gip2006.core.processapplication
tcat.variobatch.processapplication

Alle Assemblies werden dynamisch vom iPlus-Framework geladen und die Instanzieerung der Klassen und Komponenten, die auf dem iPlus-Framework basieren, erfolgt überwiegend per Reflektion. Damit das funktioniert müssen diese Assemblies einem bestimmten Namensschema entsprechen (siehe Asteriske Bild oben). Das beduetet, wenn Sie eine eigene Assembliy bauen wollen, die auf dem iPlus-Framework aufsetzt müssen Sie sich der Namenskonvention anpassen. Dabei gelten folgende Regeln:

Teil 1 des Dateinamens entspricht Ihrem Firmennamen.

Teil 2 des Dateinamens informiert über die Einordnung der Abstraktionsebene

• "core" = Kernkomponente, Abstraktionsebene 0
• "mes" = Kernkomponente für MES, Abstraktionsebene 1
• "bso" = enhält Businessobjekte, Abstraktionsebene 2
• "solution" = enthält Komponenten für kundenspezifische Lösungen, Abstraktionsebene 3

Teil 3 des Dateibnamens ist frei vergebbar. Benutzen Sie einen Namen, der möglichst prägnant ist.

Die gip.core.datamodel.dll-Assembly (1)

Die gip.core.datamodel.dll-Assembly setzt auf dem Entity-Framework auf um Zugriffe auf die Datenbank ausführen zu können. In der Datenbank werden

• die Metadaten sämtlicher Klassen/Komponenten (Eigenschaften, Methoden, Designs,...)
• die Projektkonfiguration der Kundenlösung (Instanzen, Hierarchien, Beziehungen, ...)
• Benutzer, Gruppen, Rechte, Sprachen, Alarme, Logs...

gespeichert.

Per Hilfsklassen/Methoden können diese Informationen abgefragt und verändert werden. Die gip.core.datamodel ist vergleichbar mit dem Typ- und Reflection-System von .NET, jedoch mit dem Unterschied dass dies mittels Datenbank geschieht. Dies ist notwendig, damit man mittels der iPlus-Entwicklungsumgebung objektorientiert programmieren kann ohne neue .NET-Typen oder Assemblies erstellen zu müssen.

Weitere Aufgaben der gip.core.datamodel sind:

• Eine Abtraktionsbasis zu definieren, damit die Präsentation und Objektmodelle völlig unabhängig voneinander sind. Die Schnittstellen und abstrakten Klassen die hier definiert sind werden in der gip.core.layoutengine (Präsentationsschicht / View) und der gip.core.autocomponent (Modell und Logik) implementiert.
• Serialisierungs- und Deserialisierungsmechanismen bereitzustellen
• Generierung und Persisistierung von dynamischen LINQ und/oder EntitySQL-Expressions
• Multithreading-Hilfsmittel (Delegate-Queues, Locks, Deadlockhierarchien zur präventiven Deadlockvermeidung)
• Instanziierung, Caching, Pooling und Garbagecollection von Automation-Components
• Lizenzierungshilfsmittel

Die gip.core.autocomponent-Assembly (2)

Die gip.core.autocomponent-Assembly implementiert die abstrakten Definitionen aus der gip.core.datamodel. Sie ist die Basis-Assembly auf der alle weiteren Assemblies aufbauen welche Modellklassen enthalten (keine Präsentation). Der Name "autocomponent" ist eine Abkürzung für "Automation-Component" welche die Basisklasse für alle Klassen ist, die später durch die iPlus-Runtime instanziiert und verwaltet werden.

Die Basisklasse "ACComponent" übernimmt folgende Aufgaben:

• Lebenszyklus-Management für die Initialisierungs- und Deinitialisierungsphasen, iPlus-GarbageCollector und das Pooling
• Netzwerktransparente Kommunikation für synchrone und asynchrone Methodenaufrufe, Eigenschaftswerte, Property-Binding, Referenzen zu anderen ACComponents und Entity-Objekten
• Rekursives Parent-/Childsmodell in der ACComponents in Baum-Struturen organisiert sind und kommunizieren können.
• "Virtuelle" Vererbungsmechanismen (Erweiterung von ACComponents durch C#-Skripte, Eigenschaften, Konfigurationswerte...)
• Url-basierter Befehlsinterpreter (ähnlich REST)
• Diagnose- und Debugfunktionen

ACComponent ist vergleichbar mit der Klasse "System.Object" im .NET-Framework. Alle weiteren Klassen erben von ihr. Wenn Sie also Ihre eigene brachenspezifische Assembly bauen wollen sollten Sie mindestens von ACComponent ableiten.

Weitere Funktionalitäten der gip.core.autocomponent-Assembly:

• Alarmhandling und Logging
• Workflowmanagement: Methoden-Programmierung mittels Programmablaufdiagrammen
• Updatemanagement (Klassenanalyse per Attributklassen und Reflektion, Datenbankmodellaktualisierung, Aktualisierung von Designs)

Die gip.core.layoutengine-Assembly (3)

Die Präsentation erfolgt mittels WPF/XAML. Normalerweise liegen bei WPF-Anwendungen die Oberflächen als kompilierte BAML-Resourcen in der entsprechenden Assembly vor. iPlus geht hier einen anderen Weg: Alle Designs sind als XAML in der Datenbank gespeichert. Sobald eine ACComponent präsentiert werden soll, wird der XAML-Code aus der Datenbank geladen und Just-In-Time vom XAML-Parser kompiliert und vom iPlus-Framework präsentiert. Dies ist die wichtigste Aufgabe der gip.core.layoutengine.

Der datenbankbasierte Ansatz hat den Vorteil, dass die komplette Oberfläche kundenspezifisch verändert werden kann ohne ohne die Updatefähigkeit zu verlieren. Ausserdem ist der datenbankbasierte Ansatz notwendig da iPlus gleichzeitig auch ein SCADA-System ist.

Weitere Aufgaben der gip.core.layoutengine sind:

• Kapselung des mächtigen WPF-Bindingmechanismuses durch vereinfachte VBContent- und ACUrl-Syntax.
• Lose Bindung zu ACComponent-Proxy-Instanzen und deren Freigabe für den Garbage-Collector
• Integrierter WYSIWYG-Designer mit XAML-Umschaltung (Unterstützt Styles, Data- und Propertytrigger, Expressions, Multibinding)
• Umfangreiche Steuerelementbibliothek mit Themenumschaltung
• Converter
• Drag-And-Drop-Unterstützung

Ihre eigenen Steuerelemente verwenden

Wenn Sie Ihre eigenen Steuerelemente entwickeln wollen sollten Sie auf der gip.core.layoutengine aufsetzen. Benennen Sie Ihre Assembly entsprechend den Namenskonventionen und verwenden Sie "controls" als Postfix. Ein Beispiel dafür ist die gip.core.visualcontrols.dll. Sie beinhaltet Steuerelemente für die Automatisierungstechnik. 

Klassenbibliotheken zur Erweiterung der Entwicklungsumgebung oder Anwendungsfunktionalität

Assemblies, die das Wort "Manager" beinhalten, enthalten meist Komponenten welche dazu dienen die Entwicklungsumgebung oder Businessobjekte um Funktionalitäten zu erweitern. Businessobjekte sind Automation-Components, die an der Oberfläche angezeigt werden und mit Anwendungstabellen arbeiten (z.B. Materialverwaltung, Lagerplatzverwaltung, Lieferscheine,... aber auch die iPlus-Entwicklungsumgebung selbst). Werden nun gemeinsame Funktionen benötigt, die einmal von den Businessobjekten benötigt werden aber auch im Hintergrund von serverseitigen Instanzen, dann sollte man diese Funktionalitäten in sogenannte "Manager"-Assemblies auslagern damit möglicherweise cirkuläre Abhängigkeiten vermieden werden. Beispiele dafür sind die gip.core.manager.dll (iPlus) und die gip.mes.manager.dll (.MES). 

Die gip.mes.datamodel-Assembly (6)

Die gip.mes.datamodel-Assembly beeinhaltet das Datenmodell für die MES-Funktionalität. In diesem Falle benötigen Sie auch die erweiterte Datenbank mit den MES-relevanten Tabellen. Es gibt also zwei unterschiedliche Datenbankdateien:

1. Die reine iPlus-Datenbank die nur die Tabellen enthält die für die iPlus-runtime notwendig sind.
2. Eine erweiterte iPlus-Datenbank mit zusätzlichen Anwendungstabellen für das MES-System.

Die gip.mes.datamodel-Assembly erweitert auch nicht das Entity-Framework-Modell (.edmx) aus der gip.core.datamodel sondern ist ein komplett seperates Modell und muss in einem seperaten Datenbankkontext geöffnet werden (System.Data.Objects.ObjectContext).

Im Datenbankmodell sind auch Fremdschlüsselbeziehungen unidirektional. MES-relevante-Tabellen können auf iPlus-Relevante Tabellen verweisen aber nicht umgekehrt.

Bei der späteren Programmierung können Sie Hilfsfunktionen nutzen, welche Ihnen das Matching zwischen beiden Datenbankkontexten erleichtert (siehe EntityObjectExtension).

Sie können natürlich auch Ihre eigene Anwendungstabellen dem iPlus-Datenbankmodell hinzufügen und sich eine eigene .datamodel-Assembly bauen. Sie müssen dafür das Interface IACEntityObjectContext implementieren und die Klasse ACObjectContextHelper verwenden. Siehe Thema "Anwendungstabellen hinzufügen".

Klassenbibliotheken für die Anwendungsprogrammierung.

Assemblies die für die eigentliche Anwendung oder Branchenlösung benötigt werden sollten folgendem Namensschema entsprechen:

• *.bso.*.dll: Die Assembly enthält überwiegend Automation-Components die Businessobjekte (BSO) sind.
• *.solution.*.dll: Die Assembly enthält diverse Automation-Components (Serverseitige und BSO's) und ist für eine Kundenlösung oder Branchenlösung gedacht.
•  *.mes.*.dll: Die Assembly enthält diverse Automation-Components und ist ein Teil oder eine Erweiterung für iPlus-MES