Allgemeine Betrachtungen Low Code oder No Code in der Anwenderprogrammierung

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Linutronix GmbH

Die Forderung nach einfacher grafischer Programmierung anstelle vieler Codezeilen ist aktuelles Thema – und zugleich doch irgendwie ein alter Hut. Statt dass sich ein allgemeiner Ansatz etabliert hätte, existieren viele verschiedene Tools und Herangehensweisen. Der Artikel stellt sich allgemein diesem Problem.

Es ist nicht so, dass die Entwicklung an allen Fronten parallel fortschreitet, mit halbjährlichen bahnbrechenden Releases. Vielmehr gab es für bestimmte Themen Hype-Zeiten, in denen wirklich Neues entstand. Die nächsten Jahrzehnte waren dann geprägt eher von Details und Spezialisierungen.

Die Hype-Zeit der Frage nach grafischer Programmierung war bereits in den 80er Jahren, also vor drei bis vier Jahrzehnten. Damals wurden grundlegende Ideen geschaffen. Diese haben sich aber zumeist in bestimmten Tools manifestiert, die ihrerseits sich in Grundcharakteristika nur langsam bewegen (die halbjährlichen Releases sind eher für verkaufsträchtige Hypes). Zumal hält jedes dieser Tools meist nur die eigenen Ansätze hoch, es hat sich also keine allgemeine Herangehensweise entwickelt. Darum kann man zwar auf der einen Seite Low Code bereits als einen „alten Hut“ bezeichnen, doch andererseits ist die allgemeine Forderung nach Low Code auf einer gewissen Ebene immer noch aktuell.

Beispiele für solche Tools der grafischen Programmierung, die teilweise auch dem Low-Code-Ansatz zugeordnet werden können sind: Matlab/Simulink, Labview, auch firmenspezifische Tools wie Simatic S7 mit KOP und FUP (FUP= Funktionsplan oder Function Block Diagram , auch FBD, KOP ist der Kontaktplan oder Ladder Logic; Diese Bezeichnung ist bildlich, der Anwenderprogrammierer ordnen seine Relais und Schaltkontakte zwischen den parallelen Leitern für Plus und Masse an wie die Sprossen einer Leiter, und wie er dies einstmals für handverdrahtete Logik gelernt hat.) Neben Relais und Kontakten gibt es dann noch Module, die ebenso zu verdrahten sind und die eine kleine textuelle Programmierung benötigen, kein größeres Problem. - Also genau das, was man sich in diesem Bereich unter Low Code vorstellt.

Vorsicht Falle: Outsourcing und Tooladaption

Man möchte ja nur eine einfache Programmierung mit grafischen Elementen. Die Zeilenprogrammierung ist verhasst, das können Andere besser. Also kaufe man sich entweder ein Tool, das alles verspricht was man braucht, oder man beauftrage eine Spezialfirma für das Wunschtool.

Das ist Herangehensweise von Managern, die Features kann man einklagen. Doch ist dies ein wenig blindflügig:

• Es entsteht wieder ein spezielles Tool, mit wenig Kompatibilitäten.

• Ist man sich den Anforderungen komplett bewusst?

• Adaptionen von Grafischen Programmierelementen mit aufwändigen grafischen Konfigurationseinstellungen führt den Low Code Ansatz ad absurdum.

Der Königsweg: Grafische Programmierung und deren textuelle Inhaltsgestaltung

Der Anwender programmiert mit grafisch vorgegebenen Funktionsbausteinen, platziert und verdrahtet diese und gibt wenige textuelle Konfigurationsinformationen, „Parameter“ ein. Das ist leicht vermittelbar, sehr anschaulich und auch gut für die Dokumentation. Ergänzend können in der grafischen Projektierung während des Betriebes Werte angezeigt werden, als Kontrolle und Hilfe bei der Fehlersuche bei Inbetriebsetzung.

Was die einzelnen Funktionsbausteine im Inneren tun, ist Sache eines Programmierteams. In einer kleinen Firma kann dies auch eine Einzelperson sein, oder eine Partnerfirma in der Nähe. Damit können Funktionsbausteine auf neue Anforderungen angepasst werden. Es können dem Anwender passende FB-Typen geliefert werden anstatt dass er außen komplexe Verknüpfungen für bestimmte Funktionen fortwährend projektieren und pflegen muss. Dieses „Programmierteam“ muss freilich nicht nur die textuelle Programmierung als solche beherrschen sondern muss einen Überblick über die spezifischen Modularitätsanforderungen haben (Zuschnitt der Module) und die fachspezifischen Besonderheiten kennen. Damit ist es eine weniger gute Idee, diese Dinge weit fern auszulagern.

