Funktionsblock-Grafische Programmierung

Topic:.fblock.

Last changed: 2018-08-09

Als Grafische Programmierung wird die Formulierung von Computerprogrammen wesentlich mit grafischen Mitteln verstanden. Dabei sind selbstverständlich textuelle Angaben für Indentifier (Namen), Operation-Angaben oder Anweisungsblöcke in der Ziel-Programmiersprache oder einer anderen passenden (Meta-)-Sprache dabei. Wesentlich ist, dass der Überblick über die Anwendungs-Programmierung grafisch erfolgt. Damit wird ein großes Problem der ausschließlich textuellen Programmierung gelöst: Der Überblick.

Dieser Artikel stellt grundsätzliche Dinge dar. Daraus werden Schlussfolgerungen abgeleitet, die entweder Diskussionsinputs für die Zukunft sein sollen oder aufbauend auf vorhandenen grafischen Tools diese anwenden und erweitern. Da dem Autor eine mehrjährige Erfahrungspraxis beim Tool Simulink (Mathworks) vorliegt, sind die konkreten Anwendungen und Erweiterungen darauf bezogen.

Im speziellen wird versucht, die textuelle und grafische Herangehensweise der Programmierung zu vereinen, indem auch mit Simulink aus der grafischen Ansicht eine textuelle FunktionsBlockConnection-Sprache (FBCL) erstellt wird, die auch ein Roundtrip in das Simulink-Modell ermöglicht. An dieses FBCL ist dann auch eine Codegenerierung für Zielsystemcodes angedockt. Das damit verfolgte Ziel ist die Kompatibilität verschiedener grafischer Programmiertools. Diese Arbeiten sind allerdings im Entwicklungsstadium.

Ein weiteres Thema widmet sich dem Einbringen der Objektorientierung in die grafische Funktionsblock-orientierte Programmierung.

Die grafische Programmierung hat zweifellos Vorteile. Es ist nicht einfach, in vielen Programmzeilen und Aufrufschachtelungen die Struktur zu erkennen. Grafisch ist der Überblick besser weil zweidimensional gearbeitet wird, und es ist die Erkennbarkeit besser, weil sich Programmzeilen, außer durch geschickte Kommentierungen, zu sehr gleichen. In der Grafik ist die Struktur als solche erkennbar und kann mit Bildchen (image) noch aufgebessert werden.

Daher ist es nicht sehr folgerichtig, dass die grafische Programmierung bisher immer noch eine untergeordnete Bedeutung hat und es keine standardisierte Vorgehensweise gibt.

Achtung Verwechslunggefahr: Programmierung grafischer Oberflächen - dies ist ein anderes Thema, nicht hier behandelt. Häufig wird hierfür das Schlagwort visuell verwendet, es meint die Möglichkeit der Programmierung grafischer Benutzeroberfächen, und/oder die marginale Unterstützung der IDE mit Grafik.

Topic:.fblock..

Grafische Programmierung nach Wikipedia

Zitat Wikipedia: https://de.wikipedia.org/wiki/Visuelle_Programmiersprache

Als Visuelle Programmiersprache (englisch visual programming language, VPL) bezeichnet man eine Programmiersprache, in der ein Programm, Algorithmus oder Systemverhalten durch grafische Elemente und deren Anordnung definiert wird.

In dem Wikipedia-Artikel wird darauf hingewiesen, dass einige Programmierumgebungen das Attribut visuell verwenden, eher aus Marketinggründen. Zitat Das Schlagwort "visuell" haftet heute aus marketingtechnischen Gründen auch Systemen an, die wenig visuelle Sprachelemente benutzen. Visual Basic Classic, Xcode und Visual C++ ... Entgegen den Ausführungen im Wikipedia-Artikel möchte der Verfasser anmerken, dass das Schlagwort visuell wohl eher auf die Möglichkeit der Programmierung grafischer Benutzeroberflächen hindeutet - ein seit Entstehen von Visual Studio und MS-Windows in den 90-ger Jahren wesentliche Entwicklung.

Topic:.fblock...

Bild: UML-ObjectModelDiagram

