Whitepaper: Modularisierung aus Sicht des Anwenders

Einleitung

In CODESYS 3.5 SP17 haben wir einen großen architekturellen Umbau vollzogen. Früher war der größte Teil der Programmiersystemfunktionalität in einem einzigen zusammenhängenden Setup gebündelt. Lediglich CODESYS SoftMotion sowie die kostenpflichtigen Add-ons der CODESYS Professional Developer Edition waren separat. Im Zuge des Umbaus haben wir nun diese Modularisierung bis weit in die Kernfunktionalität hinein fortgeführt. So sind die meisten Programmierspracheneditoren, Feldbuskonfiguratoren und Codegeneratoren nun in eigene Add-ons ausgelagert. Dasselbe gilt für große Features wie die Visualisierung oder die Symbolkonfiguration, um zwei Beispiele zu nennen. Im Kern verbleiben noch wichtige Infrastruktur-Features wie das Oberflächengerüst (Menüsystem, Navigator, Meldungsfenster, etc.), das Compiler-Frontend sowie Komponenten zum Projekt-Handling und zur Kommunikation mit Steuerungen. Es sollte erwähnt werden, dass zukünftig noch weitere Teile vom Kern in separate Add-ons verschoben werden können.

Wir werden diese Modularisierung in erster Linie dazu nutzen, die Versionszyklen der einzelnen Bestandteile zu entzerren. In der Vergangenheit war es notwendig, die gesamte CODESYS-Entwicklung bezüglich neuer Features und Improvements auf einen einzigen Termin pro Jahr - nämlich dem Release-Datum eines Service Packs - zu konvergieren. Features, die knapp nicht fertig wurden, haben meist zu einer Verschiebung des Service Packs geführt. Features, die vom Zeitplan deutlich unpassend waren, haben sich um ein ganzes Jahr in die Zukunft verschoben. Diese Verzahnung möchten wir sowohl aus eigenem Interesse als auch im Interesse aller CODESYS-Anwender auflösen und zukünftig jedes Add-on unabhängig versionieren und freigeben.

Für CODESYS-Anwender ergeben sich eine Reihe naheliegender und gewichtiger Vorteile.

Features werden zeitnah nach Fertigstellung freigegeben und stehen so schnell wie möglich zur Verfügung.
Beta-Versionen von Add-ons können an interessierte Anwender ausgeliefert werden, um eine rechtzeitige Feedback-Möglichkeit zu haben. Dabei kann eine solche Beta-Version in einer ansonsten stabilen Umgebung betrieben werden.
Nicht benötige Add-ons können entfernt werden, was sowohl dem Platzbedarf als auch der Gesamt-Performance zuträglich ist.

Natürlich steht dieser Flexibilität eine gesteigerte Komplexität gegenüber. In diesem Whitepaper möchten wir beschreiben,

welche Einschränkungen bestehen
welche Maßnahmen wir ergriffen haben, um die Komplexität beherrschbar zu machen
welches Vorgehen wir für typische Anwendungsfälle empfehlen

Das Setup

Das Setup, welches nach wie vor aus dem CODESYS Store International heruntergeladen werden kann, ist vollständig. Alle Bestandteile, die schon Teil von CODESYS 3.5 SP16 und früher waren, sind auch im aktuellen Setup enthalten, d.h. Anwender erhalten nach der Installation ein gewohntes Gesamtsystem ohne funktionale Abstriche.

Wir finden, dass sich Anwender die individuelle Zusammenstellung von Kernsystem und Add-on-Versionen in Ruhe erarbeiten sollen und sich nicht schon von Anfang an zwangsweise damit beschäftigen müssen. Wir sind uns auch dessen bewusst, dass viele Anwender gar nicht unglücklich über das Gesamtpaket sind und vielleicht niemals eine individuelle Zusammenstellung machen möchten - ein vollkommen legitimer Ansatz, dem das Tool nicht im Weg stehen soll.

Der Installer

Das Setup installiert automatisch ein neues globales Tool, das sich CODESYS Installer nennt. Damit können alle CODESYS-Installationen sowie die damit in Verbindung stehenden Add-ons verwaltet werden. Es ist Dreh- und Angelpunkt für die Anwender, die von den Vorteilen der Modularisierung aktiv profitieren möchten.