Diese Herangehensweise ist nun eigentlich auch „state of the art“ seit Jahrzehnten. Als Beispiel wäre SIBAS32 zu nennen, ein langjähriges System zur Konfiguration von Steuerungen in der Bahntechnik (mittlerweile von SIBAS PN abgelöst). Die Funktionsbausteine wurden in einer eigenen Abteilung der Herstellerfirma erstellt, in enger Zusammenarbeit mit den Pilotprojekten der Anwendung. Die Anwender selbst, also die Projektierer von SIBAS, konnten dagegen keine eigenen Änderungen im internen Code der Funktionsbausteine vornehmen.

Ein weiteres Beispiel aus einer ganz anderen Ecke: Mathworks Simulink und S-Functions. Der grafische Programmierer nutzt und parametriert vorgegebene Function Blocks. Diese FBs können im Inneren wieder grafisch programmiert sein, aber auch textuell als sogenannte „System-“ Funktionen mit Zeilencode-Inhalt. Das „System“ kann dort aber auch leicht vom Anwender beeinflusst werden. Am einfachsten mit der Mathworks-eigenen Matlab-Sprache, aber auch mit C oder auch C++ Programmierung. Letzteres wird gut unterstützt, benötigt dennoch etwas Spezial-Knowhow. Vorteil: Man hat dann genau den selben Source-Code in der Simulation als auch im Zielsystem, egal ob man den „Simulink-Coder“ benutzt oder die Grafiken dann handprogrammiert wenn man dies tun will. Auch hier wieder die Herangehensweise: Beispielsweise eine spezielle Hardwareadaption kann in C direkt zielsystemspezifisch vom Spezialisten ausgeführt werden. Für den Anwenderprogrammierer für die Regelalgorithmen in einem Gerät ist dies dann geboxt (in der Black Box). Selbstverständlich können diese Rollen auch von der selben Person eingenommen werden, und sind auch dann sehr günstig, unter anderem für die Dokumentation und eine gute Modularitätsstruktur.

Im KOP/FUP Bereich (siehe Simatic S7) gab es früher die AWL (Anweisungsliste) als dritten Part für das textuelle Ausfüllen von Funktionsbausteinen in KOP oder FUP grafisch einfügbar. Heute ist das eher z.B. in der SPS Programmierung als SCL oder in der IEC61131-3 Norm als „Structure Text“ benannt. Auch hier ist diese Herangehensweise seit Jahrzehnten etabliert.

Abbildung der Grafischen Programmierung mit Text-Versionsmanagement

Interessant ist, dass sich trotz allem Reden über die viel besseren Möglichkeiten der Grafischen Programmierung seit den 1990gern diese sich nicht breit etabliert hat, sondern teils das Gegenteil passiert: Die textuelle Programmierung verdrängt wieder eine vorher etablierte Grafikprogrammierung. Eine der Gründe, nebst der Verbesserung auch der IDEs für textuelle Programmierung, dürfte sein: In der textuellen Programmierung kann man mit textuellem Vergleich viel besser die Versionshistorie verfolgen. Versionsmanagement-Tools bieten immer den textuellen „View Diff“ sofort an. Für eine grafische Versionshistorie braucht man schon eher ein Spezialtool und gute Augen. Da die Bedeutung des Versionsmanagement nicht fahrlässig unterschätzt werden sollte, ist dies als wesentlich zu betrachten.

In verschiedenen Tools kann man teilweise die hinter der Grafikprogrammierung liegenden Files textuell auswerten. Bei einem mdl-File in Simulink kann man schon mal, wenn die vielen nebensächlichen Informationen aus dem Blick genommen werden, im Nachhinein erkennen, was denn eigentlich in der Grafik funktional geändert wurde. Hilfreich ist dies auch wenn man bestimmte Signalnamen und ähnliches sucht. Es ist sogar möglich, Signalnamen und Parameter direkt im textuellen File zu ändern und danach grafisch weiter zu bearbeiten. Ähnlich wie im Beispiel Simulink gelingt dies bei vielen Grafiktools.