Die modellorientierte oder modellgetriebene Programmierung ist ein Schlagwort, das vorderhand aus der UML (Unified Modelling Language kommt. Das Modell ist hier eine grafische Ausdrucksform von Aktivitäten, Klassenbeziehungen, Abfolgesequenzen, Zustandsdiagrammen und einiges mehr, repräsentiert mit den 14 im UML-Standard definierten Diagrammarten. Als Erweiterung oder Spezialisierung gibt es die SysML mit einigen weiteren Diagrammarten. Die https://de.wikipedia.org/wiki/Unified_Modeling_Language ist in den 90-ger Jahren aus Vorarbeiten und deren Vereinheitlichung insbesondere aus der Aktivität der drei Amigos Grady Booch, Ivar Jacobson und James Rumbaugh entstanden. Seither gibt es einige Firmen, die UML-Tools vertreiben und weitere Firmen, die UML coachen. Die UML ist durchaus weit verbreitet,

• teils aus einem guten Ruf der vollständigen Beschreibung der Entwicklung von den Requirements bis zum Test,

• mit grafischer Unterstützung der Objektorientierung, wenn man das ObjectModelDiagram im Mittelpunkt sieht.

• als Systementscheidung des Einsatzes bei einigen auch größeren Unternehmen.

Topic:.fblock...

Bild: Simulink-Modell

Es gibt eine zweite Art der modellorientierten Programmierung neben der UML, die repräsentiert wird von den Funktionsblock-Darstellungen. Die ersten Funktionsblock-Sprachen sind etwas älter als die UML und wohl unabhängig von den drei Amigos entstanden. Jedenfalls ist die bereits in den 80-ger Jahren bekannte Funktionsblockdarstellung nicht von der UML beachtet worden. Ein Grund dafür könnte sein, dass die UML vorderhand auch objektorientiert ist und die Funktionsblock-Darstellungen in diese Welt wohl nicht passen.

Wie im Folgeabschnitt dargestellt hat das Zustandsdiagramm die Aufnahme in die UML geschafft. Die zur Gründungszeit der UML schon bekannten Funktionsblock-Darstellungen haben diese personelle Verbindung wohl nicht gehabt und haben es damit nicht in die Unified Modelling Language geschafft.

Als wichtiger Verteter der Funktionsblock-Darstellungen sei Simulink (Mathworks) genannt. Es gibt allerdings, wie im Folgeabsatz dargestellt, eine Reihe ähnlicher Modelldarstellungen mit ihren Tools.

Topic:.fblock...

Bild: Beispiel Zustandsdiagramm mit Petri-Netz

Die Arbeit mit Zuständen (States) und deren Übergängen (Transitionen) ist grundlegend in der Programmierung. Die Einheitlichkeit der Anwendung der Zustandsdiagramme ist an sich durch die Standardisierung in der UML erreicht. Zuvor (vor und in den 80-ger Jahren) gab es mit einfachen Zustandsdiagrammen ohne Schachtelung der States, teils mit Petri-Netzen, unter dem Oberbegriff der Automatentheorie, als Mealy- und Moore-Automat. Das Bild rechts zeigt ein sehr einfaches Zustandsdiagramm mit Petri-Netz, Quelle Wikipedia-Artikel bzw. https://de.wikipedia.org/wiki/Petri-Netz#/media/File:Seasons_1.svg. Petri-Netze haben den Vorteil, dass damit parallele Zustände definiert werden können. Das sind aber aus heutiger Sicht Vorarbeiten zum standardisierten Zustandsdiagramm der UML.

Das in der UML standardisierte Statechart ist im wesentlichen von David Harel in den 80-ger Jahren entwickelt wurden und im Tool https://de.wikipedia.org/wiki/Statemate erstmalig etabliert. Es wurde mit Augenmerk auf komplexe System in praktischen Anwendungen entwickelt und kennt sowohl geschachtelte States (internes Verhalten in einem übergeordnetem State), Parallität von Abläufen, Fork- und Join-Syncbar. Letzteres erinnert an Petri-Netze und hat wohl dort möglicherweise seinen Ursprung. StateMachines in UML können entweder Event-getriggert werden, oder zyklisch ablaufen. In beiden Fällen sind Bedingungen für das Schalten definiertbar. Bei Eventtriggerung ist folgendes Prinzip wichtig: Wenn ein Event im aktuellen Zustand nicht verarbeitet werden kann, dann verfällt es. Mit diesem Prinzip wird ein unerwartetes Verhalten aufgrund eines alten gespeicherten Events vermieden. Das Prinzip ist allerdings aufgeweicht durch die mögliche Definition von dereferred Events, vom Autor nicht empfohlen.

Bild: Beispiel-Statechart in UML

Das Zustandsdiagramm hat die Aufnahme in die UML geschafft, obwohl es auch unabhängig aus einer anderen Ecke kam und daher von einigen bis vielen UML-Tools ursprünglich nicht unterstützt wurde. Das wird wohl an personellen / firmellen Gründen liegen: https://de.wikipedia.org/wiki/Statemate wurde bereits in den 80-ger Jahren von der Firma i-Logix entwickelt. Diese Firma ist dann in der Weiterentwicklung in die UML eingestiegen, mit dem Tool Rhapsody, heute als Rational Rhapsody von IBM vertrieben. Es ist folgerichtig und technisch sinnvoll, dass die eigene StateChart-Darstellung von i-Logix in die UML eingebracht wurde. Die UML unterscheidet mit Blick auf zwei wichtige Hauptvertreter der Diagrammarten zwischen statischer Beschreibung - mit dem ObjectModelDiagram und Verhaltensbeschreibung (einer Klasse) mit dem Statechart.

Das Zustandsdiagramm ist als Stateflow Bestandteil von Simulink, in etwa gleichem Funktionsumfang wie in der UML. An dieser Stelle gibt es also eine Vereinheitlichung.

Topic:.fblock...

In den 80-ger Jahren kamen die Petri-Netze in Mode, als Darstellungsmittel der parallelen und konkurrierenden Verarbeitung. Die Petri-Netze, als Idee in den 60-ger Jahren entstanden, sind allerdings immer noch in einigen Bereichen präsent. Sie werden auch als Modellierungswerkzeug benutzt.

Allbekannt ist selbstverständlich der Programmablaufplan. Ob das https://de.wikipedia.org/wiki/Nassi-Shneiderman-Diagramm mit zur grafischen Programmierung hinzugezählt werden soll, sei dahingestellt.

https://de.wikipedia.org/wiki/Graphviz scheint eine Umkehrung des Prinzips der Grafischen Programmierung darzustellen: Aus einer textuellen Beschreibung wird automatisch eine grafische Darstellung erzeugt.

TODO: noch ein paar weitere Recherchen, etwas ausführlichere Beschreibung

Topic:.fblock...

Es erscheint derzeit, dass die beiden Welten der modellorientierten oder -getriebenen Entwicklung in UML und die Entwicklung mit Funktionsblock-Darstellungen sich nicht kennen. Es sind vollkommen verschiedene Tools, Nutzerkreise und Denkschemen. Beide haben ihre etablierte Lobby. Es ist nicht zu erwarten, dass es in naher Zukunft seitens der Toolentwickler eine vereinheitlichende Entwicklung geben wird, wie beispielsweise die Aufnahme der Funktionsblock-Darstellungen in die UML.

Man muss dabei bedenken, dass speziell Simulink als einer der Hauptvertreter der Funktionsblock-Darstellungen einen ganz anderen Unterbau hat als die UML. Simulink ist nicht nur oder nicht erstrangig ein Tool zur Grafischen Programmierung, sondern ein Tool der Simulation. Die Funktionsblock-Darstellung dient also dazu, zusammenzustellen, was in der Simulation zusammenspielen soll. Eine nachfolgende Codegenerierung ist ein nice to have, 'schön, es zu haben' - oder eine notwendige Selbstverständlichkeit da das Simulierte auch auf einer Zielhardware laufen soll, aber nicht der Hauptzweck.

Es wäre aber anzustreben, eine Vereinheitlichung dieser beiden Welten in Details zu erreichen. Damit sprechen die jeweiligen Nutzer zumindestens in einigen Dingen eine ähnliche Sprache. Das kann so weit gehen, dass Kompatibilitätsformate den Datenaustausch ermöglichen. Man stelle sich die Situation vor, dass eine Abteilung in einem Unternehmen traditionell seit Jahren auf UML setzt, eine andere Abteilung gute Erfahrungen mit Simulink hat, und nun beide für Grafische Programmierung zusammenarbeiten sollen.

Die Welt der UML ist bereits vereinheitlicht, dafür steht das Unified schon im Namen. Die Verantwortung für die Standardisierung liegt in einer toolherstellerübergreifenden Organisation: https://www.omg.org/. Das XMI-Format dient dem toolübergreifenden Datenaustausch. Es ist zwar zu beobachten, dass die Toolhersteller nicht unbedingt erstrandig diese Kompatibilität unterstützen, sondern selbstverständlich ihre speziellen Features hervorkehren. Sie müssen aber unterstützen, wenn sie die Anerkennung des Standards haben wollen.

Die Welt der Funktionsplan-Darstellungen ist nicht vereinheitlicht. Im Folgekapitel Chapter: 2 Bekannte Tools für Funktionsblock-Darstellung sind einige Darstellungen und Tools genannt.

Ein Hard- und/oder Systemsoftwareanbieter kann nun, wenn er die Grafische Programmierung unterstützen möchte und dabei auf die Funktionsblock-Darstellung setzt,

• sich entweder einem der Tools unterordnen, dieses speziell unterstützen, und verliert damit möglicherweise Kunden, die ein anderes Tool bevorzugen.

• oder es müssen mehrere Tools in aufwändiger Detailarbeit unterstützt werden.

Ein Ausweg aus diesem Dilemma ist vorderhand ein einheitliches Ausgabe- oder Austauschformat, wie es die UML mit dem XMI bereits hat. Einfach so auf XMI selbst zu setzen dürfte aber nicht gelingen, da die Funktionsblock- oder datenflussorientierte Darstellung dort gar nicht berücksichtigt ist. XMI ist zudem auch sehr komplex.

Eine andere Denkrichtung kann die bessere Lösung sein, im Folgekapitel dargestellt:

Topic:.fblock..txtGrafPrg.

Es könnte/sollte ein wichtiges Grundprinzip Pate stehen für die Vereinheitlichung der Funktionsblockorientierten Grafiktools: Komplementarität der textuellen und Grafischen Programmierung.

Mit XMI ist dies kaum zu machen, zu komplex.

Folgend Vorüberlegungen/Anregungen:

• In der UML ist das Roundtrip bekannt, um Änderungen in der textuellen Erscheinung der aus UML generierten Codes in das UML-Modell zurückzuspielen. Das Roundtrip wird von den UMLern oft genutzt, da faktisch im generieten Code getestet, gedacht und folglich auch dort geändert wird. Es ist ein bekanntes und bewährtes Prinzip.

• Tools speichern ihre Daten fast immer in einem textuell lesbaren Format ab. Sucht man beispielsweise eine bestimmte Bezeichnung, dann kann man diese im textuellen Abbild zumindestens finden und damit erkennen, in welchem Modell diese vorkommt. Es gibt kaum ein Tool, das hier etwa mit binärer Spezialkodierung diese Information verbirgt. Sehr verbreitet ist die Abspeicherung der eigentlichen Daten in einem XML-Format, und danach zusammenbinden mehrerer Files im zip-Format. Das wird verwendet auch von den bekannten Office-Tools (.xlsx, .docx sind solche Formate). Auch Simulink speichert die Daten im .slx-File so ab. Der ältere .mdl-File ist direkt textuell lesbar.

• Diese textuellen oder XML-Abbilder sind aber nicht unifiziert, taugen eventuell für Suche und Vergleich mit Spezialwissen, aber nicht für die oben geforderte Komplementarität der textuellen und Grafischen Programmierung.

• Es gibt zwei Typen von textuellen Abbildern der Grafik. Beim Typ 'änderbar' kann man unter Beachtung der Syntax und auf eigene Verantwortung Inhalte im textuellen Abbild erfolgreich ändern, diese erscheinen dann richtig in der Grafik. Bei Typ 'nicht änderbar' wird mit nicht gut überschaubaren Querchecks von Inhalten oder sogar mit Prüfcodes die Änderung verhindert. Dem Verfasser ist beim Grafiktool STRUC (Simadyn, Siemens) in den 90-ger Jahren der Prüfcode in die Quere gekommen, der aber extra eingeführt wurde, weil Anwender direkt im Text geändert hatten und sich danach beim Hersteller beschwert haben, dass es Widersprüche gab. Die persönliche Bekanntschaft mit der Entwicklungsabteilung hat nun geholfen, für bestimmte Anpassungen diese Barriere zu brechen.

• Die Bereitschaft, im textuellen Abbild zu arbeiten, ist dem Verfasser auch in der Welt der GUIs und einem bestimmten Grad der Toolgläubigkeit ('das darf man doch nicht') auch bei anderen Kollegen im Gesprächskreis aufgefallen.

Die Komplementarität von Text und Grafik hat gewichtige Gründe, die auch im Folge- Chapter: 1.7 Mögliche Gründe der geringen Nutzung der grafischen Programmierung genannt sind.

Zu fordern ist:

• Die textuelle Speicherform braucht/soll/darf nicht die Grafikinformationen enthalten. Für die Grafikbearbeitung ist das Grafiktool zuständig. Dieses darf speziell und nicht kompatibel zu anderen Tools der Funktionsblock-Programmierung sein. Die Tools müssen einen Eigenständigkeitsgrad behalten dürfen.

• Die textuelle Speicherform muss aber alle Informationen enthalten, die die Funktionalität des Modells beschreiben.

• Die textuelle Speicherform kann Informationen enthalten, die Auswertungen der Modelldaten ermöglichen. Beispiel dafür: In Modellen kann ein Requirement-Backtracking verankert sein: Bestimmte Modellelemente, die speziell der Erfüllung bestimmter (Kunden-) Anforderungen dienen, sollten mit einem Label, dass die Anforderung eindeutig identifiziert, versehen werden können. Dieses Labels sollten in der textuellen Speicherform auftauchen.

• Nach Änderungen im Modell, die nicht funktional sind sondern nur Grafikpositionen und Grafikauszeichnungen betreffen, muss das textuelle Komplement vollkommen unverändert sein. Nur so ist ein Versionsvergleich möglich. Das ist essentiell, wenn beispielsweise für kleine Nacharbeiten für die Dokumentation die Modellfiles selbst geändert werden, aber die damit erzeugten Ablaufcodes bereits getestet und ausgeliefert sind und nicht noch einmal nachgeliefert werden sollen. Hier muss es einen eindeutigen Nachweis geben, dass bei einer Neugenerierung der Ablaufcodes das Ergebnis identisch sein würde.

• Nach Änderungen im Modell an bestimmten wenigen Stellen müssen diese Änderungen für einen Versionvergleich mit textuellen Diff-Tools deutlich sichtbar sein. Es dürfen keine zusätzlichen Differenzen auftreten, die die Vergleichbarkeit erschweren.

• Folglich dürfen keine Ident-Nummern verwendet werden, die automatische generiert sind und aus Grafikänderungen heraus anders vergeben sind für die gleichen Elemente. Dann würden nur die Indent-Nummern als 'geändert' erscheinen obwohl eigentlich nichts geändert ist. Letzteres ist beispielsweise so, wenn man in Simulink die mdl-Files textuell vergleicht.

• Es dürfen auch keine Meta-Informationen im textuellen Abbild stehen, die nur dadurch entstehen, dass das Modell geöffnet, unverändert gepeichert und wieder geschlossen wurde. Häufig wird dann aus vermeintlichen Servicegründen das Datum der letzten Speicherung (obwohl unverändert) und/oder Login-Informationen des Bedieners gespeichert.

• Das Datum der letzten funktionellen Änderung darf aber im File enthalten sein. Dies entsteht aber nicht von selbst (wie das Datum der letzten Änderung, dies ist ja einfach das aktuelle Systemdatum) sondern muss vom Tool verwaltet werden: Einlesen des Datums der letzten Änderung beim Öffnen des Modells, nur bei funktionellen Änderungen neu setzen, bei Bedienung 'rückgängig' (meist ctrl-Z) auch das Datum der letzten Änderung auf den alten Stand zurücksetzen wenn letzlich nichts geändert ist). Das Datum der letzten Änderung, zusammen mit den Login-Informationen, ist hilfreich.