Mit dem CODESYS Installer kann eine beliebige Anzahl unabhängiger Installationen verwaltet werden. Innerhalb jeder einzelnen Installation kann genau festgelegt werden, welche Add-ons Bestandteil sein sollen. Zur besseren Übersichtlichkeit kann jeder Installation ein sprechender Name gegeben werden. Bei jeder Installation kann eingestellt werden, welche Updates gemeldet werden sollen; standardmäßig ist dies auf „nur freigegebene Versionen“ eingestellt, es lässt sich aber auch auf Prerelease-Versionen umstellen oder auch abschalten, um den Stand einer Installation zu fixieren.

Weitere Hinweise auf nützliche Funktionen des CODESYS Installer finden sich weiter unten bei den Empfehlungen.

Innerhalb von CODESYS haben wir das Notification Center an den CODESYS Installer angebunden. Hier werden Nachrichten zu passenden Updates eingeblendet. Man muss also nicht ständig den CODESYS Installer ausführen, um über Updates benachrichtigt zu werden.

Kompatibilität

Hinter dem Stichwort Kompatibilität verbirgt sich der größte Komplexitätszuwachs, der sich aufgrund der Modularisierung ergibt. Während es traditionell eine lineare Weiterentwicklung gab und die Kompatibilitätsfrage daher einfach war („neues CODESYS kann altes Projekt lesen“), ist die Angelegenheit in einer hochmodularen Umgebung ungleich schwieriger.

Die Entscheidungen, die wir getroffen haben und die in den nachfolgenden Abschnitten näher erläutert werden, sind bewusst nicht anhand des technisch Machbaren, sondern des sinnvoll Beherrschbaren getroffen worden.

Projekt-Kompatibilität

Hierbei geht es um die Frage, inwieweit eine CODESYS-Installation ein Projekt oder eine Bibliothek öffnen kann, die mit einer anderen CODESYS-Installation erstellt wurde.

Diesen Mechanismus haben wir nicht geändert. Das Verhalten ist identisch wie in den CODESYS-Versionen vor der Modularisierung. Falls es im Projekt Daten gibt, die mit der aktuellen Version nicht gelesen oder interpretiert werden können, weil sie aus einer neueren Umgebung erzeugt wurden, so werden die betroffenen Objekte mit einem roten Kreuz im Navigator markiert und entweder mit [incomplete] (→ Editor kann noch geöffnet werden) oder [unknown] (→ Editor kann nicht mehr geöffnet werden) gekennzeichnet. In beiden Fällen lässt sich das Projekt nicht auf die Steuerung laden (weil sich ein undefiniertes Programmverhalten ergeben könnte), und es steht auch nur Speichern unter zur Verfügung (um ein versehentliches Überschreiben des Originalprojekts und damit einen Datenverlust zu verhindern).

Dieses Verhalten hat sich seit Jahren bewährt.

Code-Kompatibilität

Hierbei geht es um die Frage, ob man mit einer CODESYS-Installation zu einem Projekt immer binärgleichen Steuerungscode generieren kann wie eine andere CODESYS-Installation. Vereinfacht ausgedrückt: Kann man ein beliebiges Projekt mit einer CODESYS-Installation öffnen und sich ohne Online-Change bzw. Download auf die Steuerung einloggen?

Zu diesem Zweck gab es bis einschließlich CODESYS 3.5 SP17 das Konzept der Compilerversion. Die Compilerversion werden wir ab CODESYS 3.5 SP18 entfernen. Wenn man darauf angewiesen ist, sich mit einem Projekt ohne Online-Change bzw. Download auf eine Steuerung einloggen zu können, dann muss man das Projekt mit einer genau passenden CODESYS-Installation öffnen.

Für die Entscheidung, das Konzept der Compilerversion aufzugeben, gibt es eine Reihe gewichtiger Argumente:

Für den generierten Code sind nicht nur der Compiler, sondern auch die beteiligten Programmierspracheneditoren und Feldbuskonfiguratoren verantwortlich. Da diese nun in unabhängig versionierte Add-ons ausgelagert wurden, kann es prinzipiell keine einheitliche allumfassende Compilerversion mehr geben. Den Versuch, eine Kombination aus verschiedenen Add-on-spezifischen Compilerversionen zu einer Art Compilerversionsprofil zusammenzufassen, finden wir aus Anwendersicht übermäßig komplex. Bei CODESYS UML (Teil der CODESYS Professional Developer Edition) gibt es schon seit Jahren eine separate Sprachmodellgenerierungsversion, aber schon bei diesem einen Add-on hat sich dieses Konzept in der Praxis nicht bewährt, geschweige denn bei der jetzigen Vielzahl an Add-ons.
Die Compilerversion hat bereits in der einfachen Form genaue Kenntnis des Anwenders erfordert. Spätestens die Korrektur einer versehentlich falsch eingestellten Version war oft problematisch. Anwender, die damit schlechte Erfahrungen gemacht haben, oder die von diesem Konzept grundsätzlich nicht überzeugt waren, haben schon in der Vergangenheit mehrere Maintenance-Installationen mit sich geführt, um sich im Wartungsfall auf laufende Steuerungen sicher einloggen zu können. Wie wir weiter unten sehen werden, bieten wir für diesen Fall nun eine robuste interaktive Unterstützung an.
Jede neue Compilerversion bläht unsere interne Codebasis auf. Einerseits wirkt sich das negativ auf die Performance und auf die Installationsgröße aus. Andererseits können wir längst nicht alle Kombinationen in dieser Codebasis testen. Da die Pflege der Compilerversionen darüber hinaus auch in gewisser Weise fehleranfällig ist, steht dies in direktem Widerspruch zu unserem stetig steigenden Qualitätsanspruch. Mit anderen Worten: Wir können nicht garantieren, dass das bisherige Compilerversionskonzept in allen Fällen zuverlässig funktioniert, und wir könnten es erst recht nicht mehr, wenn wir dieses Konzept aufgrund der Modularisierung noch komplexer ausgestalten müssten.
Die beiden vorhergehenden Argumente können so zusammengefasst werden: Es ist aus Anwendersicht attraktiv, für den Maintenance-Fall durch unsere Tool-Unterstützung eine sicher passende Version herstellen zu können, ohne sich überhaupt mit einer Compilerversion beschäftigen zu müssen.

Laufzeitsystem-Kompatibilität

Hierbei geht es um die Frage, inwieweit eine CODESYS-Installation zu einer Laufzeitsystem-Version kompatibel ist. Mit anderen Worten: Kann man sich mit einer neuen CODESYS-Installation auf eine alte Steuerung einloggen und die verfügbaren Online-Funktionen nutzen?

Die damit verbundenen Mechanismen haben wir nicht geändert. Grundsätzlich sind Programmiersystem- und Laufzeitsystemversionen beliebig kombinierbar, mit folgenden Einschränkungen:

Eine neue Programmiersystemversion bietet möglicherweise Funktionen an, die eine ältere Laufzeitsystemversion noch nicht unterstützt. In diesem Fall steht die Funktion nicht zur Verfügung.
Eine ältere Programmiersystemversion kann möglicherweise nicht mit einer neueren Laufzeitsystemversion arbeiten, wenn Security-Erweiterungen dies verbieten (beispielsweise eine erzwungene Benutzerverwaltung oder ein neuartiger Verschlüsselungsalgorithmus).

Empfehlungen für Anwender

Die in diesem Abschnitt beschriebenen Szenarien können selbstverständlich auch in Kombination zur Anwendung kommen. Wir glauben, dass hiermit die allermeisten praxisrelevanten Fälle abgedeckt sind und möchten diese bestmöglich durch unsere Tools unterstützen. Auch in Zukunft wollen wir unsere Software entlang dieser Anwendungsfälle weiter optimieren.