Also haben wir auch hier wieder eine zweckdienliche Trennung: Der Anwenderprogram¬mierer ändert in der Grafik, der Spezialist schaut sich die Änderungen als Versionsdifferenz dann im Text an oder kann dort noch helfend eingreifen.

Um bei Simulink zu bleiben: Im neueren slx-Format kann man dies genauso tun, nur mit etwas mehr Aufwand. Das slx-Format ist ein gezipter File-Tree aus meist XML-Files, die gut strukturiert sind. Diese Herangehensweise ist sehr allgemein anzutreffen, beispielsweise auch beim weiter unten noch in den Fokus gerückten Libre-Office-draw. Grundsätzlich sind diese Speicherformate intern, nicht offiziell dokumentiert und können sich von Version zu Version beliebig ändern. Die Änderungen sind aber meist überschaubar und gut nachzuvollziehen.

Für die Bewertung der funktionalen Inhalte einer Grafikprogrammierung gibt es die folgende Möglichkeit: Aus den Grafikinformationen wird eine textuelle Abbildung erzeugt. Wenn diese von funktional unrelevanten Informationen bereinigt ist, das sind auch die Grafikpositionen, und in einer einheitlichen Form gespeichert ist (auch nach Änderung stehen im Generat die gleichen Dinge immer an gleicher Stelle), dann gelingt eine textuelle Differenzschau, um die funktionale Änderung zu bewerten.

Denkbar ist es auch, dieses funktionale textuelle Abbild nach Änderungen mit den originalen Grafikfiles geeignet so zu verarbeiten, dass ein neuen Satz Grafikfiles auf Basis dieser textuellen Funktionsänderung entstehen. Das sind Möglichkeiten, die die Toolhersteller bekannter Grafiktools nicht von selbst anbieten, die aber als add on programmiert werden können.

Die Frage nach dem Tooling

Vergleicht man mit Tools für textuelle Programmierung, dann stellt sich dort die Situation wie folgt dar:

Die Quellfiles sind mit jedem beliebigen Texteditor bearbeitbar. Sie sind vergleichbar und auch gut generierbar. Man kann also den Editor der Wahl nutzen, kann wechseln, kann Spezialtools nutzen beispielsweise für Analyse, aber auch für Codegenerierung oder Suchen und Ersetzen.

• Speziell angepasst für das Zielsystem sind die Compiler. Aber auch dort hat man eine gewisse Einheitlichkeit. Viele Compiler basieren direkt auf GNU oder sind dem ähnlich. Man kann zwar in die Falle hineinlaufen, die speziellen Features des ganz spezifischen besten Spezialcompilers zu nutzen, aber man kann aus eigenem Ermessen und ohne Nachteile diese Falle auch umgehen. Es gibt also eine weitgehende Kompatibilität.

• Die spezifische IDE (Integrated Development Environment) erscheint nach außen als „das Tool“ für die Benutzung, man kann aber immer auch außerhalb der IDE arbeiten oder eine andere IDE entsprechend angepasst nutzen.

Demgegenüber ist die Bedienung verschiedener Tools der Grafikprogrammierung zwar meist ähnlich, doch die Tools sind unterschiedlich und inkompatibel. Oft haben Tools zeitinvariant bestimmte Usability-Besonderheiten. Man ist an das Tool mit allen seinen Macken (“Usability Besonderheiten“) gebunden.

Das ist Schade. Die allgemeine Entwicklung hat uns ein einheitliches Textformat beschert, aber kein einheitliches Grafikformat.

Nimmt man den Stand der Technik bei der textuellen Programmierung als Vorbild, dann ist als erstes zu überlegen, für die grafische Editierung ein Standardgrafik-Draw aus dem Open Source Bereich, allgemein verfügbar und bekannt, zu nutzen.

Ähnlich wie bei der textuellen Programmierung sollte man auch Editieren und Verarbeiten trennen. Aus den gespeicherten Daten der Grafik Ablaufcode zu generieren, denn darum geht es ja im Wesentlichen, ist faktisch kein großes Problem. Die Speicherformate sind meist XML, die Daten lassen sich gut herauslesen, auch was zueinander gehört. Man kann Gruppierungen nutzen, und über Formatzuweisungen Metainformationen unterbringen, und hat selbstverständlich auch die textuellen Kennzeichnungen von Funktionsblocknamen, Konnektoren, Signalnamen als Text an einer Verbindungslinie und dergleichen.

Also nehme man ein Standard-Draw-Tool, beschäftige einen Spezialisten der die Konvertierung und Generierung daraus programmiert, nachvollziehbar, ggf. Open Source, und damit hat man eine langjährige Basis ohne die Bindung an einen speziellen Toolhersteller.

Nun gibt es im Bereich der IDEs bereits einige Platzhirsche, die diesem Ansatz entsprechen könnten. In Eclipse kann man grafisch arbeiten mit entsprechender Datenablage. Visual Studio Code etabliert sich als Verdränger des Eclipse-Hirsches auf dem Platz. Dieser Ansatz ist also auch von diesen Tools erkannt, nur noch nicht allgemein etabliert. Ist das Tool selbst kostenfrei (mindestens in der arbeitsfähigen Grundversion) verfügbar, dann kann es sich auch verbreiten. Nichts gegen Kostenpflichtigkeit, meine Kollegen aus der Toolentwicklung wollen auch Geld verdienen. Aber Kostenpflichtigkeit bedeutet immer Management-entscheidung ob und welches Tool genutzt wird, und dann haben wir wieder die inkompatible Vielfalt. Schauen wir auch in dieser Frage auf die Tools der textuellen Programmierung, diese sind meist frei nutzbar.

Man kann auch erwägen, ein Standardgrafik-Draw-Tools als Editor zu nutzen. Beispielsweise Libre Office Draw [9]. Dies ist fast kompatibel mit Open Office, lässt sich ggf. auch aus Word und Visio konvertieren, damit hat man eine kompatible Tool-Landschaft ähnlich den verschiedenen Text-Editoren. Im Libre Office ist es ähnlich wie auch im Visio möglich, Blöcke zu verbinden mit sogenannten Connectors. Die Verbindungslinien werden mit geführt beim Schieben der Blöcke (=Funktionsblöcke). Elemente lassen sich gruppieren. Damit hat man die notwendige Grundausstattung. Was fehlt, ist die Unterstützung von Querverweisen, Aufklappen von Zusatzinformationen und dergleichen. Dies könnte man allerdings im Sinne des Open Source hinzufügen, in einer Community auf den Zweck der grafischen Programmierung orientiert. Das heißt, man nutzt die Speicherform von Libre Office, kann auch immer im originalem Libre-Office-Draw editieren (ähnlich wie mit einem einfachen Texteditor die Textquellen), für die eigentliche Arbeit des Anwenderprogrammierers benutzt man aber das für den Zweck geschaffenen Spezialtool. Dieses ist weniger komplex in der Usability und hat die nötigen Spezialfeatures.

Das Bild links - ein Snapshot aus der Editierung mit Libre-Office-Draw - zeigt eine Zusammenschaltung von Blöcken für eine Hardwareschaltung (FPGA). Die Rückwärtspfeile sind ein Zugriff auf Referenzen aus anderen Modulen. Die Pfeile sind „Konnektoren“ mit Glue-Points, die auf den beschreibenden Text der Anschlüsse gehen. Diese sind nicht zugänglich, wenn der jeweilige Block mit dem Text gruppiert ist. Die Gruppierung des Blocks mit seinen Anschlusstextfeldern ist notwendig sowohl zum einfachen Schieben des Blocks als auch für die Datenauswertung der Grafik. Um eine neue Verbindung zu ziehen, muss man erst die Gruppe auflösen, dann andocken, dann die Gruppe wieder bilden, also eine Usability-Besonderheit. Nutzung von „Shape - Enter Group“ funktioniert leider nicht entsprechend, Libre Office Version 6.4.5.2. Aber das Tool hat die passenden Ansätze, dies zu können. Es lässt sich jetzt schon arbeiten.

Diese Entwicklungsrichtung für Low Code Tooling möchte dieser Artikel anregen. Offensichtlich gibt es da noch sehr wenig.

UML und SysML im Low-Code-Funktionsblock-Ansatz

Vor ca. zwei bis drei Jahrzehnten wurde UML als Unified Modeling Language geschaffen, aus dem Ansatz heraus, bis dato verbreitete verschiedene Darstellungen der Softwarestrukturierung und Planung zu vereinheitlichen. Auch die Generierung von Code aus der grafischen Modellierung lag im Fokus. Dass die Codegenerierung aus UML-Modellen bzw. die UML-Modellierung als Gesamtansatz sich nicht genügend breit durchgesetzt hat, lag auch daran, dass die UML zwar die Softwarestrukturierung gut unterstützt, aber die Informationen sind nicht vollständig genug. Handergänzungen und eine nicht unaufwändige Konfigurierung der Codegenerierung stellten sich dagegen.

Bewährt hingegen hat sich der UML- und insbesondere SysML-Ansatz für die Dokumentation und Erarbeitung der gesamten Softwarestrukturierung (Architektur) einschließlich der Einbeziehung von Anforderungsmanagement. Die Denkgrenze ist dabei nicht die Software des Einzelgerätes sondern der Komplex der Lösung einschließlich Hardware und Netzwerkkommunikation (Cyber-Physical System).

UML/SysML und Grafische Funktionsblockprogrammierung haben sich nebeneinander entwickelt. Es könnte darauf ankommen, beide Denkwelten zueinander zu bringen. Soll heißen - Low Code Grafikprogrammierung erzeugt auswertbare Daten, die in SysML-Modelle einfließen. Ab SysML v2 soll es eine textuelle Notation geben. Man hat damit grafische und textuelle Notationen der Modellteile parallel, gepaart mit einer präzisen Semantik. Dies erleichtert eine Generierung und Auswertung der Modelldaten in verschiedenen denkbaren Richtungen.

Ein Beispiel: Möglicherweise muss in der Low-Code-Programmierung lediglich das Identifier einer Anforderung mit eingetragen werden. Damit ist rückschließbar ob und wie eine Anforderung realisiert wurde und warum die Programmierung gerade so ist. Interessant ist dabei allerdings, Anforderungsmanagement etwas agil anzugehen. Doch das Thema sprengt diesen Artikel.

Ein interessantes Lesson-Learned Detail aus UML sei nicht unerwähnt: Bei einigen Diagrammen in UML, speziell dem Class Diagram oder Object Model Diagram kann man ein Element, konkret eine class, in verschiedenen Diagrammen aufführen um sie in verschiedenen Kontexten zu beschreiben. Bei dem Funktionsblock-Tools (Simulink & co) ist aber ein Block nur einmal darstellbar, ein zweiter Block mit gleichen Namen ist ein Fehler oder erzeugt eine weitere Instanz. Das ist schade. Es wäre sehr einfach, aufgrund des Namens und gleichen Typs den Grafikblock nur als „zwei mal dargestellt“ zu erkennen. Bei einem großen Block könnte man so die Verbindungen auf verschiedene Diagramme verteilen oder ein spezielles Diagramm für die Parametrierung erstellen.

Fazit: Was ist wichtig und richtig für Low-Code?

Für die richtige Verwendung eines Low-Code-Ansatzes lassen sich die folgenden Schlussfolgerungen festhalten:

• Kein gekauftes Tool das viel verspricht und nicht selbst konfigurierbar ist. Man sollte möglichst die Dinge in die Hand nehmen, in Zusammenarbeit mit einer Community.

• Low oder No Code für den Endanwender, aber textuelle Programmierbarkeit der Inhalte der Low Code Grafikbausteine seitens des Spezialisten in der Nähe.

• Funktionale Änderungen sollen durch Vergleich eines textuellen Abbildes der Low / No Code Grafik gewonnen werden können.

• Die Bedeutung der Generierung von Informationen aus den verschiedenen hinterlegten textuellen Daten sollte beachtet werden, ebenfalls durchschaubar gestaltet. Kein fremdes unbekanntes und angeblich „bestes“ System verwenden sondern auf eigenes Wissen, Open Source und Community setzen.

• Allgemeiner Ansatz für Editieren verfolgen.

Checkliste für Citizen Development im Unternehmen

4 Kriterien für den passenden Low-Code-Ansatz

Domänenwissen schlägt Coding-Skills

Software entwickeln mit Low Code, No Code und GPT-3

Low Code in Embedded-Systemen – geht das?

* Dr. Hartmut Schorrig war in den vergangenen zwei Jahrzehnten Entwicklungsingenieur bei Siemens. In den Jahren zuvor wurden in verschiedenen Forschungsinstituten und in der Wirtschaft Erfahrungen gesammelt, anfänglich in den 80-ger Jahren mit der Entwicklung eines Industrie-PCs „MC80“, damals selbstverständlich noch in Assembler. Schon mit dem Studium „Technische Kybernetik und Automatisierungstechnik“ an der TH Ilmenau wurde der Blick auf den Zusammenhang von Elektronik, Regelungstechnik und Software gerichtet. Aktuell betreibt er die IT-Plattform vishia.org.

(ID:48357221)