• Es muss jedenfalls ein Roundtrip bei syntaktisch korrekten Änderungen im textuellen File unterstützt werden. Die komplette Information des Modells ist in dem toolspezifischen Speicherformat enthalten. Aber das Tool muss unterstützten, eine Änderung im zeitgleich mit gepeicherten textuellen Abbild zurückzulesen.

• Das textuelle Abbild muss einfach zu lesen und zu ändern sein. Es dürfen keine Doppelinformationen enthalten sein (zum Beispiel Eingänge verweisen auf Ausgänge, dass Ausgänge von Funktionsblöcken auch auf die Eingänge verweisen ist nicht nötig, doppelt und stört bei Änderungen).

Für Simulink ist ein solches textuelles Komplement generiert aus dem slx-File mit Roundtripmöglichkeit beim Verfasser in Arbeit. Ergebnisse werden in naher Zukunft präsentiert.

Für andere Tools der Funktionsblock-Darstellung kann das gleiche Format toolspezifisch entwickelt werden, Einigt man sich auf ein bestimmtes Format, dann ist das Ziel der Vereinheitlichung der Tools an dieser Stelle geschafft.

Topic:.fblock..noGProg.

Geschätzt über 90% der Programmierung in allen Bereichen wird heute noch nicht grafisch ausgeführt. Dies wird häufig beklagt, aber der Zustand hat sich, obwohl Tools der Grafischen Programmierung schon mittlerweile jahrzehntelang etabliert sind, nicht geändert.

Im Wikipedia-Artikel für Labview (National Instruments) werden folgende Nachteile genannt, die im Artikel auf Labview bezogen sind, aber in etwa der gleichen Form überall zutreffen dürften:

---Zitat aus https://de.wikipedia.org/wiki/LabVIEW Stand 2018-07-16

Neben den genannten Vorteilen hat die graphische Programmierung gegenüber der textbasierten auch Nachteile:

• LabVIEW-Programme lassen sich nur mit der originalen LabVIEW-Entwicklungsumgebung bearbeiten, an deren Funktionsumfang man gebunden ist. Allerdings lassen sich Funktionen aus dynamischen Bibliotheken oder ActiveX-Objekte nutzen. Der Plattformunabhängigkeit geschuldet sind Hindernisse in der Gestaltung von Benutzeroberflächen, so werden Windows-Hotkeys nicht unterstützt, und das Verhalten von Accelerator-Keys entspricht nicht exakt dem Verhalten des Betriebssystems (hier: Fokus-Verlust). Die Unicode-Unterstützung ist unzureichend.

• Ausführbare LabVIEW-Programme können vom Entwicklungssystem zwar erstellt werden, erfordern jedoch die Installation einer Laufzeitumgebung auf dem Zielsystem (vergleichbar mit der Installation des .NET-Frameworks für .NET Applikationen). Bei Verwendung von bestimmten Zusatzmodulen, wie z. B. IMAQ Vision, ist zudem eine kostenpflichtige Lizenz pro Zielplattform notwendig.

• Die Prinzipien moderner Objektorientierung versucht National Instruments mit neueren LabVIEW Versionen zwar nachzubilden, jedoch gelingt dies bisher nur unzureichend. Zudem zeigt die Programmierung gegen große bestehende Klassenhierarchien wie das Microsoft .NET-Framework die Grenzen im Umgang mit grafischen Zugriffsknoten auf - mit textbasierten Programmiersprachen, zum Beispiel C#, sind dieselben Aufgaben i. d. R. schneller programmierbar.

• Kleine Änderungen können aufwendige Neustrukturierungen nach sich ziehen, wenn das Schaffen von Raum auf dem Blockdiagramm durch Verschieben geschieht, da dann die Drähte und Symbole oftmals neu geordnet werden müssen, um die Übersichtlichkeit wiederherzustellen. Dieses Problem kann jedoch durch Strukturierte Programmierung gemildert werden (insbesondere durch konsequente Verwendung von Sub-VIs).

• Der einfache Einstieg in die LabVIEW-Programmierung verleitet dazu, die ordentliche Planung des Projektes zu vernachlässigen.

---ende Zitat.

Im ersten und zweiten Punkt wird beklagt, dass ein Kollege am Nebenplatz, der eben mal keine Labview-Lizenz hat, nichts mit der Arbeit seines Nachbarn anfangen kann. Solange es um den Nebenplatz in der gleichen Firma geht, kann man argumentieren, dass es Netzlizenzen gäbe. Damit ist das Problem aber nicht gelöst, denn man möchte Modelle oder Informationen daraus auch mit Partnerfirmen austauschen. Bei der Vielzahl und Diversität der Tools kann man nicht damit rechnen, dass der Partner auch eine Lizenz hat, beziehungsweise noch problematischer, sich nicht auf das Tool eingearbeitet hat.

Vergleicht man dies nun mit den textuellen Softwarequellen, dann ist es schlicht egal, ob man einen Quelltext mit einem kostenpflichtigem Visual Studio 2017 bearbeitet hat, oder mit Eclipse CDT, oder nur mal eben mit Notepad++ damit hineinschaut um zu erkennen wie eine Ausgabe gebildet wird. Der Unterschied ist nicht die Kostenpflichtigkeit der Lizenz sondern die nicht notwendige spezielle Einarbeitung in das Tool. Die gemeinsame Sprache ist der Quelltext der Programmierung, der ist bekannt.

Also wird gezögert in der Entscheidung für ein Tool der Grafisches Programmierung:

• Dies ist eine Systementscheidung. Es stehen Lizenzkosten bei Mehrplatznutzung in 5-stelligem Bereich an.

• Dabei ist vollkommen ungeklärt, ob die Nachbarabteilung oder die Partnerfirma mitzieht.

• Da die Tools doch spezieller sind, braucht es eine Schulung der Mitarbeiter, mit Zeit- und finanziellem Aufwand.

• Wenn die gesamte Programmierung umgestellt ist, ist der Nutzen wirklich da? Meist liegt der Teufel im Detail.

Es gibt einige weitere Aspekte, die für die Bevorzugung der zeilenorientierte Programmierung sprechen:

Im Moment der Programmierung, also über einen Zeitraum von 1..2 Jahren kennt man sich im eigenem Quelltext aus. Suchfunktionen und Strukturierung die die IDE anzeigt, helfen. Möglicherweise nimmt man ein UML-Tool oder eine passende Grafik zur Unterstützung der Dokumentation. Über diese zwei Jahre der Bearbeitung im kleinen Team kommt man mit dem Quelltext gut hin. Das Problem der Unübersichtlichkeit der rein textuellen Programmierung fällt erst dann auf, wenn entweder Zeit vergangen ist oder der Quelltext einem anderen Kollegen erklärt werden muss. Im letzten Fall, sobald sich der Kollege etwas hereingedacht hat, ist das Problem wieder weg, man kommt gut mit dem Quelltext zurecht.

Die IDEs (Integrated Development Environment) sind in den letzten Jahrzehnten besser geworden' und bieten weitreichende Unterstützung beim Refactoring. Debugging wird direkt unterstützt. Man debuggt eher im Quelltext.

Für den Vergleich der Softwareversionen, der Absicherung, was ist beim Kunden, ist der Quelltext besser geeignet.

Eine langjährige Pflege der Software, also mögliche Anpassungen beispielsweise beim Ersatz defekter nicht mehr beschaffbarer Hardware, erfordert beim Quelltext lediglich das Aufheben der Compiler und Linker für das Zielsystem. Man kann ältere Versionen entweder auf einem älteren PC, der extra archiviert wird, ablaufen lassen, oder man benutzt beispielsweise VMware zur Emulation der damaligen Systemumgebung. Dazu sind die Aufwände gering. Bei einem Grafiktool muss man nicht nur das Tool selbst vorhalten, gegebenenfalls auf Lizenzen und Zugänge achten, sondern muss auch das Wissen um die Bedienung bewahren. Langjährig bedeutet 20..40 Jahre (bei Industrieanlagen). Entscheidet man sich jetzt also für ein Graphik-Programmiertool dann stehen diese Fragen, bezogen auf eine ferne Zukunft, ebenso im Raum.

Die letzten beiden Punkte im Zitat der Labview-Nachteile sprechen ein Thema an, das mit einem Styleguide beziehungsweise einer modularen Arbeitsweise lösbar ist. Im Vergleich zu textuellen Tools hat man ja bei letzteren das gleiche Problem, wenn man einfach darauf los programmiert. Aber es erscheint bei Texten einfacher, Inhalte zu verschieben, nachdem man die Notwendigkeit der Umstrukturierung erkannt hat. Zudem wird von modernen IDEs das Refactoring gut unterstützt.

Dem Verfasser erscheinen diese letzten beiden Punkte jedoch nicht als typisch für die Grafische Programmierung. Im Gegenteil: Beim 'Aufräumen' im grafischen Modell hat man den besseren Überblick als beim aufräumen in Textzeilen. Grafische Teile lassen sich, zumindestens in Simulink, per Zwischenablage in andere Modellteile oder Submodule einfügen. Eine spezielle Unterstützung in Simulink für Create Subsystem from Selection ist genau für solche Aufräumaktionen gedacht. Man sieht an dieser Anmerkung eines oder mehrerer Wikipedia-Schreiber, das wohl auch hier noch Nachholebedarf gegeben ist.

Topic:.fblock.tools.

In der Wikipedia Kategorie Grafische Progammiersprachen findet sich eine Übersicht, die ein Teil der hier genannten Tools unterstützt. In dieser Kategorie fehlt (Stand 2018-07) die UML, es fehlt auch Simulink und einige weitere Tools. Die UML gehört zu den Grafischen Programmiersprachen, wird von den Verfassern aber offensichtlich dort so nicht eingeordnet.

Folgend wird jedes dem Verfasser bekannte Tool kurz vorgestellt. Es soll damit gezeigt werden, wie vielfältig (und nicht standardisiert) diese Welt ist.

TODO: Noch genauer recherchieren, das ist erstmal ein kurzer Überblick.

Topic:.fblock.tools..

https://de.wikipedia.org/wiki/ICon-L An einigen Instituten/in einigen Firmen verwendete grafische Programmiersprache mit integrierter Ablage des zu interpretierender Ablaufcode, Aufruf der zugehörigen in C geschriebenen Funktionen.

Topic:.fblock.tools..

https://de.wikipedia.org/wiki/LabVIEW National Instruments, Verschaltung von Messgeräten, Anzeigen und Berechnungen vorderhand für Messungen in Labors.

Topic:.fblock.tools..

https://de.wikipedia.org/wiki/Max/MSP

https://de.wikipedia.org/wiki/Pure_Data Datenstromdarstellung / Planung

Topic:.fblock.tools..

https://de.wikipedia.org/wiki/Posity

Etwas sehr spezifisch für betriebswirtschaftliche, datenbankzentrierte Anwendungen (aus Wikipedia-Artikel)

Topic:.fblock.tools..

https://de.wikipedia.org/wiki/Qfix_Grape

Kann alles, wenig Angaben.

Topic:.fblock.tools..

https://de.wikipedia.org/wiki/VisSim

Erstversion 1989, aktuell aus 2008, grafische Blockdiagramm-Programmiersprache für die Simulation von dynamischen Systemen. (Zitat aus Wikipedia-Artikel). Äußerlich irgendwie wie Simulink-Blockdiagramme.

Topic:.fblock.tools..

Obwohl nicht in der Wikipedial-Kategorie:Grafische Programmiersprache benannt, ist Simulink adäquat. Aus Sicht der grafischen Programmierung ist es eine Funktionsblockorientierte Grafische Programmiersprache. Erwähnenswert sollte allerdings sein, dass mit Matlab als Background und sehr vielen Addons eine vollständige Simulation der grafisch gezeichneten Programmierung erfolgt. Codegenerierung für C, aber auch für FPGAs (VHDL) sowie einige andere Programmiersprachen ist als addon zukaufbar. Eine home-Edition (keine kommerzielle Nutzung) ist bereits für wenige 100 Euro erhältlich, auch als Studentenversion, alle Simulationsmöglichkeiten umfassend aber ohne die C-Code-Generierung.

In Simulink ist direkt in C geschriebener Code einbindbar (sogenannte S-Functions), auch in der Home-Edition. Damit ist eine Brücke zu Systemprogrammen und hardwarenaher Programmierung vorhanden.

Topic:.fblock.do.

Last changed: 2018-08-09

Dieser Artikel wäre wenig nutzbringend, wenn nicht konkrete Realisierungen in die hier aufgestellte Richtung bereits in Arbeit oder erledigt wären.

Topic:.fblock.do..

Dazu ist auf ein vom mir erstelltes pdf verwiesen: ../../smlk/SmlkOOguide-de.pdf. Dazu ein Grundsatzpapier: ../../smlk/SmlkOOapproach-de.pdf. Ein passendes Beispiel zum Auspacken und Testen ist abzholen: ../../smlk/Example_ObjO.zip. Im Beispiel ist nicht das Generierscript enthalten. Es ist nicht zum eigenen Arbeiten, sondern nur zum Nachverfolgen der Herangehensweise gedacht. Bei Interesse bitte mit dem Verfasser in Verbindung setzen: mailto: hartmut.schorrig@vishia.de

Detailliertere Erklärungen befinden sich in ../../fbg/html/GraphProgr_1.html.

Bild: Beispiel Object-FB in Simulink

Die Idee ist, Funktionsblöcke in Simulink als Object-FB und Operation-FB zu untergliedern und mit Referenzen zu verbinden. Das Bild rechts zeigt zwei Object-FB, param2 ist als Aggregation auf OrthOsc2_FB verbunden. calcmagn2 ist ein Operation-FB. Die Referenzen sind in Simulink Handle, die einen Index auf eine globale Adresstabelle darstellen. Die Adressen selbst sind damit intern. Die Adressen stehen in einem shared-memory-Bereich da jeder Funktionsblock als S-Function realsisiert sonst seinen eigenen Speicherbereich hat. Die Object-FB legen Daten an und kennen über Aggregationen andere Object-FB. Die Operation-FB bekommen den Handle von ihren Object-FB und wenn notwendig noch von anderen Object-FB. Damit können die Operation-FB mit den Daten der Object-FB beliebig arbeiten, wie es der Objektorientierung entspricht. Das für die Funktionsplan-Darstellungen gewohnte Datenflussprinzip wird hier etwas durchbrochen, da die Zugriffe auf die Daten nicht gezeichnet sind. Die Handleverbindungen sind aber gezeichnet. Man sieht in der Grafik nicht direkt, mit welchen Daten gearbeitet werden. Die Grafik ähnelt zum Teil eher einem ObjectModelDiagram aus der UML, nur die Zeigerrichtungen sind umgekehrt: In der UML als Depedency vom Nutzenden zum Genutzten, in der Funktionsblock-Darstellung vom Bereitstellenden zum Nutenden. Der Datenfluss wird also dargestellt, aber mit dem Handle bekommt man den Zugriff auf alle Daten.

Der notwendige Typtest der Handle oder Zeiger erfolgt zur Runtime in einer speziellen Tinit-Abtastzeit über Reflection. Die Handle sind formal uint32-getypt. Für das Zielsystem enthalten die Handle direkt die Instanzadressen (kurze Rechenzeit). Im Zielsystem werden vom Simulink-Codegenerator die Zeiger immer noch als uint32 gespeichert, vor Aufruf erfolgt codegeneriert das notwendige casting. Der Typtest darf im Zielsystem entfallen, wenn die Verbindungen aggregiert sind (nicht zur Laufzeit geändert) und das Modell getestet ist, der Typtest also im Modell jedenfalls durchlaufen wurde. Der Typtest ist nur notwendig, um Anwender-Verbindungsfehler im Modell zu erkennen.

Bild: FunctionCall ObjO_Smlk

Die Themen Vererbung bzw. Abstraktion, wie sie für die Objektorientierung typisch sind, sind ebenfalls abgehandelt: Es ist möglich, einen mehr abstrakten Typ als Input eines Operation-FB zu verdrahten auf den abgeleiteten Instanztyp, damit wird eine Basis-Operation gerufen. Aus einer Basis-Operation heraus kann über den Aufruf einer anderen Basisoperation die für die Instanz abgeleitete Operation gerufen werden, indem entweder in C über eine Nachbildung der virtuellen Tabelle über Funktionszeiger die instanzrichtige Operation gerufen wird, oder, wie im Bild rechts gezeigt, der Funktionsaufruf über eine triggered Operation läuft. Die Arbeit mit abgeleiteten Operationen ist deshalb interessant, weil ein Basissystem als Modell unverändert übernommen werden kann, ein anderes Modellteil aber spezialisiert ist. Es muss dann keine Anpassung erfolgen.

Bild: ObjO_Smlk Funktion in Simulink

Das Ganze funktioniert nicht nur mit S-Functions, die in C programmiert sind, sondern auch mit Modellteilen in Simulink. Dabei sind nur die Schnittstelle beispielsweise zu einem Operation-Submodul in C programmiert. An den Ausgängen dieser S-Functionen stehen die Daten der Klassen-Instanz (des zugehörigen Object-FB) an. Diese werden in einem reinen Simulink-Modell verknüpft und auf Eingänge einer S-Funktion zum Einschreiben der Daten in die Klasseninstanz gelegt. Für den Controlflow können triggered Subsystems des Simulink eingesetzt werden. Das rechtstehende Bild zeigt die Einbettung einer Funktionalität in einen datenliefernden und einen datenspeichernden Operation-FB. Beide sind einfache S-Functions. Die eigentliche Funktionalität ist modelliert. Der Datenzugriff in diesen Operation-FB kann mit entsprechenden C-Funktionen insbesondere geschützt sein, für Mulitthreading mit Wechselpuffer oder Mutex und dergleichen. Solche Dinge sind dann in C besser ausprogrammierbar, da direkt Betriebssystemdienste in Anspruch genommen werden können.

Busse in Simulink werden unterstützt. Da die Busse aber teils mit der Zeiger- oder hier Handle-Technik nicht verträglich sind, werden Datenstrukturen nicht mit Bussen sondern als struct in C definiert. Die zugehörigen S-Function-Blöcke sehen dann in der Grafik schmal geschoben fast so aus wie ein Bus-Selector.

Die Realisierung baut also stark auf S-Functions in C. Damit diese S-Functions unaufwändig in das Modellieren integriert werden können, ist ein eigener Codegenerator für die S-Function-Wrapper gebaut, der mit Informationen aus den Headerfiles arbeitet und pro S-Function viel weniger Aufwand braucht als etwa das Mathworks- oder Simulink-eigene Legacy Code Tool. Dieser Teil der Realisierung ist nicht Opensource, muss also vom Autor geliefert werden. Das Grundprinzip kann aber anhand eines umfangreichen Beispiels studiert werden. Die Zielcodegenerierung läuft über den Simulink-Coder. Die dafür notwendigen tlc-Files werden vom S-Function-Wrapper-Generator geliefert, so dass ein reibungsloses Zusammenspiel gesichert ist.

Würde dieses System nativ in Simulink von Mathworks unterstützt werden (was durchaus in den nächsten Jahren vorstellbar ist), dann könnte die C-Ebene teils herausgenommen werden. Wenn Busse andere Busse referenzieren können (das sind Assoziation oder Aggregation), dann wäre die Datenanlage vollständig mit dem Bus-System in Simulink möglich. C-Funktionen kommen dann nur ins Spiel (ggf. mit dem S-Funktion-Wrapper-Generator des Verfassers) wenn sie von der Anwendung wirklich gewünscht wären.

Topic:.fblock.do.FBCL.

Last changed: 2018-08-09

Der Verfasser hat sich mit dem Auslesen von Informationen aus dem slx-File beschäftigt, um eine spezielle Codegenerierung zu entwickeln, die von Simulink nicht unterstützt wird. Dabei wurden die Informationen, die im slx-File Simulink-spezifisch enthalten sind, zunächst unifiziert. Es wurde mit verschiedenen Simulink-Versionen gearbeitet, dabei traten Änderungen im slx-File auf, die zwar klar erkennbar und schnell behandelbar waren, aber eine Trennung der Aufbereitung der Informationen aus dem slx-File von der eigentlichen Codegenerierung nahelegen. Im derzeiten Stand dieses Projektes wird die unifizierte Ablage der Modelldaten nur intern gehalten. Die Idee, damit eine allgemeingültige Datenablage zu bilden, ist daraus entstanden.

Die Idee und die Anforderungen an diese allgemeingültige textuelle Datenablage von Funktionsblock-Darstellungen ist im Kapitel Chapter: 1.6 Komplementarität der Textuellen und Grafischen Programmierung oben bereits beschrieben. Diese Idee ist nicht mehr nur auf verschiedene Versionen der slx-Codierungen des Simulink bezogen, sondern soll andere Grafik-Darstellungen und Tools der Funktionsplan-Represetationen mit einbeziehen. Das können die im Kapitel Chapter: 2 Bekannte Tools für Funktionsblock-Darstellung genannten sein.

Es ergibt sich damit folgende Situation (Stand 2018-August):

• Über eine einheitliche FBCL können funktionale Informationen aus Funktionsblock-Darstellungs-Tools entnommen und beliebig weiterverarbeitet werden, unabhänig von den Toolherstellern.

• Ein Roundtrip bei geänderten Infos im FBCL aber versionsrichtiger Speicherung im zugehörigem Tool sollte möglich sein. Für Simulink wird beides von mir aus slx generiert bzw. das slx wird entsprechend korrigiert.

• Für andere Tools kann ein Toolhersteller oder -nuter entsprechendes kompatibel programmieren, so dass mit einer einheitlichen FBCL verschiedene Tools kompatible unterstützt werden.

• Wenn es gelingt, die FBCL mit Grafikinformationen zu versehen und insgesamt als Inputformat für verschiedene Tools zu nutzen (also kein Roundtrip sondern wirkliches Input) dann gelingt der Datenaustausch zwischen den Tools. Gegebenenfalls kann es dabei manuell zu lösende Details geben.

• Eine Codegenerierung für andere als vom Tool selbst unterstützte Ziel-Programmiersprachen kann/sollte aus der FBCL heraus erfolgen. Dann ist die Codegenerierung zugleich aufgrund einheitlicher Schnittstelle für alle Tools erledigt, die FBCL adäquat unterstüzten.

• Diese Codegenerierung hat meistenteils experimentellen Charakter. Es soll nicht langjährig gewachsenen Systemen der Zielcodegenerierung der entsprechenden Tools in überschwenglicher Weise eine einfache Konkurrenz geboten werden. Bei Simulink betrifft dies insbesondere die C- und VHDL-Codegenerierung.

Der letzte Punkt ist nochmals darzustellen: Eine Codegenerierung aus der noch zu beschreibenden FBCL ist keinesfalls etwa mit einem einfachen Perl-script oder dergleichen noch etwa in einer Bachelorarbeit machbar. Die Zielcodegenerierung benötigt eine hohe Verlässlichkeit, die auch durch langjährigen Praxiseinsatz gegeben ist. Aber mit einem anfänglichen experimentellen Ergebnis kann bei intensiver Beschäfigung eine solide Lösung entstehen. Für den einzelnen Toolhersteller kann das im Verlauf von einigen Jahren eine gewisse Konkurrenz bedeuten. Diese Konkurrenz erwächst aber aus den Anforderungen der Nutzer. Diese wollen möglicherweise Lösungen, die kompatibel für verschiedene Tools anwendbar sind. Dies ist ein vergleichbarer Ansatz wie die Standardisierung der UML-Darstellung im XMI-Format.

Die Idee der FBCL hat also zukunftsweisenden Charakter. Man muss sehen, was sich daraus entwickelt.

Topic:.fblock.do..

ident=FBCL2target

Folgend ist nur stichpunktartig benannt, was alles zu beachten ist bei einer Codegenerierung aus einer textuellen Funktionsblock-Connection-Darstellung, die als Output aus verschiedenen Tools möglich sein sollte:

• Die Modelle in der FBCL sind häufig nicht oder nicht vollständig typspezifiziert. Die Datentypen ergeben sich vielmehr aus den außen angeschlossenen Input- oder ggf. auch Output-Daten (Back-Propagation). Dies gilt insbesondere für Library-Module, die in verschiedenen Typumgebungen eingesetzt werden können. Die Generierung einer statischen Zielsystemsprache wie C, C++, Java, C# erfordert jedoch typspezifische Variablendeklarationen, um damit die typspezifische Compilation der Funktionalität zu realisieren. Um dies zu erreichen, muss zunächst ermittelt werden, wie viele verschiedene Typen in einem Modul vorhanden sein müssen, unabhängig von der Ausprägung der Typen. Wenn beispielsweise ein Modul nur numerische skalare Operationen ausführt, dann braucht dieses Modul nur genau einen Typ, der der dann bei der Verwendung des Moduls aus dem höchsten numerischen Typ der Umgebung bestimmt wird. Werden im Modul dagegen Vektor- und Sklararoperationen gemischt verwendet, dann braucht es den Vektortyp, mit von außen definierter Anzahl Elemente, neben dem Skalartyp passender numerischer Auflösung. Die Typinstanzen ergeben sich aufgrund der Verdrahtung der Funktionsblöcke. Diese müssen zunächst festgestellt werden. Dabei kann die Komplexität hoch sein.

• Für eine bestimmte Typausprägung der Nutzung eines Moduls gibt es eine Zielsystemcodegenerierung. Wird das selbe Modul in einer anderen Typumgebung nochmal verwendet, dann braucht es eine zweite andere Codegenerierung. Dies muss verwaltet werden.

• Die Abarbeitungsreihenfolge der Funktionsblöcke ergibt sich aus dem Datenfluss. Zu beachten sind dabei auch verschiedene Abtastzeiten (in Simulink mit Rate Transition gekennzeichnet). Für das Zielsystem muss es pro Abtastzeit eine Gesamt-Operation ergeben. Weiterhin sind spezielle Operationen für die dynamische Initialisierung der Instanzen nach der Anlage notwendig. Selbstverständlich muss das Problem, wie Daten angelegt werden (new, statisch ...) definiert werden.

• Module mit Funktionsblöcken sind oft so zusammengestellt, dass verschiedene Operationen in einem Modul vereint sind. Äußerlich kann es Rückkopplungen von Ausgängen auf Eingänge im Datenfluss geben, die aber nicht wirkliche Schleifen sind. Zusammen mit dem folgenden Punkt müssen einzelne Operationen aus einem Modul herausgelöst werden. Keinesfalls darf ein Modul immer als eine Einheit aufgefasst werden (kein 'Atomic Subsystem' in Simulink).

• Module enthalten oft Funktionsblock-Verschaltungen, deren Ausgänge in der Anwendung des Moduls dann nicht genutzt werden. Das ist mit dem Aufruf des Moduls klar erkennbar. Die Teilfunktionalitäten im Modul müssen passend zu Operationen zusammengefasst werden. Wenn Ausgänge nicht genutzt werden, dann werden die damit verbundenen Operationen zwar möglicherweise codegeneriert, brauchen also Speicherplatz, werden aber nicht aufgerufen. Eine andere Variante ist, diese Teile erst gar nicht zu generieren (wichtig für Zielsysteme mit wenig Speicher).

• Das richtige Verhalten von 'update' (Belegung von Zustandsvariablen) muss realisiert werden. Es darf kein falsches Verhalten in der Abtastzeit-Abarbeitungsreihenfolge generiert werden. Insbesondere Filteralgorithmen hängen von der korrekten Verwendung der Speichervariablen ab. Zusätzliche Totzeiten wegen falscher Rechenreihenfolge bewirken Instabilität oder unerwartete Resonanzen in closed-loop-Anwendungen.

Topic:.fblock.inspc.

Last changed: 2018-08-09

Es gibt zwei verschiedene Herangehensweisen der Simulation:

• a) Es wird auf dem PC mit spezieller Abarbeitung simuliert. Dabei sind selbstverständlich Zwischensignale abgreifbar.

• b) Die Abarbeitung erfolgt immer im Zielsystem bzw. mit adäquater Compilierung des einen Zielcodes auf dem PC. Auf dem PC ist selbstverständlich ein Einzelschritt-Debugging mit den bekannten IDEs möglich. Wie Zwischensignale auch im Run-Mode sichtbar ist, ist individuell zu klären.

Einige der einfachen funktionsplandarstellungsorientieren Tools arbeiten nach dem System b). Das Zielsystem wird direkt unterstützt, Compilierung in einer PC-Umgebung reicht für einen Test ohne Zielhardware.

Simulink arbeitet typischerweise (im typischen Anwendungsfall) nach der Variante a). Das liegt auch daran, dass Simulink nicht vorrangig ein Tool zur grafischen Zielsystemprogrammierung ist, sondern ein Simulationstool auch für Grundsatzuntersuchungen. Wenn beispielsweise komplexe technische Systeme nachgebildet und simuliert werden (mit Simscape), dann ist eine Codegenerierung für diese Systeme nicht angebracht. Die Simulation erfolgt durch numerische Integration der Differenzialgleichungen über interne Algorithmen.

Dennoch ist für Simulink eine Instrumentierung des Zielsystems möglich.

Instrumentierung bedeutet: Im Zielsystem werden Daten erfasst und auf Modellebene an passender Stelle im Modell mit dem laufenden Zielsystem dargestellt. Es ist dann beispielsweise beobachtbar

Topic:.fblock..

https://en.wikipedia.org/wiki/Comparison_of_system_dynamics_software