Szenario	Empfehlung	Tool-Unterstützung
Alltägliche Entwicklung an einem laufenden Projekt	Die CODESYS-Version sowie die dazugehörigen Add-ons sollen stets up-to-date gehalten werden. Wir arbeiten stetig an großen und kleinen Verbesserungen, Fehlerbehebungen und Security-Updates, so dass die neueste Version immer die beste Version aller Zeiten ist. Es gibt kaum Gründe, an alten Versionen festzuhalten.	Der CODESYS Installer zeigt alle zu einer Installation gehörigen verfügbaren Updates an. Diese Updates können mit wenigen Mausklicks heruntergeladen und installiert werden. Darüber hinaus werden über das Notification Center, das in CODESYS als andockbares Fenster integriert ist, ebenfalls verfügbare Updates (genau passend zur aktuell ausgeführten Installation) angezeigt. Von hier kann direkt in den CODESYS Installer gesprungen werden, so dass dieser nicht ständig aktiv sein muss. Alle von uns bereitgestellten Setups und Add-ons sind signiert, daher ist das Herunterladen über das Internet sicher. Wir haben den PackageManager um entsprechende (teilweise interaktive) Prüfmethoden erweitert.
Alltägliche Entwicklung an einem laufenden Projekt unter der Randbedingung, dass mehrere Personen in einem Team eine einheitliche Installation einsetzen müssen	Wie oben. Eine Person im Team installiert verfügbare Updates bei sich und testet aus. Bei erfolgreicher Freigabe wird die neue Referenzinstallation im Team verteilt.	Im CODESYS Installer können bestehende Installationen als Beschreibungsdatei exportiert werden. Mit Hilfe dieser Datei kann an auf einer anderen Maschine eine identische Installation hergestellt werden. Dieser Mechanismus steht auch über Kommandozeile zur Verfügung, eignet sich also insbesondere auch für automatisierte Umgebungen.
Ausprobieren neuester Add-on-Features in einer geschützten Umgebung	Eine bestehende produktiv eingesetzte CODESYS-Installation wird dupliziert. In dieser werden beliebige Beta-Versionen von AddOns installiert und bedarfsweise upgedatet. Die produktiv eingesetzten CODESYS-Installationen bleiben davon vollkommen unberührt. Die normale Arbeit an Projekten wird nicht beeinträchtigt.	Der CODESYS Installer erlaubt es, auf einfache Weise eine Kopie einer Bestandsinstallation anzulegen. Pro Installation kann gewählt werden, ob nur freigegebene Updates oder auch experimentelle Beta-Updates angeboten und installiert werden sollen. Bisher konnte ein bestimmtes Service Pack oder Patch immer nur einmal pro Maschine installiert werden. Seit Einführung des Installers ist diese Einschränkung aufgehoben.
Wartung an einer bestehenden Steuerung, ohne das dazugehörige Bestandsprojekt zu ändern. Es muss gewährleistet sein, sich ohne Online-Change oder Download auf die Steuerung einloggen zu können,	Es wird eine genau zum Projekt passende CODESYS-Installation erstellt. Ohne sich mit Compilerversionen beschäftigen zu müssen, ist die Generierung eines binärgleichen Steuerungscodes garantiert.	Werden beim Laden eines Projekts Unterschiede zwischen der aktuellen CODESYS-Installation und der Erstellungsversion festgestellt, bekommt man die Möglichkeit, sich eine genau zum Projekt passende Installation herunterladen und installieren zu können. Das Projekt wird dann automatisch in dieser neu angelegten Version geöffnet. Darüber hinaus können beim Laden natürlich auch passende Installationen ausgewählt werden, die bereits auf der Maschine existieren. Installationen bekommen im CODESYS Installer einen benutzerdefinierten Namen. Damit verliert man auch nicht die Übersicht, falls man eine größere Anzahl an Installationen verwalten muss. Um nicht laufend Update-Vorschläge für eine solche spezielle Kompatibilitätsinstallation zu bekommen, werden diese per Default vom Update-Kanal getrennt.
Weiterentwicklung an einem älteren Bestandsprojekt	Das Projekt wird in einer aktuellen CODESYS-Installation weiterentwickelt. Da ohnehin Änderungen am Code gemacht werden, spielt der fällige Online-Change oder Download keine Rolle.	CODESYS kann nach wie vor ältere Projekte verlustfrei laden. Sollte ein notwendiges Add-on fehlen, besteht die Möglichkeit, dieses direkt aus dem Projektladevorgang heraus herunterladen und installieren zu können. Ansonsten ist durch Schreib- und Downloadschutz sowohl das Projekt selbst als auch die Steuerung geschützt.

In diesem Abschnitt: